MulverineX
Assigned
Reported
MC-277010
`stepping_on` check in `entity_properties` predicate is incorrect when sharing the same coordinate as a partial block
Awaiting Response
MC-276817
Teleport command offsets are applied incorrectly
Fixed
MC-260591
'execute on origin' and 'execute on owner' fail to find the targeted entity when it is in a separate dimension
Fixed
MC-260590
Multiple entities can have the same UUID when in different dimensions
Duplicate
MC-259462
Parrots do not exist in the world when on the player's shoulders
Duplicate
MC-117222
Advancement triggers are inconsistently named
Confirmed
MC-94270
[Graphical Glitch]Weird red dots
Incomplete
Comments
Related bug: https://bugs.mojang.com/browse/MC-276755
Command/datapack users/map-makers need a reliable way to detect whether the player is colliding with a block, regardless of if they're in a special state like being teleported, if this bug is resolved using the same code path as {{is_on_ground}} then we're back to square one. Due to the inefficient nature of commands, being forced to do our own collision math is quite a burden and ideally could be avoided.
For those trying to find a workaround for this, stepping_on air actually works, so all you have to do is invert or unless it. Turns out it has it's own issues
Editing entity nbt is not a valid alternative for this due to prohibitively high performance cost. We need a way to change entity rotation without dismounting the entity, please reverse this decision.
while of course we'd appreciate a fix to this bug, a better resolution would be a proper way to receive player input values & events, and if that means waiting another snapshot cycle or 2 the commands community would rather have a more polished/intentional method, as NBT access is bad.
A great fix for this that would avoid creating a global entity list would be to add the same logic from SingleEntityArgument to the getOwner methods (that searches all entity lists for a UUID if that is inputted).
This probably effects most if not all of the `<relation>` types, `on origin` is just the one I've tested
Related bug report: https://bugs.mojang.com/browse/MC-260591
The problem is that the area effect cloud's set & get methods for its owner require that the entity is living, despite there being no place in the code where `LivingEntity` specific class members are used for the AEC's owner.
[media]The ideal solution here would be to remove the instance check, remove the `LivingEntity` type cast, and swap the types to `Entity` instead, therefore letting us set the owner to any entity, and use `execute on origin` to access it.
A workaround for flower pots (would need some work for a survival implementation, and you have to wait till something's in the pot)
Armor stand position can be adjusted to make it work for any of these blocks that are affected.
Link: https://pastebin.com/raw/m4qBS0MF
Notes:
<x y z> being the coords of the flower pot, must be run in a command block because of length
command in pastebin because Jira formatting is dumb
Belongs in Console Edition Section until bedrock bug tracker is introduced. This is the Java bug tracker.
Description is updated and simplified, a new attachment is added