| Type: | Bug | ||
| Reporter: | [Mod] markderickson | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 90 |
| Labels: | minecart | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| 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 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.
|
| 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(); // ... } } 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 |
| 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 |
| 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. |
| 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... 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: What you would expect from MC-868: What actually happens: 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 ] |
| 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: Apparently |
| 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---------- 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: |
| 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): Same construction but with another orientation: 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 I hope this helps to fix the problem & describes what is reported above. 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 |