[MC-868] Detector Rail switches junction before Minecart passes detector (happens only with minecarts of certain speed) Created: 27/Oct/12  Updated: 10/Nov/24

Status: Open
Project: Minecraft: Java Edition
Component/s: None
Affects Version/s: Minecraft 1.4.2, Minecraft 1.4.5, Minecraft 1.4.6, Minecraft 1.4.7, Snapshot 13w05b, Snapshot 13w09a, Snapshot 13w09b, Minecraft 1.5, Snapshot 13w11a, Minecraft 1.5.1, Minecraft 1.5.2, Snapshot 13w18c, Snapshot 13w19a, Minecraft 1.6.2, Minecraft 1.6.4, Minecraft 13w38b, Minecraft 13w38c, Minecraft 13w39a, Minecraft 1.7.1, Minecraft 1.7.2, Minecraft 13w47e, Minecraft 13w48a, Minecraft 13w48b, Minecraft 1.7.3, Minecraft 1.7.4, Minecraft 14w02c, Minecraft 14w03b, Minecraft 14w04a, Minecraft 14w04b, Minecraft 14w05b, Minecraft 14w06a, Minecraft 14w06b, Minecraft 1.7.5, Minecraft 14w11b, Minecraft 1.7.9, Minecraft 14w17a, Minecraft 14w18a, Minecraft 14w20a, Minecraft 14w20b, Minecraft 14w21b, Minecraft 1.7.10, Minecraft 14w27b, Minecraft 14w30b, Minecraft 14w30c, Minecraft 14w32a, Minecraft 14w32b, Minecraft 14w32c, Minecraft 14w32d, Minecraft 14w33a, Minecraft 1.8, Minecraft 1.8.1-pre2, Minecraft 1.8.1-pre3, Minecraft 1.8.1, Minecraft 1.8.3, Minecraft 1.8.4, Minecraft 1.8.5, Minecraft 1.8.7, Minecraft 1.8.8, Minecraft 15w35e, Minecraft 15w44b, Minecraft 1.8.9, Minecraft 15w51b, Minecraft 16w02a, Minecraft 1.9 Pre-Release 1, Minecraft 1.9, Minecraft 1.9.1 Pre-Release 3, Minecraft 1.9.2, Minecraft 1.9.3 Pre-Release 3, Minecraft 1.9.4, Minecraft 16w20a, Minecraft 16w21a, Minecraft 16w21b, Minecraft 1.10 Pre-Release 1, Minecraft 1.10 Pre-Release 2, Minecraft 1.10, Minecraft 1.10.1, Minecraft 1.10.2, Minecraft 16w32a, Minecraft 16w32b, Minecraft 16w33a, Minecraft 16w35a, Minecraft 16w40a, Minecraft 16w41a, Minecraft 16w44a, Minecraft 1.11 Pre-Release 1, Minecraft 1.11.2, Minecraft 17w06a, Minecraft 1.12.1, Minecraft 18w50a, Minecraft 1.14 Pre-Release 1, Minecraft 1.14 Pre-Release 5, Minecraft 1.14.1, Minecraft 1.14.2 Pre-Release 1, Minecraft 1.14.2 Pre-Release 2, Minecraft 1.14.2 Pre-Release 3, Minecraft 1.14.2, Minecraft 1.14.3 Pre-Release 2, Minecraft 1.14.3 Pre-Release 3, Minecraft 1.14.4 Pre-Release 3, 1.14.4, 19w35a, 1.15.2, 20w07a, 20w14a, 1.16 Pre-release 2, 1.16 Pre-release 5, 1.16 Release Candidate 1, 1.16, 1.16.1, 20w28a, 20w29a, 20w30a, 1.16.2 Pre-release 1, 1.16.2 Pre-release 2, 1.16.2 Pre-release 3, 1.16.2 Release Candidate 1, 1.16.2 Release Candidate 2, 1.16.2, 1.16.3 Release Candidate 1, 1.16.3, 1.16.4 Pre-release 1, 1.16.4 Pre-release 2, 1.16.4 Release Candidate 1, 1.16.4, 20w45a, 20w46a, 20w48a, 20w49a, 20w51a, 21w03a, 1.16.5, 21w05a, 21w05b, 21w06a, 21w07a, 21w08b, 21w10a, 21w11a, 21w13a, 21w14a, 21w20a, 1.17, 1.17.1, 21w39a, 21w42a, 1.18 Pre-release 5, 1.18, 1.18.1, 22w03a, 22w06a, 22w14a, 22w18a, 1.19.1 Pre-release 5, 1.19.2, 1.19.3, 23w03a, 23w04a, 23w05a, 23w06a, 1.19.4, 1.20.1, 1.20.2 Pre-release 2, 23w51b, 24w40a, 1.21.3
Fix Version/s: None

Type: Bug
Reporter: [Mod] markderickson Assignee: Unassigned
Resolution: Unresolved Votes: 90
Labels: minecart

Attachments: GIF File 1.gif     GIF File 2.gif     PNG File 2014-05-22_16.27.18.png     PNG File 2014-05-22_17.27.55.png     PNG File Alternative Cycle.png     PNG File Alternative Setup.png     File MC-868-world.7z     PNG File end.png     JPEG File javaw 2015-07-22 15-19-39-14.jpg     PNG File start.png    
Issue Links:
Duplicate
is duplicated by MC-9082 Detector rails still triggering junct... Resolved
is duplicated by MC-30516 Detector rail incorrect timings Resolved
is duplicated by MC-87698 Detector Rail powering a Activator Ra... Resolved
is duplicated by MC-98697 Detector rails are not precise at all Resolved
is duplicated by MC-116908 Minecart activates detector rail befo... Resolved
is duplicated by MC-177665 Chest and Hopper Minecarts trigger de... Resolved
is duplicated by MC-187776 The detector rail is activated before... Resolved
is duplicated by MC-230498 Detector rail detects before cart rea... Resolved
CHK:
Confirmation Status: Confirmed
Category:
Minecart
Mojang Priority: Normal
Area: Platform

 Description   

If you have a detector rail it can affect rails directly connected to it. A powered rail for example is powered and a curved rail can change orientation. Imagine now to have a t-junction setup like in

The detector rail is on the left and passing it will cause the curved rail to change orientation. We start our cart not from the detector, but from where the rail is bend to. After starting the cart it goes into the bend and before leaving it, the detector will react. This causes a flicker in which the cart and the rail change orientation several times to then finally settle in the right-side position as in
This basically means the detector rail caused a change of orientation for the bend rail before the minecart was even standing on it.

I assume that the signaling goes by this: If the cart, would in a next step touch the detector rail, it fires. Since the rail is then bending in another direction there is an update as the minecart will now not go over the rail, causing another oriantation change. This then causes the detector to fire again going back to the situation in the beginning. The reason why this does not cause an endless loop is that each action takes one tick. Depending on the speed of the cart you will see a longer or shorter flicker then.

What I expected was that the cart will go to the left, not the right as it actually did.

Code analysis by pr0cess can be found in this comment.


James549:

  • Fixed in 16w02a? Using the setup described in start.png, the minecart sometimes "bounces" off the rail and goes backwards.
  • Half-fixed for 1.9.1-pre3.
    • Slow-moving minecarts will go the correct way, while fast moving minecarts will bounce back?!

Immaterialise:

  • Confirmed for 1.9-pre1. It seems to be affected by the speed of the minecart as well. Fast and slow minecarts don't trigger it, but minecarts with a medium-ish speed do.


 Comments   
Comment by Minecraft386882 [ 10/Nov/24 ]

Can confirm for 1.21.3

Comment by Brain81505 [ 05/Jul/23 ]

Can confirm in 1.20.1

Comment by Brain81505 [ 11/Feb/23 ]

Can confirm in 23w06a

Comment by Brain81505 [ 01/Feb/23 ]

Can confirm in 23w05a

Comment by Jochen Theodorou [ 26/Jan/23 ]

As the original author of this issue I just wanted to say hello. It is 10 years now, I still play Minecraft. I am not complaining, I see no need to rush to fix this.

Comment by Brain81505 [ 25/Jan/23 ]

Can confirm in 23w04a

Comment by Brain81505 [ 18/Jan/23 ]

Can confirm in 23w03a

Comment by Brain81505 [ 14/Jan/23 ]

Can confirm in 1.19.3

Comment by FX - PR0CESS [ 11/May/22 ]

Can confirm for 22w18a

The issue is not due to how big the collision box of the detector rail is, as mentioned before. Since changing the collision box will also affect command block minecarts & inventory minecarts, which is a big deal.

The issue is due to how the detector rail functions. When an entity collides with a detector rail, it looks for carts touching itself, we simply need to tell it not to activate unless the minecart is in the block.

Code Analysis (Yarn - 22w18a)

net.minecraft.block.DetectorRailBlock.java
// Called on entity collision
private void updatePoweredStatus(World world, BlockPos pos, BlockState state) {
	if (this.canPlaceAt(state, world, pos)) {
		boolean wasPowered = state.get(POWERED);
		boolean shouldPower = false;
		List<AbstractMinecartEntity> list = this.getCarts(
			world, 
			pos, 
			AbstractMinecartEntity.class, 
			entity -> true
		);
		if (!list.isEmpty()) {
			shouldPower = true;
		}
		if (shouldPower && !wasPowered) {
			// Turn on
		}
		if (!shouldPower && wasPowered ) {
			// Turn off
		}
		// ...
	}
}

Suggested Fix:

private void updatePoweredStatus(World world, BlockPos pos, BlockState state) {
	if (this.canPlaceAt(state, world, pos)) {
		// Change entityPredicate to check the entity blockPos
		List<AbstractMinecartEntity> list = this.getCarts(
			world, 
			pos, 
			AbstractMinecartEntity.class, 
			entity -> entity.getBlockPos().equals(pos)
		);
		boolean wasPowered = state.get(POWERED);
		boolean shouldPower = !list.isEmpty();
		// ...
	}
}

Working Fix

Now I will mention why this should not be fixed xD

When changing this code you run into an issue with client rendering. Due to the client using interpolation, the client will render the minecart as if it's turning and then put it in the right place. So that issue should be solved first... which is not an easy issue to fix.

Comment by Jasmin Reeh [ 24/Aug/21 ]

This effect is also visible when a cart passes nearby a detector rail. The detector rail fires when the cart will not even drive over it 

Comment by James A [ 22/Jul/21 ]

Affects 1.17.1

Comment by Marty McFly [ 10/Jun/21 ]

Affects 1.17

Comment by [Mod] Avoma [ 05/Feb/21 ]

Can confirm in 21w05b.

Comment by Ducky [ 16/Nov/20 ]

This bug is still present as of 1.16.3, its making my T-junctions impossible to use

 

Comment by Fabian Röling [ 09/Nov/20 ]

I can. Are you using the setup from the pictured embedded into the description?

Comment by h2ofiremaster [ 09/Nov/20 ]

Cannot reproduce in 20w45a. Fixed?

Comment by Marty McFly [ 19/Jun/20 ]

Affects 1.16 Release Candidate 1

Comment by UserTaken [ 12/Jun/20 ]

Still exists in 1.16 Pre-5.

Comment by Benjamin Bryztal [ 02/Sep/19 ]

This still affects 1.15 snapshots. 

Comment by Dave S [ 08/Jul/19 ]

1.14.4 Pre-3 - still there.

Comment by Dave S [ 09/Jun/19 ]

Still in 1.14.3 Pre-Release 2
Mojang, please. This really makes it impossible to do any cool rail systems and is in the game already for so long.

Comment by Elemend [ 22/May/19 ]

Happens in 1.14.2-Pre-Release 3

Comment by Dave S [ 20/May/19 ]

Still in MC 1.14.2 Pre-2 
Also, in Environment it says Ubuntu. Windows (10) should be added as well.
 

Comment by Dave S [ 13/May/19 ]

Still in MC 1.14.1

Comment by Dave S [ 21/Apr/19 ]

Would be nice to have it finally fixed, in 1.14.
This happens in 1.13 and all the recent snapshot versions. Tested again on 1.14 Pre-Release 5:

Comment by Fabian Röling [ 08/Dec/18 ]

This issue is different now. The minecart doesn't go in the other direction of the junction, but instead it goes backwards. If it bounces back to the junction again, it goes the other direction of course.

Comment by [Mod] bemoty [ 12/Aug/17 ]

Can confirm for MC 1.12.1.

Comment by Daniel Burnett [ 09/Jul/17 ]

Confirmed for 1.12; this is quite an annoying bug that really messes with simple minecart junctions.

I think this could be easily solved by changing the AABB used for detection of minecarts in BlockRailDetector#getDetectionBox (using the Forge names for things); there already seems to be a variable, f, which defines how much the block pos is shrunken for the AABB, but it's not actually used; using that and adjusting it to something a bit larger (so, a smaller AABB) would probably do the trick, as it seems checking the middle 60% of the block is still too much margin.

Alternatively, the World#getEntitiesWithinAABB method (or, down the line, the AxisAlignedBB#intersects method) could have an overloaded option that takes an "adjustment" float argument and adjusts the entity's bounding box during intersection testing.

Either should work; I'd say the first option is easier, though.

Comment by husky2490 [ 25/Jun/16 ]

This might help to visualize the behavior...
https://youtu.be/2UhbmKqR82g

Also, confirmed for Minecraft 1.10.2

Comment by null (Inactive) [ 23/Jun/16 ]

Confirmed for 1.10.2.

Comment by null (Inactive) [ 22/Jun/16 ]

Confirmed for 1.10.1.

Comment by null (Inactive) [ 08/Jun/16 ]

Confirmed for 1.10. I still managed to get the minecart to go the incorrect way!

Comment by null (Inactive) [ 07/Jun/16 ]

Confirmed for 1.10-pre2. (Slow moving minecarts will initially appear to move the incorrect way, then they will start to move the correct way.)

Comment by null (Inactive) [ 03/Jun/16 ]

Confirmed for 1.10-pre1.

Comment by null (Inactive) [ 26/May/16 ]

Confirmed for 16w21b. (At this point, the bug is the fact that minecarts will bounce back in the example.)

Comment by null (Inactive) [ 25/May/16 ]

Confirmed for 16w21a.

Comment by null (Inactive) [ 18/May/16 ]

Confirmed for 16w20a.

Comment by null (Inactive) [ 11/May/16 ]

Confirmed for 1.9.4.

Comment by null (Inactive) [ 05/May/16 ]

Confirmed for 1.9.3-pre3.

PS. In the description, James should be changed to James549 "[~James549]".

Comment by James (inactive) [ 15/Mar/16 ]

Half-fixed(?) for 1.9.1-pre3.

Slow-moving minecarts will go the correct way, while fast moving minecarts will bounce back?!

Comment by Immaterialise [ 17/Feb/16 ]

Confirmed for 1.9-pre1. It seems to be affected by the speed of the minecart as well. Fast and slow minecarts don't trigger it, but minecarts with a medium-ish speed do.

Comment by Alexander [ 14/Jan/16 ]

Not fixed. Still an issue in 16w02a.

Comment by James (inactive) [ 13/Jan/16 ]

Fixed in 16w02a? Using the setup described in start.png, the minecart sometimes "bounces" off the rail and goes backwards.

Comment by James (inactive) [ 23/Dec/15 ]

Confirmed for 1.8.9 and 15w51b. Happens about 80% of the time.

Comment by Alexander [ 30/Oct/15 ]

Confirmed for 15w44b.

Comment by Kai Hoop [ 22/Jul/15 ]

Confirmed in 1.8.7 on OS X Mavericks, with Java 8 update 51. This happens no matter what speed the minecart's traveling at.

Comment by Christopher Martin [ 22/Jul/15 ]

Here's some other crazy behaviour related to this.

What you would expect from block descriptions on the Wiki:
The Minecart should travel East from the starting point then turn right.

What you would expect from MC-868:
The Minecart should travel East from the starting point, activate the detector rail around the corner then go left.

What actually happens:
Insanity ensues! Watch the video: https://youtu.be/HCrlaovpXuk

This bug is THREE YEARS OLD. Very soon, Mojang are going to have to pack this bug up and send if off to school it's so old.

Comment by husky2490 [ 23/May/15 ]

If this setup counts, confirmed for Vanilla 1.8.5.

Comment by Ralf [ 05/May/15 ]

Confirmed for 1.8.4 stable.

Comment by Jeremy [ 01/Nov/14 ]

Confirmed for 1.8 pre-release 3.

Comment by [Mod] Sonicwave [ 19/Oct/14 ]

Confirmed for 1.8/1.8.1-pre2. Can probably be fixed by only making the center of its hitbox interact with the detector rail, instead of the entire hitbox.

Comment by kbk [ 13/Aug/14 ]

Starting to sound like a broken record today, but this is still valid as of 14w33a

Comment by Dlawso the Really Lucky Rabbit [ 25/Jul/14 ]

Still in 30c.

Comment by kbk [ 07/Jul/14 ]

Still valid for 14w27b.

Comment by Christopher Martin [ 16/Jun/14 ]

OP, can we get 14w21b added to the affected version field please?

kbk, yeah the directionality of it suggests it's bug-like, if not an outright code bug. It's likely going to be very hard to fix, which would suggest it's going to languish, unresolved, for some time yet.

Comment by kbk [ 22/May/14 ]

And here, if we rotate our setup to the south, both detectors become active and the minecart can go to the right and back.

Comment by kbk [ 22/May/14 ]

I guess not. Additionally, my test sheep refused to pass junction in first setup.

So, what happens here:
1. I put a minecart on the south-facing track and provide the junction with two detector rails on southern and northern tracks. Junction assumed its natural south-western orientation.
2. I pull the cart. Cart passes the detector for the first time. Junction assumes innatural north-western orientation.
3. Cart passes the junction straight north (which is normal), returns back, presses the detector to the right and successfully goes west.
4. Cart approaches the junction. Southern (leftmost) detector activates, junction assumes innatural position due to this, then for some reason minecart bumps back west with all the momentum it previously had.

Apparently
a) for some reason it is definitely tested whether the minecart can pass the junction towards the active detector. I suppose such check happens at least twice: right before the detector activates when the junction is approached by minecart (true) and then again after it toggles the junction (false).
b) the detector that will become active first is chosen directionally (e.g. there is currently no way for junction to store and reuse some unrelated data like "last active signal source", "last known minecart direction" or "what does the sheep say" here)

Comment by Christopher Martin [ 21/May/14 ]

As frustrating as this is, it must be a damn pickle to have gone over two years without resolution. Is it related to the minecart hitbox size?

Comment by kbk [ 15/May/14 ]

Still valid for 14w20b

Comment by kbk [ 29/Apr/14 ]

Valid for 14w17a

Comment by theerapak [ 15/Mar/14 ]

still in 14w11b

Comment by Freso Fenderson [ 09/Feb/14 ]

Still present in 14w06b.

Comment by kbk [ 26/Jan/14 ]

Yes, it is as valid as has ever been.

Comment by Freso Fenderson [ 09/Dec/13 ]

And 1.7.4 can be added to the list. (I forgot to check for this in the intermediary version, but I'm guessing it was to be found there as well.)

Comment by Freso Fenderson [ 29/Nov/13 ]

I've attached a world/save that shows the bug.

Comment by Freso Fenderson [ 29/Nov/13 ]

And 13w48b too.

Comment by Freso Fenderson [ 25/Nov/13 ]

I can confirm this in 1.7.2, 13w47e, and 13w48a. (I discovered it in 13w47e, checked it again in the last stable version to see if it was a snapshot version bug, and then came here to see if it was already reported - and then downloaded 13w48a and tested there.)

Comment by kbk [ 26/Sep/13 ]

13w39a confirmed to still have this.

Comment by [Mod] CubeTheThird [ 26/Sep/13 ]

Is this still a concern in the current Minecraft version 1.6.4 / Launcher version 1.2.5 ? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.

Comment by rex [ 04/Jul/13 ]

bug still happens in 1.6.1

Comment by Marchack [ 17/May/13 ]

I managed to catch the moment when the actual bug happens - Fourth picture. Then it happens again in the Fifth picture while the previous detector rail is still active.

Comment by Marchack [ 17/May/13 ]

13w19a still has got it and it's getting annoying.

Comment by kbk [ 27/Apr/13 ]

1.5.2pre is still affected.

Comment by kbk [ 06/Mar/13 ]

Still ain't fixed as of 13w10b. Bawwwww.

Comment by kbk [ 01/Mar/13 ]

Affects 13w09b.

Comment by Owen Murray [ 28/Jan/13 ]

This seems to be similar to an issue I am having, I will try a diagram

B----------r---------C
............X
............I
............I
............I
............I
............I
.........A.I

OK basically a cart coming from A should trip the corner r from C to B then reset and it does, but when the cart returns from B the corner flips again sending the cart to A - There is no detector rail on the B line. I have just made the B C into a loop and what is happening is the cart coming to the corner from C trips the corner towards B but for some reason the cart takes the corner to A anyway. Bug seems to be - if one line has a detector rail ALL lines to the T junction behave like they have one. If you add a rail above the r the detector rail stops working.

Watch this new video I made with Ezvid:
http://youtu.be/fvHlh8mEFEU

Comment by Peter Rothe [ 07/Jan/13 ]

I hope that this screencast show the problem from another angle.

This is the way it should be working (the cart drives to north):
http://www.screencast.com/users/kitharo/folders/Default/media/2c44b0a6-6681-47c6-b4bc-f8b441507bc1
(creative)

Same construction but with another orientation:
http://www.screencast.com/users/kitharo/folders/Default/media/7914ba35-8176-48e1-8fa5-4e30d72d1f11

Here you can see the the detection isn't work correctly: http://www.screencast.com/users/kitharo/folders/Default/media/789f3c14-e9ae-4bb9-9fe2-e2b400a40ef4
(creative)
There was nothing special build.

I hope this helps to fix the problem & describes what is reported above.
Can somebody check that please otherwise i will create a new task.

Also Snapshot 13w01b has these bug.

EDIT: looks like the orientation is important to fix the bug

Comment by Peter Rothe [ 02/Jan/13 ]

really annoying bug. Hope that get fixed in 1.5 =)

Comment by Tails [ 30/Nov/12 ]

Confirmed in 1.4.5.

Comment by Jochen Theodorou [ 27/Oct/12 ]

added smalelr images

Generated at Sun Jan 12 11:52:30 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.