Detector Rail switches junction before Minecart passes detector (happens only with minecarts of certain speed)

added smalelr images

Confirmed in 1.4.5.

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

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

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

Affects 13w09b.

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

1.5.2pre is still affected.

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

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.

bug still happens in 1.6.1

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.

13w39a confirmed to still have this.

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.)

And 13w48b too.

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

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.)

Yes, it is as valid as has ever been.

Still present in 14w06b.

still in 14w11b

Valid for 14w17a

Still valid for 14w20b

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?

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)

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

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.

Still valid for 14w27b.

Still in 30c.

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

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.

Confirmed for 1.8 pre-release 3.

Confirmed for 1.8.4 stable.

If this setup counts, confirmed for Vanilla 1.8.5.

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.

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.

Confirmed for 15w44b.

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

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

Not fixed. Still an issue in 16w02a.

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.

Half-fixed(?) for 1.9.1-pre3.

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

Confirmed for 1.9.3-pre3.

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

Confirmed for 1.9.4.

Confirmed for 16w20a.

Confirmed for 16w21a.

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

Confirmed for 1.10-pre1.

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.)

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

Confirmed for 1.10.1.

Confirmed for 1.10.2.

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

Also, confirmed for Minecraft 1.10.2

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.

Can confirm for MC 1.12.1.

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.

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:

Still in MC 1.14.1

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

Happens in 1.14.2-Pre-Release 3

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.

1.14.4 Pre-3 - still there.

This still affects 1.15 snapshots. 

Still exists in 1.16 Pre-5.

Affects 1.16 Release Candidate 1

Cannot reproduce in 20w45a. Fixed?

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

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

Can confirm in 21w05b.

Affects 1.17

Affects 1.17.1

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 

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.

Can confirm in 1.19.3

Can confirm in 23w03a

Can confirm in 23w04a

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.

Can confirm in 23w05a

Can confirm in 23w06a

Can confirm in 1.20.1

Can confirm for 1.21.3

dang this is the oldest open ticket in java mc, wow

It might be just a visual effect, as minecart and boat rendered location is significantly behind the actual location. This is probably so the movement looks smooth, so they delay the rendered location to calculate and play movement animation.