| Type: | Bug | ||
| Reporter: | [Mod] Avoma | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 134 |
| Labels: | power, powered_rail, rails, redstone, update, update-failure | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| CHK: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Category: |
Block states, Minecart, Redstone
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Mojang Priority: | Low | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Area: | Platform | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
The bugPowered rails do not update when additional power sources are added or removed. How to reproduce
Expected behaviorPowered rails would update when additional power sources are added or removed. Code analysisCode analysis by ISRosillo14 can be found in this comment. |
| Comments |
| Comment by kaktusmisapolak [ 28/Aug/24 ] |
|
confirmed in 1.21.1 |
| Comment by Ceresjanin123 [ 20/Aug/24 ] |
|
This could be fixed in the experimental redstone improvements hopefully |
| Comment by Josh Birk [ 09/Sep/23 ] |
|
Can confirm, bug still occurs in 1.20.2 Pre-release 2. |
| Comment by Jon1337 [ 07/Sep/23 ] |
|
In 1.20.2 Pre-Release 2 |
| Comment by Ismael Rosillo [ 28/Mar/23 ] |
|
Hey Avoma! Though this is not a code analysis, it is a possible fix for this bug, I hope this will help Mojang fix it. Cause Powered rails try to check and update when a neighbour change happens, that is okay. The problem is that if you set a redstone power source next to an already powered "on" rail, neighbors will not update because there are no block state changes (powered=true is equal to powered=true). A possible way to fix this is by making the powered block state depend on a power number state, so every time a redstone signal changes every rail will update neighbour rails up until they're far enough from source. Workaround A few months ago I was messing with PoweredRailBlock.java to make curved powered rails, and I noticed how unsafe are methods findPoweredRailSignal(Level,BlockPos,BlockState,boolean,int) and isSameRailWithPower(Level,BlockPos,boolean,int,RailShape). Basically what I did was remove the proximity variable (the int param of this method that increases every time it checks a further rail) and make powered rails use a new "power" block state that goes from 0 to 9 (0 equals to unpowered, 9 is fully powered). Then, changed findPoweredRailSignal again to only check directly connected powered rails (and not all 8) and isSameRailWithPower to only check the given's rail "power" state (previously it did check if that rail had a redstone source or else check for a further away neighbour block). Also, the two methods mentioned above will now return power state (int) instead of powered state (boolean). In other words, the new behaviour will make findPoweredRailSignal and isSameRailWithPower get their direct adjacent's power. End result of these two methods:
public class PoweredRailBlock extends BaseRailBlock { ... protected int findPoweredRailSignal(Level p_55220_, BlockPos p_55221_, BlockState p_55222_, boolean reverse) { int i = p_55221_.getX(); int j = p_55221_.getY(); int k = p_55221_.getZ(); boolean checkBelow = true; RailShape railshape = p_55222_.getValue(SHAPE); switch (railshape) { case NORTH_SOUTH: if (reverse) { ++k; } else { --k; } break; case EAST_WEST: if (reverse) { --i; } else { ++i; } break; case ASCENDING_EAST: if (reverse) { --i; } else { ++i; ++j; checkBelow = false; } railshape = RailShape.EAST_WEST; break; case ASCENDING_WEST: if (reverse) { --i; ++j; checkBelow = false; } else { ++i; } railshape = RailShape.EAST_WEST; break; case ASCENDING_NORTH: if (reverse) { ++k; } else { --k; ++j; checkBelow = false; } railshape = RailShape.NORTH_SOUTH; break; case ASCENDING_SOUTH: if (reverse) { ++k; ++j; checkBelow = false; } else { --k; } railshape = RailShape.NORTH_SOUTH; } int pow; if ((pow = this.getSameRailPower(p_55220_, new BlockPos(i, j, k), railshape)) > 0) { return pow; } else { return checkBelow ? this.getSameRailPower(p_55220_, new BlockPos(i, j - 1, k), railshape) : 0; } } /* renamed from isSameRailWithPower * I also removed the boolean param because it was not used anymore */ protected int getSameRailPower(Level p_55226_, BlockPos p_55227_, RailShape p_55230_) { BlockState blockstate = p_55226_.getBlockState(p_55227_); if (!blockstate.is(this)) { return 0; } else { RailShape railshape = blockstate.getValue(SHAPE); if (p_55230_ != RailShape.EAST_WEST || railshape != RailShape.NORTH_SOUTH && railshape != RailShape.ASCENDING_NORTH && railshape != RailShape.ASCENDING_SOUTH) { if (p_55230_ != RailShape.NORTH_SOUTH || railshape != RailShape.EAST_WEST && railshape != RailShape.ASCENDING_EAST && railshape != RailShape.ASCENDING_WEST) { if (blockstate.getValue(POWER) > 0) { return blockstate.getValue(POWER); } else { return 0; } } else { return 0; } } else { return 0; } } } ...
Now, we are missing something: method updateState(BlockState,Level,BlockPos,Block). This is the only method that uses findPoweredRailSignal, and is the one that sets the rail's power value when it detects a neighbor change. We will update it in order to set the proper "power" block state, by getting instead the adjacent connected powered rails highest signal, and decrease it by 1 (so power will be lesser the further the rail is full from source rail):
public class PoweredRailBlock extends BaseRailBlock { ... @Override protected void updateState(BlockState p_55232_, Level p_55233_, BlockPos p_55234_, Block p_55235_) { int thisPower = p_55232_.getValue(POWER); /* Give nine of power instead of redstone power in order to keep the original behavior */ int checkPower = Math.max(p_55233_.hasNeighborSignal(p_55234_) ? 9 : 0, Math.max(this.findPoweredRailSignal(p_55233_, p_55234_, p_55232_, true), this.findPoweredRailSignal(p_55233_, p_55234_, p_55232_, false)) - 1); if (checkPower != thisPower) { p_55233_.setBlock(p_55234_, p_55232_.setValue(POWER, Integer.valueOf(checkPower)), 3); p_55233_.updateNeighborsAt(p_55234_.below(), this); if (p_55232_.getValue(SHAPE).isAscending()) { p_55233_.updateNeighborsAt(p_55234_.above(), this); } } } ...
After this workaround, the bug seemed fixed. Problems:
|
| Comment by Brain81505 [ 01/Feb/23 ] |
|
Can confirm in 23w06a |
| Comment by Brain81505 [ 25/Jan/23 ] |
|
Can confirm in 23w04a |
| Comment by Brain81505 [ 18/Jan/23 ] |
|
Can confirm in 23w03a |
| Comment by [Bot] Arisa [ 13/Dec/21 ] |
|
An attachment with a disallowed file extension has been removed from this ticket. Executable files and documents are not allowed as attachments. |
| Comment by PiTheGuy [ 27/Nov/21 ] |
|
Can confirm in Release 1.17.1 |
| Comment by [Mod] Avoma [ 04/Oct/21 ] |
|
I am able to confirm this behavior in 21w39a. Here are some extra details regarding this problem. The Bug: Powered rails do not update when additional power sources are added or removed. Steps to Reproduce:
Observed Behavior: Powered rails do not update when additional power sources are added or removed. Expected Behavior: Powered rails would be updated when additional power sources are added or removed. |
| Comment by Nolan Soo [ 30/Mar/21 ] |
|
There is an easy workaround, just break the rail, add the source and it works. |
| Comment by user-c84db (Inactive) [ 21/Feb/21 ] |
|
Also affects Activator Rails. |
| Comment by Stanisław Wardak [ 05/Feb/21 ] |
|
Confimed on 1.16.4
|
| Comment by Fabian Röling [ 25/Nov/20 ] |
|
Only the latest release and the latest snapshot are useful. And that version is already in the list. |
| Comment by Ahmad S. [ 25/Nov/20 ] |
|
cofirmed in 1.4.1 |
| Comment by Adam Xu [ 05/Nov/20 ] |
|
confirmed for 20w45a |
| Comment by pulpetti [ 06/Jul/20 ] |
|
affects 20w27a |
| Comment by Conem [ 15/Jun/20 ] |
|
Confirmed in 1.16-pre6. |
| Comment by Conem [ 12/Jun/20 ] |
|
Confirmed in 1.16-pre5. |
| Comment by Numeritos [ 05/Jun/20 ] |
|
Affects 1.16 pre2 |
| Comment by Tooster [ 29/Apr/20 ] |
|
and 20w18a |
| Comment by Alex Hester [ 23/Apr/20 ] |
|
Still in snapshot 20w17a |
| Comment by Allison Ferris [ 26/May/19 ] |
|
Glad someone reported this, I thought I was going crazy (built a string farm from Pixlriffs but the minecart keeps stopping on a powered rail). Still an issue in 1.14.2 pre-release 4. |
| Comment by [Helper] ZeNico13 [ 17/May/19 ] |
|
Still in 1.14.2 Pre-Release 1 and 1.14.2 Pre-Release 2 |
| Comment by [Helper] ZeNico13 [ 13/May/19 ] |
|
Can also confirm for 1.14.1 Release |
| Comment by [Helper] Jack McKalling [ 13/May/19 ] |
|
Confirmed for 1.14.1 |
| Comment by [Helper] Jack McKalling [ 09/May/19 ] |
|
Confirmed for 1.14.1 pre-2 |
| Comment by [Helper] Jack McKalling [ 07/May/19 ] |
|
Confirmed for 1.14.1 pre-1 |
| Comment by Jordan Tyler Chase [ 30/Apr/19 ] |
|
Confirmed for 1.14 Release |
| Comment by [Helper] ZeNico13 [ 23/Apr/19 ] |
|
Still in 1.14 Release |
| Comment by [Helper] Jack McKalling [ 18/Apr/19 ] |
|
Confirmed for 1.14 pre-5 |
| Comment by [Helper] Jack McKalling [ 17/Apr/19 ] |
|
Confirmed for 1.14 pre-4 |
| Comment by [Helper] Jack McKalling [ 16/Apr/19 ] |
|
Confirmed for 1.14 pre-3 |
| Comment by [Helper] ZeNico13 [ 12/Apr/19 ] |
|
Still in 1.14 Pre-Release 2 |
| Comment by [Helper] Jack McKalling [ 10/Apr/19 ] |
|
Confirmed for 1.14 pre-1 |
| Comment by [Helper] Jack McKalling [ 08/Apr/19 ] |
|
Confirmed for 19w14b |
| Comment by [Helper] Jack McKalling [ 03/Apr/19 ] |
|
Confirmed for 19w14a |
| Comment by [Helper] Jack McKalling [ 29/Mar/19 ] |
|
Confirmed for 19w13b |
| Comment by [Helper] Jack McKalling [ 27/Mar/19 ] |
|
Confirmed for 19w13a |
| Comment by [Helper] Jack McKalling [ 21/Mar/19 ] |
|
Confirmed for 19w12b |
| Comment by [Helper] Jack McKalling [ 20/Mar/19 ] |
|
Confirmed for 19w12a |
| Comment by [Helper] Jack McKalling [ 14/Mar/19 ] |
|
Confirmed for 19w11b |
| Comment by [Helper] Jack McKalling [ 13/Mar/19 ] |
|
Confirmed for 19w11a |
| Comment by [Helper] Jack McKalling [ 28/Feb/19 ] |
|
Confirmed for 19w09a |
| Comment by [Helper] Jack McKalling [ 13/Feb/19 ] |
|
Confirmed for 19w07a |
| Comment by [Helper] Jack McKalling [ 06/Feb/19 ] |
|
Confirmed for 19w06a |
| Comment by [Helper] Jack McKalling [ 30/Jan/19 ] |
|
Confirmed for 19w04b and 19w05a |
| Comment by [Helper] Jack McKalling [ 24/Jan/19 ] |
|
Comfirmed for 19w04a |
| Comment by [Helper] Jack McKalling [ 19/Jan/19 ] |
|
Confirmed for 19w03c |
| Comment by [Helper] Jack McKalling [ 17/Jan/19 ] |
|
Confirmed for 19w03b |
| Comment by [Helper] Jack McKalling [ 16/Jan/19 ] |
|
Confirmed for 19w03a |
| Comment by [Helper] Jack McKalling [ 09/Jan/19 ] |
|
Confirmed for 19w02a |
| Comment by [Helper] Jack McKalling [ 12/Dec/18 ] |
|
Confirmed for 18w50a |
| Comment by [Helper] Jack McKalling [ 05/Dec/18 ] |
|
Confirmed for 18w49a |
| Comment by [Helper] Jack McKalling [ 30/Nov/18 ] |
|
Confirmed for 18w48b |
| Comment by [Helper] Jack McKalling [ 29/Nov/18 ] |
|
Confirmed for 18w48a |
| Comment by Kraif [ 19/Oct/18 ] |
|
Confirmed for 1.13.2-pre2. |
| Comment by Kraif [ 16/Oct/18 ] |
|
Confirmed for 1.13.2-pre1. |
| Comment by Kraif [ 22/Aug/18 ] |
|
Confirmed for the last snapshots (1.13.1-pre1, pre-2) and 1.13.1. |
| Comment by Kraif [ 15/Aug/18 ] |
|
Confirmed for 18w33a. |
| Comment by Kraif [ 08/Aug/18 ] |
|
Confirmed for 18w32a. |
| Comment by Kraif [ 01/Aug/18 ] |
|
Confirmed for 18w31a. |
| Comment by Kraif [ 26/Jul/18 ] |
|
Confirmed for 18w30b. |
| Comment by Kraif [ 25/Jul/18 ] |
|
Confirmed for 18w30a. |
| Comment by Kraif [ 18/Jul/18 ] |
|
Confirmed for 1.13. |
| Comment by Kraif [ 18/Jul/18 ] |
|
Confirmed for 1.13-pre10. |
| Comment by Kraif [ 17/Jul/18 ] |
|
Confirmed for 1.13-pre9. |
| Comment by Kraif [ 13/Jul/18 ] |
|
Confirmed for 1.13-pre8. |
| Comment by Pau Olivares [ 10/Jul/18 ] |
|
Confirmed in 1.13-pre7. |
| Comment by Pau Olivares [ 28/Jun/18 ] |
|
Confirmed for MC 1.13-pre4 too. |
| Comment by [Mod] NeunEinser [ 23/Jun/18 ] |
|
Can confirm for 1.13-pre3 |
| Comment by Pau Olivares [ 14/Jun/18 ] |
|
You could fix that adding a redstone torch near the non-activated rail. It worked for me.
|
| Comment by Léa Gris [ 28/Jan/18 ] |
|
Bug still present in 18w03b |
| Comment by [Mod] NeunEinser [ 26/Oct/17 ] |
|
Can confirm for 17w43a/b |
| Comment by Alugia [ 11/Aug/17 ] |
|
Confirmed for 1.12.1 |
| 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 Fabian Röling [ 09/Jun/16 ] |
|
Confirmed for 1.10. |
| Comment by Erik [ 25/Feb/16 ] |
|
Confirmed for 1.9-pre3 |
| Comment by Immaterialise [ 17/Feb/16 ] |
|
Confirmed for 1.9-pre1 |
| Comment by Pascal Roeleven [ 26/Jan/16 ] |
|
Confirmed for 16w03a. |
| Comment by James (inactive) [ 23/Dec/15 ] |
|
Confirmed for 1.8.9 and 15w51b. |
| Comment by Alexander [ 30/Oct/15 ] |
|
Confirmed for 15w44b |
| Comment by [Mod] Neko [ 03/Aug/15 ] |
|
Confirmed 15w31c |
| Comment by Jaden Speth [ 02/Jun/15 ] |
|
Confirmed in 1.8.6 |
| Comment by Jeremy [ 01/Nov/14 ] |
|
Confirmed in 1.8-pre 3. |
| Comment by Tintti214 [ 11/Aug/14 ] |
|
Still reproduceable in 14w32d! |
| Comment by kbk [ 07/Jul/14 ] |
|
Still not fixed as of 14w27b This can be exploited by mapmakers to create enormous self-powered tracks with but a pair of torches. |
| Comment by [Mod] Torabi [ 13/May/14 ] |
|
A redstone torch can normally only power a rail up to 9 blocks away, which makes a total of 17 rails in a row, if the torch is placed next to them. The bug here is that in some cases, redstone torches placed or removed next to an active powered rail are not updating the rails, meaning that some rails do not go inactive, while others do not become active. This means that a single torch can be made to power extremely long (perhaps infinite) sections of powered rail, if the torches are added and removed in the right places, and the right order. Placing or removing a torch only seems to update the rails if it is placed next to the last active powered rail in a row that is correctly powered by another torch. If it is the only torch within range, then the rails will be updated correctly. |
| Comment by Jeremiah [ 11/May/14 ] |
|
This is not a bug! You see, when you put redstone current (e.g, lever or redstone torch etc.) down it is carried through the rails. Thus, if you destroyed another redstone current, the other redstone current would be carried on. |
| Comment by Anonymous User [ 24/Apr/14 ] |
|
Confirmed in 14w11b. |
| Comment by Damien Claessen [ 23/Feb/14 ] |
|
I believe this bug has been present since powered rails were added. I've tested it back to 1.0 but not in beta 1.5 because of no creative mode back then. I'm surprised such an old bug hasn't been fixed lol. |
| Comment by Itouch2 [ 20/Feb/14 ] |
|
Still present in 08a |
| Comment by kbk [ 23/Jan/14 ] |
|
This is still valid indeed. |
| Comment by [Mod] Ezekiel (ezfe) [ 22/Jan/14 ] |
|
Is this still a concern in the latest Minecraft version 14w03b? 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 andrew hyland [ 30/Jun/13 ] |
|
still in 1.6.1 pre |
| Comment by Carl Lystad [ 04/Mar/13 ] |
|
Still in 13w10a. Redstone Blocks behave like the levers do in Nic's comment. |
| Comment by kbk [ 28/Feb/13 ] |
|
This affects 13w09b. Activator rails are affected as well. |
| Comment by Mustek [ 05/Feb/13 ] |
|
Still happens in 13w05b |
| Comment by lucky [ 16/Jan/13 ] |
|
This is still and issue in 1.4.7 and in Snapshot 13w02b The powered rail update changes slightly depending on the power source type(torch or leaver).
|
| Comment by Kumasasa [ 08/Dec/12 ] |
|
Confirmed for 12w49a |
| Comment by Robbie Lee [ 29/Oct/12 ] |
|
As you can see from the screenshot, more rails are powered one side of the torch than should be powered due to this bug. |
| Comment by Robbie Lee [ 29/Oct/12 ] |
|
Recreated in 1.4.2, moving the torch doesn't update the rails, normally only 8 rails are powered either side of the torch but with this bug I managed to get 16 rails powered one side of the torch this is because the rails don't update from their powered state once the torch is moved. |
| Comment by Ricardo Stryki [ 27/Oct/12 ] |
|
I'm spanish don't insult me man |
| Comment by kourchenkofouters [ 27/Oct/12 ] |
|
<Comment removed by MOD> |