Marker armor stand does not render in some cases
The bug
Marker armor stands, due to their hitbox being tiny and the new rendering methods being based on the hitbox location (I presume), cause them to easily stop rendering.
How to reproduce
/summon armor_stand ~ ~ ~ {Marker:1b}- Stand close to it and slowly look up
- Armor stand stops rendering / disappears
Linked Issues
is duplicated by7
MC-130007Marker Armor stands disappear if you look upDuplicateMC-131372Standing in same block as marker armor stand while looking at it directly at eye level causes it to disappearDuplicateMC-156826Marker Armor stands become invisibleDuplicateMC-188917Armour stands with the marker tag disappearDuplicateMC-190321Armor Stands with the Marker tag stops rendering in certain player rotationsDuplicateMC-190699Marker tag changes the rendering of armor standsDuplicateMC-269604Armor stands with the Marker tag render incorrectly in certain viewing angles.Duplicaterelates to4
MC-96853Large block models stop rendering prematurely on ArmorStands/Entities when leaving player's field of view. (e.g.: Dragon Head on ArmorStand)Won't FixMC-1058A dragon head is invisible if the entity wearing it is not in viewFixedMC-106512Ghast is not rendered when its hitbox is not on screen
LowMC-107172Hitbox of Marker "true" Armor Stands lets their names now appear above themFixed
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
- Unresolved
Onnowhere- 63
- 24
- Confirmed
- Low
- Platform
- Rendering
- armor_stand
1.9-pre4 - 1.21.4
1.9-pre4 1.9 1.9.1-pre1 1.9.1-pre2 1.9.1-pre3 1.9.1 1.9.2 1.9.3-pre2 1.9.4 16w20a 16w21a 16w21b 1.10-pre1 1.10-pre2 1.10 1.10.1 1.10.2 16w32a 16w32b 16w33a 16w35a 16w44a 1.11 1.11.2 17w15a 17w16a 1.12-pre2 1.12-pre6 1.12-pre7 1.12 1.12.2 17w48a 17w49b 18w20c 1.13-pre3 1.13-pre6 1.13-pre7 1.13.2 18w50a 19w09a 19w12b 19w13b 19w14a 19w14b 1.14.3 1.15-pre2 1.15-pre4 1.15.2 20w08a 1.16-pre4 1.16-pre8 1.16-rc1 1.16 1.16.2-pre3 1.16.3 1.16.4-pre2 1.16.4 20w48a 21w03a 1.16.5 21w05b 21w06a 21w07a 21w11a 21w14a 21w17a 1.17 1.17.1 1.18.1 1.18.2 22w15a 1.19 1.19.1 1.19.2 22w42a 1.19.3 1.20.1 1.20.4 24w11a 1.21.4- 16w38a
Created Issue:
Marker Armor Stand Does Not Render In Some Cases
Marker Armor Stands, due to their hitbox being tiny and the new rendering methods being based on the hitbox location (I presume), cause them to easily stop rendering.
To Test:
1. /summon ArmorStand ~ ~ ~
{Marker:1b}2. Stand close to it and slowly look up.
3. Armor Stand stops rendering.
Attachments2
![[Mod] redstonehelper](../../../data/avatars/users/10122.svg){kind=small}
Marker Armor Stands, due to their hitbox being tiny and the new rendering methods being based on the hitbox location (I presume), cause them to easily stop rendering.
To Test:
1. /summon ArmorStand ~ ~ ~
{Marker:1b}2. Stand close to it and slowly look up.
3. Armor Stand stops rendering.
relates to
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
Marker Armor Stands, due to their hitbox being tiny and the new rendering methods being based on the hitbox location (I presume), cause them to easily stop rendering.
To Test:
1. /summon
{Marker:1b}ArmorStand ~ ~ ~2. Stand close to it and slowly look up.
3. Armor Stand stops rendering.
Marker Armor Stands, due to their hitbox being tiny and the new rendering methods being based on the hitbox location (I presume), cause them to easily stop rendering.
To Test:
1. {{/summon armor_stand ~ ~ ~
{Marker:1b}}}
2. Stand close to it and slowly look up.
3. Armor Stand stops rendering / disappears.
Marker Armor Stands, due to their hitbox being tiny and the new rendering methods being based on the hitbox location (I presume), cause them to easily stop rendering.
To Test:
1. {{/summon armor_stand ~ ~ ~
{Marker:1b}
}}2. Stand close to it and slowly look up.
3. Armor Stand stops rendering / disappears.
Marker Armor Stands, due to their hitbox being tiny and the new rendering methods being based on the hitbox location (I presume), cause them to easily stop rendering.
To Test:
1.
/summon armor_stand ~ ~ ~ {Marker:1b}2. Stand close to it and slowly look up.
3. Armor Stand stops rendering / disappears.
Marker
ArmorStands, due to their hitbox being tiny and the new rendering methods being based on the hitbox location (I presume), cause them to easily stop rendering.To Test:
1.
/summon armor_stand ~ ~ ~ {Marker:1b}2. Stand close to it and slowly look up.
3. Armor Stand stops rendering / disappears.
The bug
Marker armor stands, due to their hitbox being tiny and the new rendering methods being based on the hitbox location (I presume), cause them to easily stop rendering.
How to reproduce
/summon armor_stand ~ ~ ~ {Marker:1b}- Stand close to it and slowly look up
- Armor stand stops rendering / disappears
MarkerArmorStandDoesNotRenderInSomeCasesMarker armor stand does not render in some cases
is duplicated by
relates to
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
is duplicated by
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
![[Mod] Asteraoth](../../../data/avatars/users/92886.png){kind=small}
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
is duplicated by
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Helper] Johnibur](../../../data/avatars/users/28381.png){kind=small}
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
relates to
![[Mod] Jarl-Penguin](../../../data/avatars/users/92849.png){kind=small}
![[Helper] Jack McKalling](../../../data/avatars/users/92859.png){kind=small}
is duplicated by
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
in 1.19.2.png
![[Helper] osfanbuff63](../../../data/avatars/users/94394.png){kind=small}
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
is duplicated by
MC-1058 fixed indeed the issue that most entities cannot be seen when on the edge of the screen, but from my testing it seems that only applies to mobs/living entities and normal-sized blocks on ArmorStands.
On an ArmorStand with a large model on headslot though this rendering bug still occurs, both at edge of screen as well as frontal (when you look upwards), depending on block model.
Summon command for dragon head on ArmorStand headslot:
/summon minecraft:armor_stand ~ ~ ~ {ArmorItems:[{},{},{},{id:stone,Count:1}]}
It also affects self-made models, see screenshots and attached test-resourcepack by [Mod] NeunEinser
This bug is important for mapmakers to be fixed before 1.9 release.
Two other things important to mention:
*Do not test on Y = 63* if you want to confirm it.
There is a (confirmed it by testing) bug that renders any entity (or the blocks attached to them) invisible if you're at Y= 63.
I'm not sure if this bug here can relate to it, but I'll leave the according bugpost in here to be safe, maybe you can fix it alongside this bug here:
MC-88176
*Do not test with ArmorStands that have their Marker-tag set to true*
I don't know whether or not it's "works as intended", but even regular-sized blocks vanish at certain perspective angles (sideways as well as looking up) if they're at an ArmorStand with Marker-tag set to 1. (Screenshots attached).
*It would be nice to know if this is intended behaviour* or - at least currently - not fixable, because I could think about some circumstances where it'd be nice to have an ArmorStand with Marker-tag set to true, but without the model/block "vanishing" out of sight of the player, dependant on their perspective.
*If this is maybe even a desired behaviour is up to Mojang and suggestions of the mapmaking community* - So i hope someone could comment on that.
If this is not intended behaviour and fixable, please fix it alongside with this bug.
Onnowhere opened a bugpost for this here on MC-98146
I suspect this might happen with any larger-scaled model, also selfmade models, I couldn't confirm that yet but will do so with according screenshots.
If any modelmakers read this and could test it themself with a largescale model on an ArmorStand headslot to confirm it via a comment and screenshot, I'd be very thankful }=)
Thank you.
[Mojang] Grum (Erik Broes) I don't know how I shall interpret that.. That's exactly the thing, it'd be great if the entity wouldn't stop rendering as long as a bit of it is within the field of view of the player, and that's what is happening here, the entity, e.g. an ArmorStand (without true Marker) with equipment does not render that equipment although it's still within the screen/field of view of the player.
It has gotten way better than in the beginning at the very least, so if it can't be fixed any better than what we've got currently, then we'll have to live somehow with it.
Edit: I didn't have the time yet to test it in 16w32a myself, will do some tests after work; if the entity gets rendered whereas its equipment doesn't, I'll post it to Mojira-Reddit with the hope maybe something can be still done about it, if one sees some examples.
Just a quick feedback note from other map and concept makers:
They see it as important that a large model (or any equipment) can be displayed despite the entity not being rendered, if it's possible code-wise, for better immersion of the player.
One thing I find very important (which I also mentioned in the bugpost):
I hope it's possible to make Marker:1b-Armorstands render their equipment at any time, because that'd be very much important for mapmakers, as it breaks immersion of players in maps greatly when it stops rendering its equipment: MC-98146
Thank you }=)
PS: Opened a Redditpost for further discussions about that topic, without knowing of course currently if having equipment on an entity being visible despite that entity not being rendered.
While checking if the bug MC-98146 still persists, I found that MC-98146 is fixed - apparently.
I don't know if that was intended and has anything to do with e.g. changes made for MC-86164 but I wanted to state it, so that the fix for MC-98146 could be kept (even if it was not intentional), and any changes to Armor Stands, e.g. due to MC-86164, that still have to be made, would not cause the apparent bugfix for MC-98146 to vanish again, as Marker-true-AS rendering their equipment from ALL angles (like Marker:false AS) is very benefitting for the mapmaker-community.
Before 16w38a, the name of AS with Marker-tag set to true is at the BOTTOM of the AS - now when I entered my bugpost-testworld, I found all my Marker-true-AS got their name changed to at the top, like also Marker-false-AS.
Apparently this is caused by Marker-true-AS also now having a hitbox, unlike before 16w38a, and apparently this hitbox was needed in order to fix other AS bugs.
(Pics attached).
I summoned another Marker-true-AS in 16w38a to confirm that the name will appear also at the top, not feet anymore and checked that it is indeed a Marker-true-AS after summoning via
/entitydata @e[type=armor_stand,r=2] {}
Summon command:
/summon armor_stand ~ ~1 ~ {CustomName:"Marker True",CustomNameVisible:1,Marker:1b,ArmorItems:[{},{},{},{id:skull,Damage:3,Count:1,tag:{display:{Name:"Meri"},SkullOwner:Meri}}]}
If more issues occur due to the AS change, I'll add them of course.
Relates to MC-108008 "Hitbox of Marker:1 Armor Stands lets Passengers appear now ABOVE them"
As for MC-98146: Please do not mark it as "Resolved", until it's sure that the above mentioned change is wanted or why it changed at all.
(Edit: Marked as fixed now, but I really really would love to have a confirmation it was an intentional fix which got simply forgotten to be resolved as fixed by the fixing Dev.)
Suggestion As stated already in MC-108008
A possible solution would be to give us an offset-possibility, e.g. also for/including the displayed custom names on AS.
In MC-108008 the offset-possiblity would apply to the positioning of a passenger-entity as well.
No it did not for Marker-true-AS, if you look at it from certain angles. That's why MC-98146 got entered as bugpost (I already mentioned it in my resolved as WaI-bugpost MC-96853, I quote:
| Do not test with ArmorStands that have their Marker-tag set to true I don't know whether or not it's "works as intended", but even regular-sized blocks vanish at certain perspective angles (sideways as well as looking up) if they're at an ArmorStand with Marker-tag set to 1. (Screenshots attached). |
and that's when Onnowhere made a bugpost out of it, which is MC-98146
Whatever the reason is, the question remains whether that change was intentional, as well as whether MC-98146 was an intentional fix (and if not, please figure what it fixed and keep it), and if mapmakers could have a problem with the changed display of a custom name if it's visible (which I doubt, as they are most likely to use the Tags tag for targetting the AS nowadays, like already mentioned, and they could use an additional entity for a name display at AS-feet height, if they have to).
Also, if Marker-true-AS having a hitbox now could cause a problem in any way, as being "interactable" which they shouldn't be. I couldn't get them to e.g. being pushed yet by pistons (MC-100398), but I'll keep an eye on it when I got more time 
efraim bring What you mean is probably MC-98146, if you want to follow that specific bug
Duplicate of MC-98146
I meant MC-98146 and copied the wrong id, apologies.
![[Mod] j_p_smith](../../../data/avatars/users/92851.png){kind=small}
Related to MC-98146.
Thank you for your report!
We're tracking this issue in MC-98146, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! Please report any issues on Discord or Reddit
Thank you for your report!
We're tracking this issue in MC-98146, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Already mentioned in
MC-96853, but probably it's better to have a separate ticket for itConfirmed, like already mentioned in
MC-96853I'm assuming using a Marker-tag set to true is what mapmakers do more often than leaving it to false.
Thus, if it's possible to fix, and nobody of the mapmaking community can present reasons why it must not be fixed, it'd be great if it could be fixed before 1.9 release.
Confirmed for 1.9.1 Release.
Confirmed for 1.9.3 pre-2.
Confirmed for all previous versions I didn't confirm it for in here, up to/incl. the current 16w21a.
Confirmed for 16w21b.
Confirmed for 1.10 pre-2 + pre-1.
Confirmed for 1.10.1
Confirmed for 1.10.2
Confirmed for 16w32a.
Confirmed for 16w32b.
Confirmed for 16w33a.
Confirmed for 16w35a.
Confirmed in 16w36a, but apparently fixed for 16w38a?
Please do NOT mark this bugpost here as fixed rightaway, please read:
MC-107172If it's fixed, it's fixed, we'll reopen the bug if it reoccures in a later version.
(And before you ask, yes, I did read the ticket)
The reason why I'm so cautious and say "please do not resolve it as fixed" is that it doesn't seem to be intended - okay, Devs not always assign themselves to a bugpost when they fix it, but at the least they MARK it as fixed, and it wasn't done here.
So my assumption/fear is that whatever got changed UNINTENTIONALLY fixed this bugpost here, and I just want to make sure that it does not reoccur, and the Dev can look into what he changed and thus figure out the reason for the fix, so it:
a) won't happen again and
b) he/she doesn't have more work, as they might have to search more after a while, when it reoccurs, and they maybe forgot what they did that it unintentionally fixed.
A lot of times bugs are fixed without a dev marking them as such, simply by forgetting or not finding the ticket.
Don't worry too much about it, if it changed for the good, it's likely intentional.
Okay.. ;-;
I'm just scared it is not an intentional fix and we'd lose it again }xD
This fix is GREAT for the mapmakers, if it is intentional they totally should have bragged with it in the post and not forget it!
It's very much needed for better player immersion with also e.g. large block models etc.
I'll be cautiously happy now.. will blame you if it reoccurs };]
Due to the fixes of other armor stand related bugs, this issue is back in 16w44a.
Can confirm for 1.13-pre3
Happens in the latest snapshot (19w09a).
Confirmed it's still happening in 1.16.3. Really hoping this ever gets fixed again.
Can confirm in 20w48a.
Can confirm in 1.16.4
Can confirm in 21w03a.
Can confirm in 21w05b.
Can confirm in 21w06a.
Video attached.
Can confirm in 21w07a.
Can confirm in 21w11a.
Can confirm in 1.16.5 and 21w14a.
Can confirm in 21w17a.
Can confirm in 1.17.
Can confirm in 1.17.1.
Can confirm in 1.18.1.
Can confirm in 1.18.2 and 22w15a.
Can confirm in 1.19.
Can confirm in 1.19.1
Can confirm in 1.19.2.
Can confirm in 1.19.3.
Can confirm in 1.21.4.