mojira.dev
MC-86164

When renamed with a name tag, armor stand will not show the nameplate above its head until CustomNameVisible:1b is set

The bug

When renamed with a name tag, armor stand will not show the nameplate above its head until CustomNameVisible:1b is set.

To reproduce

  1. Place an armor stand

  2. Rename it with a name tag

  3. Use the following command:

    /data merge entity @e[type=minecraft:armor_stand,limit=1,sort=nearest] {CustomNameVisible:1}

Linked issues

Attachments

Comments

Ezekiel

Use

/entitydata @e[type=ArmorStand,r=5] {CustomName:"Name Here"}

while standing within 5 blocks of the armor stand you want to change.

[Bot] Arisa

Please do not mark unreleased versions as affected.
You don't have access to them yet.

--- I am a robot. This action was performed automatically.

Eldar

/entitydata @e[type=ArmorStand,r=5] {CustomName:"Name Here"}
Thx, I know this command, but that doesn't change, that you can't rename an armor stand with a name tag as you could before (and should be able to).

Also this bot-thing is silly. Why do we have access to this version number in the affected versions list, when we aren't supposed to mark it with it?

Ezekiel

The bot thing is not silly, because it fixed your mistake.

kumasasa

Renaming armor stands by name tags was never possible.

user-f2760

Not fixed, reopened.

marcono1234

They are renamed (use /say @e[type=armor_stand]), but the CustomNameVisible tag is not set to true.

Meri Diana

Exactly, command-wise, if you want an ArmorStand to have its name displayed, you'd have to use something like:

/summon ArmorStand ~ ~1 ~ {CustomName:"This is my Name",CustomNameVisible:1b}

1.11+:

/summon armor_stand ~ ~1 ~ {CustomName:"This is my Name",CustomNameVisible:1b}

If you use instead

/summon ArmorStand ~ ~1 ~ {CustomName:"This is my Name"}

1.11+:

/summon armor_stand ~ ~1 ~ {CustomName:"This is my Name"}

the Custom name will not be visible.

Which ultimately means, if an ArmorStand gets renamed via a nametag, together with that nametag-renaming it would have to have automatically applied something like

/entitydata @e[type=ArmorStand] {CustomNameVisible:1b}

1.11+:

/entitydata @e[type=armor_stand] {CustomNameVisible:1b}

to make the name visible.

In my personal opinion the ArmorStand should not be changed that the custom name is visible per default though, to fix this issue..
Although mapmakers nowadays very likely use the Tags tag rather than a custom name to target the ArmorStand, I feel it wouldn't be a good solution, as it'd require them then to change all AS with a name to "CustomNameVisible:1b" instead, in case they did give the AS a custom name and if it would default to visible:true in the future to fix this bugpost.. but that's just my opinion, maybe I'm just too cautious here }=)

Edit: Of course, change the above commands into the new "armor_stand" instead of "ArmorStand", sorry, it's still "in my fingers" };]

Sorry, edit again: If it would be an easy+quick fix to have AS automatically equipped with "CustomNameVisible:1b" when placed down already, would it be maybe possible to only have newly placed AS have it, and leave old AS, placed before 1.11+, untouched? Then mapmakers wouldn't have to maybe change their customly-named AS in their maps, but Survival could have a nametag-AS-rename, which would be great }=)

user-f2760

A fix for this without breaking above mentioned issue is set it to true once the name tag is used (like it also sets PersistenceRequired) for armor stands only.

Meri Diana

Exactly, that's what I meant with:

if an ArmorStand gets renamed via a nametag, together with that nametag-renaming it would have to have automatically applied something like

entitydata @e[type=ArmorStand] {CustomNameVisible:1b}

Sorry if I worded it too complicated };]

If it is possible to do so, that'd be the best solution.

What I additionally mentioned as second solution was just for the case that it would not be easily possible code-wise to set CustomNameVisible automatically to true if renamed by a name-tag, which I don't know (how complicated it would be).

user-f2760

Not too complicated I think, looking that it already does so for PersistenceRequired for every mob.

marcono1234

@@unknown

Sorry, edit again: If it would be an easy+quick fix to have AS automatically equipped with "CustomNameVisible:1b" when placed down already, would it be maybe possible to only have newly placed AS have it, and leave old AS, placed before 1.11+, untouched?

Setting the tag CustomNameVisible to true when the player right clicks the armor stand with a name tag is probably the way they choose to fix it. There is no reason why it should affect all armor stands. As this is a snapshot there is no need for a data fixer to change the CustomNameVisible tag for existing armor stands, which means there is probably nothing to worry about.

FaRo1

Not fixed for me.

user-f2760

It's not marked as fixed. :/

marcono1234

Thinking about it, it is probably better if armor stands with a CustomName but CustomNameVisible:0b would show their name when the player is pointing at them like it is right now with mobs.

Meri Diana

As long as an AS showing its name despite CustomNameVisible:0 would not affect Creative/mapmaking?

If CustomNameVisible would not be changed to "1" but instead remained "0", wouldn't that mean some additional tag would have to be added to the AS, some sort of "nametagged:0/1" in order to differentiate between a CustomNameVisible:0, but nametag-renamed AS which would show its name upon a player looking at it, and those named AS summoned by a command with a CustomNameVisible:0 which would continue not to show their name although it exists?

Like I said in a previous comment, nowadays many mapmakers surely use mainly the Tags tag on AS, but just to be safe, in case some have to also use named AS for their maps/creations but do not want the name to be displayed, it must be sure that for them a CustomNameVisible-false-AS does not show its name if one looks at it, unless it was rightclicked with a name tag by a Player.

Come to think of it, maybe it'd be also good for mapmakers/Creative to implement a restriction that nametagging an AS would not be possible at all, e.g. for maps which make use of named AS, and in case the Player of the map could get a hold of a name tag, it could cause problems for the map, if stuff relies also partially on the AS' name?
That would go for all entities though, now that I think more about it.

Just a thought, I currently don't know if it's really that risky for mapmakers nowadays (thanks to the Tags tag and the possibility for a mapmaker to remove nametags in the map etc.).

marcono1234

As long as an AS showing its name despite CustomNameVisible:0 would not affect Creative/mapmaking?

You are right. That is kind of awkward. With CustomNameVisible:1b it would need to be visible all the time for consistency but that would be inconsistent with mobs and would be very irritating.

Meri Diana

I'm usually all for consistency, but sometimes, for some instances, I feel it would not hurt to not pull through with consistencies every time.

For Survival, I personally would find it annoying if the name of an AS would show the whole time even by not directly looking at it, if I'd have many nametagged AS and their names would be overlapping optically the whole time, but that's personal preference, and I could imagine it being very useful for some Servers.

user-f2760

@unknown setting CustomNameVisible to 1b/true will render the name everywhere again since 1.9 or something and CustomNameVisible 0b/false still functions the way it did before.

Meri Diana

Oh really? Since 1.9? Now I'm confused 😃 I didn't catch them reverting that again then, I only use AS with their name visibility set to 0 since 1.9, and before 1.9 with visibility on.
Scratch then what I wrote 😉

user-f2760

A good solution here, IMO would be to have CustomNameVisible:0b on armor stands behave like it does with mobs.

Meri Diana

That's what Marcono said, but it would affect Creative as well then or not?
If I make an AS creation which needs named but invisible AS, then the player could see their name if they look at it?
I mean with AS creation something like this:

[media]

user-f2760

Invisible mobs don't render the name either.

Meri Diana

As long as that would stay/be the same for invisible AS, then it should be cool I guess 🙂
I personally can currently not think of a mapmaker AS creation with visible, renamed AS where this could become a problem.

(Sorry for comment spam to the bugpost watchers and mods, I know this is not a discussion forum.)

bemoty

Can confirm for MC 1.12.1.

user-2a4c8

Confirmed 18w02a

Aaron Rhodes

Confirmed in 18w07c.

Elemend

Affects 1.13 and 1.13.1-pre1.

Meri Diana

Confirmed for 18w49a.

Meri Diana

Confirmed for 19w03c.

j_p_smith

Confirmed in 1.15.2 and 1.16 Release Candidate 1.

user-69bf7

Present in 20w28a.

Avoma

Can confirm in 20w51a. You can use the following command once you've applied the nametag to see this bug in action.

/data merge entity @e[type=minecraft:armor_stand,limit=1,sort=nearest] {CustomNameVisible:1}
Avoma

Can confirm in 21w03a.

Avoma

Can confirm in 21w05b.

Avoma

Can confirm in 21w06a.

Avoma

Can confirm in 21w07a.

Avoma

Video attached.

Avoma

Can confirm in 1.17.

Kai Maldonado

Actually you should not name an armor stand due to @unknown's comment in MC-66058. 

ampolive

Can confirm in 21w40a.

Avoma

Can confirm in 1.18.1.

Avoma

Can confirm in 1.18.2.

Avoma

Can confirm in 1.19.

Avoma

Can confirm in 1.19.2.

SoloAlguien

Can confirm in 23w03a.

MukiTanuki

Can confirm in 1.20.4

MukiTanuki

confirmed in 1.20.6

MukiTanuki

affects 1.21

MukiTanuki

affects 1.21.3

Eldar

(Unassigned)

Confirmed

Platform

Normal

Entities

CustomNameVisible, armor_stand, name_tag

Minecraft 15w33b, Minecraft 15w33c, Minecraft 16w38a, Minecraft 16w42a, Minecraft 1.11.2, ..., 23w41a, 23w43a, 1.20.4, 1.21, 1.21.3

Minecraft 16w38a

Retrieved