In 1.21.2+, any entity going through a portal with over 10 blocks/gametick of motion will have their Motion tag reset, same as a chunk reload
In 1.21.1 and lower, the entities keep motion and continue moving after teleport, which I assume is the intended behaviour.
Steps to reproduce:
Create an entity, i.e. a boat
Move the entity at >10b/gt with ie cramming collision from >200 of an entity (this can be easily done by i.e stacking 200+ boats 1 block away from a portal, and dispensing a boat inbetween to have it get motion and teleport instantly
Teleport the entity with a nether portal, all motion will be reset
This change is caused by a change in how portals are handled by entities, in mojmap:
1.21.1:
Entity::handlePortal() method calls changeDimension() method which contains
entity3.setDeltaMovement(dimensionTransition.speed());which correctly copies entity movement data after teleport
in 1.21.2+ code (including 1.21.8) there is no restoration of the movement data in any method called by handlePortal()
Due to this bug, any sort of cannon or contraption relying on entity motion staying the same after portal movement is irreparably broken, would be highly appreciated if this can be fixed
Environment
Minecraft Java 1.21.8, vanilla
CPU Ryzen 9 9900X
GPU 6900XT
OS: Debian 13
Linked issues
Attachments
Comments 7
what makes this inconsistent is cannons that are single dimensional have 0 issue using high motion work fine in it, but when the entity needs to be moved through portal (i.e. chestboat cannons) this breaks them
i will update reproduction steps
Ok after a good bit of effort I managed to make a robust testing setup:
The button is connected to an upwards-facing dispenser under the water, and the command blocks are as follows:
Killer: kill @e[type=minecraft:bamboo_raft,distance=..10]
Summoner: execute positioned ~ ~ ~1.9375 summon minecraft:bamboo_raft if entity @e[type=minecraft:bamboo_raft,distance=..1] (this way the number of boats you just worked with remains stored in the output field after you reset, until you start again)
Counter (from bottom):
execute positioned ~-2 ~ ~1 if entity @e[type=minecraft:bamboo_raft,distance=..1]data modify block ~-1 ~ ~1 front_text.messages[2] set string block ~ ~-1 ~ LastOutput.extra[0].with[0] 0execute positioned ~-2 ~-2 ~1 unless entity @e[type=minecraft:bamboo_raft,distance=..1] run data modify block ~1 ~1 ~ front_text.messages[2] set value "0"
Dispenser restocker: data merge block ~-2 ~-2 ~ {Items:[{Slot:4,id:"minecraft:bamboo_raft"}]}
The result is that if the number of “launcher” rafts is 223 or greater, the dispensed raft will lose its motion upon being teleported.
Please reopen. Still happens in 1.21.9 pre release 1. It’s so glitchy pearls will go through 10s of solid blocks. seems the glitch happen when a pearl is going over ~125m/gametick.
I will set this to Plausible, but please update the report to provide concrete reproduction steps, i.e. how to eject an entity from a mass of other entities in such a way that its Motion exceeds 10 yet also ensure that only one entity goes through the portal.
I am not particularly optimistic that this will be fixed since entity motion being capped at 10 during summoning and manual data modification is longstanding behavior (see MC-123603), so getting an entity to reach higher speeds via other methods is likely considered unsupported. However, it’s not clear to me why that report was resolved as Invalid given that the cap is seemingly not due to a technical limitation, so I will request a review on it. If the report is reopened then this issue is likely valid as well.
My hope is that Mojang opts to enforce a consistent cap (hopefully much higher than 10) across all parts of the game, and that when an entity’s motion would exceed this cap, it is set to the cap instead of to 0. While the existence of any cap would impact pearl cannons and other interesting contraptions, having a consistent cap would clarify what intended behavior is and allow easy simulation of cannons using commands.