mojira.dev
MC-128225

'/data remove' can't remove the NBT "CustomName"

The bug

The /data remove command can't remove the NBT CustomName.

How to reproduce

  1. Type this command:

    /summon spider ~ ~ ~ {CustomName:"{\"text\":\"Grumm\"}"}

    → ✔ You can see its name by looking at it

  2. Type this command:

    /data remove entity @e[type=spider,limit=1,sort=nearest] CustomName

    → ❌ Its name should be removed, but it isn't

Expected behavior

The name of the entity should be able to be removed using the /data remove command.

Related issues

Attachments

Comments

migrated
[media][media]
migrated

Does reloading the world (leave and enter) fix it?

migrated

No, its nbt still has CustomName value
It still exist in 18w15a

migrated

Comfirmed in 18w16a

migrated

You can update the affected versions yourself, no need to comment.

kg583

Confirmed for Minecraft 1.13-pre7

migrated

Affects 18w31a.

migrated

Affects 1.13.1-pre2.

AlexMCool

Confirmed for 18w43c

migrated

Confirmed for 1.14.1

migrated

Confirmed in 1.16 Pre-release 2.

kcrca

Just to make it clear – this seems to be general. I can't remove saddles from horses, items from frames, ...

Avoma

Can confirm in 21w05b.

Avoma

Can confirm in 21w06a.

tryashtar

As a workaround you can just use data modify to set it to any non-JSON string, it will throw and end up clearing the existing name

Avoma

Can confirm in 1.17.1. Video attached.

kcrca

@tryashtar can you give an example? I find that the the non-JSON string is simply rejected by the command parser and so never executed. And, say, to remove horse armor I've tried things like setting the specific armor slot to "air" or to Count:0, which don't work.

tryashtar
/summon pig ~ ~ ~ {CustomName:'"test"'}
/execute as @e[type=pig,name=test] run data modify entity @s CustomName set value ""

 

kcrca

Ah, yes, thanks, good to have this in the text!

I agree that this works for CustomName, and I'd guess for other string properties.

However, my bug was marked a dup of this one, and I was looking at non-string properties, such as SaddleItem. And it does not work (afaict) for a horse's SaddleItem. I tried

/data modify entity f4d501d5-adc6-4bff-8d79-07924348f0a5 SaddleItem set value ""
/data modify entity f4d501d5-adc6-4bff-8d79-07924348f0a5 SaddleItem set value {id:""}
/data modify entity f4d501d5-adc6-4bff-8d79-07924348f0a5 SaddleItem set value {id:"",Count:0b}
/data modify entity f4d501d5-adc6-4bff-8d79-07924348f0a5 SaddleItem set value {id:"",Count:0}

Other things that don't work: {} {id:"\"\""}

So it's a workaround for some cases, but not all I'm afraid.

kcrca

Following up, I have found that my specific problem about saddles can be solved using the /item command, as in:

/item replace entity @e[tag=armor_horse] horse.saddle with air

For some reason, there is no "remove" subcommand of item

This is not a general answer, it only works for attributes that are supported in the item command, but it's a workaround for some cases.

Avoma

Requesting ownership of this ticket since the current reporter has been inactive since May of 2019. I'm willing to keep this report updated and will continue to provide all of the necessary information. 🙂

Avoma

Can confirm in 1.18.1.

Avoma

Can confirm in 1.18.2 and 22w13a.

Avoma

Can confirm in 1.19.

PvPqnda

Just stumbled upon this bug myself. Made me very confused as to why my functions weren't working properly for a couple days before I realized this command simply just wasn't working. But I've found for the time being, an easy fix is instead of running /data remove entity @s CustomName, use /data modify entity @s CustomName set value ''

migrated

Can confirm in 1.19.1 Pre-release 4.

migrated

Can confirm in 1.19.1 Release Candidate 2

migrated

Can confirm in 1.19.1

migrated

Can confirm in 1.19.2 Release Candidate 1

migrated
Lunarian

Can confirm in 23w43a / 1.20.2: requesting ownership to make it easier to update (the OP has been inactive since 05/2019).

 

migrated

This is now a crucial problem I think.
Removing CustomName is now outright impossible to do due to MC-267259

[Mod] turbo

@unknown: Stop reposting information that adds nothing new to the report. Everything you have to say has already been said (MC-267259 included), and every comment sends unnecessary email notifications to watchers.
Yes, MC-267259 is a thing, and is working as intended, and yes, this issue (MC-128225) is a more important problem now, as already stated by @unknown in this comment. That's why the Mojang Priority for this ticket has been bumped from "Low" to "Important".

Nico4play

[Mod] Turbo I get It. I was just trying to get a reason why my messages were removed. Thank you for explaining

Nico4play

Can confirm in 24w06a

Rob23

Just did a quick code analysis and it seems like this bug could be solved like this:

net.minecraft.world.entity.Entity

public void load(CompoundTag tag) {
    // ...
    if (tag.contains("CustomName", Tag.TAG_STRING)) { // Existing code, line 1933
        String text = tag.getString("CustomName");
        try {
            setCustomName(Component.Serializer.fromJson(text));
        } catch (Exception ex) {
            LOGGER.warn("Failed to parse entity custom name {}", text, ex);
        }
    } else { // Fix
        setCustomName(null);
    }
    // ...
}

A similar fix can also be applied to other places, specifically command blocks, containers, beacons, banners and enchanting tables.

An alternative way would be to make a method dedicated to retrieving a custom name, with the same code as above, that returns the custom name.

The fix comes from removing the custom name if the tag is not present. Through testing, this seems to work as expected, /data remove does remove the custom name, other types of changes also don't cause any issues.

Nico4play

Can confirm in 24w07a and 24w09a

Nico4play

Can confirm in 24w10a, 24w11a, 24w12a and 24w13a

migrated

This still exists all the way up to 1.20.5 Prerelease 3.

migrated

Still exist in 1.20.5-rc1.
It seems like we won't be able to remove custom names for 2 versions in a row after having been able to in another way since 1.13. Ouch.

migrated

Still exists in 1.20.5-rc2.

migrated

Sadly, this is still the case in Release 1.20.5.

migrated

Still exists in 1.20.6-rc1. Is this even a critical bug?

Charlotte Eiffel Lilith Buff

Confirmed in 1.21.2

Charlotte Eiffel Lilith Buff

Confirmed in 1.21.3

Lunarian

slicedlime

Confirmed

Platform

Important

Commands

commands, nbt

Minecraft 18w14b, Minecraft 18w15a, Minecraft 18w16a, Minecraft 18w22c, Minecraft 1.13-pre1, ..., 24w21b, 1.21, 1.21.1, 1.21.2, 1.21.3

1.21.4 Pre-Release 1

Retrieved