Minecarts will reverse direction when a track changes direction just as the minecart is entering that track block. The minecart should be directed to the alternate track.
I have only been able to reproduce it with the pictured track (facing west). The timing has to be very precise otherwise it will work as expected.
Edit: the issue happens only in the X axis, attached image showing that expected behavior happens in Z axis
Related issues
relates to
Attachments
Comments
migrated
pulpetti
In 1.16.1
migrated
I studied the cause of this bug some months ago and here are my findings. I used version 1.16.5 and the code was decompiled with fabric.
[media]The images labeled Tick 1 and Tick 2 describe what happens to a minecart's velocity and position during two consecutive executions of the moveOnRail-method (yarn mappings). The velocity arrows are not to scale and are only used to illustrate the direction. The actual magnitude depends on a variety of factors such as the minecart's type but is irrelevant as long as it is large enough to reach the speed limit of 0.4 blocks/tick. We assume that there are no blocks diagonally to the curved rail and that the rails connected to the junction are all flat and straight.
At the beginning of tick 1 a minecart at full speed has just entered a curved rail from a straight rail on the bottom. The assumption that the cart has reached the speed limit implies that the cart has advanced at most a distance of 0.4 into the curved rail block.
The following is roughly what happens during the execution of a tick if the assumptions above are considered:
The minecart's position is adjusted by snapping it onto the snap line, which is a line passing through the midpoints of the two faces the rail is connected to. No collision checks with blocks or other entities are done at this point.
The velocity is rotated such that it is parallel to the snap line. Since there are two ways to do this, the direction is specified by requiring that the dot product between the velocity before the rotation (v1) and after the rotation (v2) is positive: v1 * v2 > 0. If v1 and the snap line are perpendicular which is what happens during tick 2 in the illustration, then the direction of v2 is chosen such that it points from the north/south connection towards the east/west one making the bug orientation dependent.
Finally, the minecart is moved in the direction of its velocity while capping the movement along both x and z directions to 0.4 blocks. Unlike in the snapping step, now the movement is also affected by collisions with blocks that might exist around the junction.
We observe that a necessary condition for the momentum reversal bug to occur is that the minecart starts two consecutive ticks on top of the same curved rail. For a full speed cart this only happens if the initial position is less than 0.2 blocks into the curved rail. If the minecart starts advanced further than this, it is guaranteed to exit the curved rail block by the end of the tick thus making it impossible for any rail switching to affect its movement.
The bug cannot happen when the junction switching is the other way around, i.e. initially facing down-right and switching to up-right between the two ticks. In this case the minecart will however choose between "bouncing" depending on orientation.
In the case of approaching the junction from the stem of the T-junction (from the right in this illustration) the bug can happen regardless of which way the rail is pointing initially.
Once there are blocks present diagonally to the curved rail to collide with the cart and to modify the direction of its velocity, some additional ways for this bug to occur become possible. I verified this by testing in game but didn't look into the details.
I cannot think of an obvious solution to fix the issue that wouldn't affect any of the properties of curved rail that many consider features, such as the fact that because of the snapping step minecarts can effectively move at twice the speed limit at 0.8 blocks/tick.
migrated
Affects 1.17 Pre-release 1
migrated
Affects 1.17
migrated
Still persists in 1.21.1
Carretero Martínez
Unable to reproduce with the set ups provided in the experimentals in 24w33a.
its either solved, or aa new set up is needed. Either way this issue should be closed as unable to reproduce
migrated
No, still exists in 24w33a using setup from MC-184539
[media]
Carretero Martínez
I just tested the set up provided by Jitse, given by MC-184539 in the east direction. the bug is indeed fixed in the experimental branch in the snapshots. But I was made aware in the Jira Discord that until these experiments are made into the official branch. Ill keep adding versions to the affected versions as they pointeded but the issue is fixed in the experimental minecart version.
migrated
Yes turning on experimental minecart fixed it