Before 16w38a, Passengers of an AS with Marker-tag set to true were at the BOTTOM of the AS (the AS was stuck inside the Passenger, see pic with creeper as example).
Now Marker-true-AS got their Passengers at the top, which might mean huge problems for mapmakers who frequently use invisible Marker-AS with Passenger-entities for their maps or at least for some of their CB inventions/contraptions.
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.
Steps to reproduce
1. Summon as example a Creeper as Passenger of a Marker-AS:
/summon armor_stand ~ ~1 ~ {NoGravity:1b,Marker:1b,Passengers:[{id:"creeper",NoAI:1,Silent:1}]}2. Look at it in e.g. 16w39c and 16w36a to see the difference very well.
As this could be a concern for mapmakers, please fix this BEFORE 1.11 OR add an alternative for 1.11, e.g. offset-possiblity or a designated new simple invisible marker entity (see Suggestions below).
If this gets fixed or reverted to its old state, please keep other fixes for AS that were already done or are currently in the making.
Screenshots attached.
Suggestions
I just read it again in the comments and heard it also by other mapmakers/CBers since longer:
A possible solution would be to give us an offset-possibility for Passenger-Entities on AS, preferrably also all the other entities, without having to use relative-tps or the likes.
This would maybe also start a change in the thinking of the CB community who still use AS due to them being the "old safe known method" and would maybe make them more comfortable in using alternatives like an AEC.
Another possibility could be to add a completely new Marker entity, a simple, invisible Marker.
The "workarounds" we use currently like Armor Stands and Area Effect Clouds do work, of course, but a real designated simple Marker entity would be great to have.
Sadly new implementations often need time (incl. testing+bugfixing), and apparently 1.11 is already feature-ready, which means a release could be near. That means either this bug will be fixed or gets resolved as "works as intended" before 1.11 release, and CBers will have to change their maps/inventions accordingly, or this bug will still be open after 1.11 release, and if in 1.11.x or 1.12 an offset-possibility and/or a new designated marker-entity will be added OR this bug here will be fixed, that'd possibly mean the CBers will have to change their maps/inventions yet again.
We can wait to change our commands and for fixes or new implementations as long as we know about when and that we will get them at all. But for the sake of the community and the Devs.it should be avoided, if possible, to have us everything changed for 1.11 and shortly after we'll have to change everything again.
It'd be really kind if Mojang could be a bit open in which direction they want to go, even if they currently don't have the time to fix or add anything before 1.11 release, so we can plan when or if to update commands related to this Marker:1-change at all.
Thank you!
Linked issues
Attachments
Comments 6
This is bad because map makers will have to deal with extra hitboxes in the way of their NPC's which use marker armorstands. If a user needs to be able to place blocks below the npc for a map, it is ruined becuase the marker armorstand has a hitbox
Seems intentional. It just relies on the visual appearance of the entity, instead of the collision hitbox. If people need a zero-height stackable marker entity to use in mobs, they can always use an AreaEffectCloud. If anything, this adds an extra useful feature without taking anything away. It might break some old stuff, but so will the rest of 1.11.
...That is, of course, assuming the new hitbox doesn't interact with things. I'm not in a position to test right now but I'll give it a go tomorrow.
@unknown That's the thing: The hitbox is no longer on the feet of the AS, it now has a real hitbox.
@unknown This part is not true. If you had played around with the marker armor stand's hitbox, you would have noticed that this hitbox is not a hitbox you can interact with. Meaning: You can still place blocks inside of the armor stand, press buttons through it, etc.
@unknown I agree with the use of AEC as marker entity since they're less laggy. Unfortunately, they are not zero-height stackable. I would be really happy if they marked this bug as WAI and made AECs zero-height stackable instead.
Ah, I always assumed they were. That's what I get for not testing. That does seem like a reasonable solution, since the hitboxes don't interact with anything. Preserves consistency and allows for anything done pre-change to also be done post-change.
Related to MC-96863
michael
The Entity should appear on the same level as them for Marker for several reason. One reason being that there is already an option to have an entity above an ArmorStand and that is the normal ArmorStand. Another reason is that it would more consistent with the hit-box being on the feet of the ArmorStand. Maybe an option to fix this is have an offset tag with riding like with minecarts holding blocks.