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
Place an armor stand
Rename it with a name tag
Use the following command:
/data merge entity @e[type=minecraft:armor_stand,limit=1,sort=nearest] {CustomNameVisible:1}
Linked issues
is duplicated by 3
testing discovered 1
Attachments
Comments 50
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.
/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?
The bot thing is not silly, because it fixed your mistake.
Renaming armor stands by name tags was never possible.
Not fixed, reopened.
They are renamed (use /say @e[type=armor_stand]), but the CustomNameVisible tag is not set to true.
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 }=)
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.
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 |
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).
Not too complicated I think, looking that it already does so for PersistenceRequired for every mob.
@@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.
Not fixed for me.
It's not marked as fixed. :/
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.
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.).
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.
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.
@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.
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 😉
A good solution here, IMO would be to have CustomNameVisible:0b on armor stands behave like it does with mobs.
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:
Invisible mobs don't render the name either.
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.)
Can confirm for MC 1.12.1.
Confirmed 18w02a
Confirmed in 18w07c.
Affects 1.13 and 1.13.1-pre1.
Confirmed for 18w49a.
Confirmed for 19w03c.
Confirmed in 1.15.2 and 1.16 Release Candidate 1.
Present in 20w28a.
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}Can confirm in 21w03a.
Can confirm in 21w05b.
Can confirm in 21w06a.
Can confirm in 21w07a.
Video attached.
Can confirm in 1.17.
Actually you should not name an armor stand due to @unknown's comment in MC-66058.Â
Can confirm in 21w40a.
Can confirm in 1.18.1.
Can confirm in 1.18.2.
Can confirm in 1.19.
Can confirm in 1.19.2.
Can confirm in 23w03a.
Can confirm in 1.20.4
confirmed in 1.20.6
affects 1.21
affects 1.21.3
Use
while standing within 5 blocks of the armor stand you want to change.