ru4red
Comments
It is still a problem in 26.3.
This is not a bug; different blocks have different characteristics.
Confirmed in 26.2, not fixed.
Only the first gt in entering the rail does not match the rail position; If the speed is slowed down, the bug will be small enough not to trigger the adjacent sensing rail.
Additionally, trapdoors are 0.1825 thick and hoppers are 0.125 thick. Since a minecart at top speed moves at 0.4 b/gt, it is possible to pass through them at specific positions due to discrete movement.
In Bedrock Edition, when a minecart is on a rail, its block collision box slides parallel to the track one block above it (shown in orange in the image), while the red area represents the minecart's actual hitbox.
Image 1 shows how a minecart can pass
through regular blocks. When entering the inclined rail, the block collision box enters the block's space, allowing it to pass through freely.
Image 2 demonstrates why hoppers, cauldrons, and trapdoors cause minecarts to get stuck. When entering the inclined rail, the minecart's block collision判定 does not enter the block's space, causing it to collide with the block.
This behavior is significantly different from the Java Edition.
I created an animation of the minecart's actual movement. The minecart doesn't perfectly follow the track's trajectory during the first gt after entering the rails, causing this phenomenon.
The original report expects the dismount position to be relative to the rail, but it is actually tied to the minecart. Therefore, this is not a bug.
A more detailed analysis of this report, it is caused by the execution order: the dismount location is determined by the minecart’s position 1gt before it hits the activator rail. This is a consistent mechanical feature and does not require a fix
To clarify what I mean by 'expected behavior': comparing the two tracks in my video, it is clearly visible that the minecart on the top row (which hits the wall) moves slower than the one on the bottom row (which does not hit the wall), excluding the MCPE-225691 bug.
One more addition: this is unrelated to MCPE-225691. Factors like direction or whether there are other minecarts nearby do not matter; the instant stop occurs at random positions regardless.
Apologies, I overlooked a key detail in my previous comment. The issue reported in MCPE-190781 does exist. In certain cornering scenarios, the motion isn't split between X and Z, but is instead focused entirely on one axis (either X or Z). If that axis hits a block, the velocity drops to zero instantly.
The gradual deceleration I described earlier should be the expected behavior, but the 'instant stop' at specific positions as reported is indeed an anomaly.
This is not a bug, but a result of collision physics. On a zig-zag track, the minecart's path inevitably hits the adjacent blocks. Since the motion is diagonal, it is split into x and z components.
When hitting a wall, one component is reduced to 0, leaving only the other direction—effectively reducing the velocity to (1/√2.approx 0.707x) per impact. Continuous turns lead to rapid momentum loss due to these repeated collisions. This is a normal physical interaction, so it should be "Works as Intended."
This issue should be treated as a visual redirection error. Redstone wire should stay straight and power the piston via lateral signal (side-powering), just like a solid block. The piston should not "attract" the wire and cause it to redirect, as this unnecessarily breaks the original circuit path
Because the loading range is limited, it's impossible to require entities outside the loading range to move; therefore, this report should be categorized as "as expected".