MC-3114Activated detector-rails moved by a piston keep their activated state
Detector rails, which were activated by a minecart upon them, keep their active-state when moved by a piston, although there isn't minecart upon afterwards.
Detector rails affected by this bug can't be manually reset to normal function, they however change back to normal function after a certain time.
What I expected to happen was...:
As there is no minecart upon them any more, after movement the detector-rail should change to off-mode.
What actually happened was...:
Instead, the detector-rail keeps it's on state for a certain time.
Steps to Reproduce:
1. Place a minecart on a detector rail
2. Move the detector rail (horizontally) with a piston
3. The detector rail stays on unexpectedly, although there is no cart on it.
Update (16.2.2013)
As noticed by user kbk, not only the rail's state is messed up, when the detector-rail is moved, but also the underlying block does not get/send it's updates properly too.
Linked Issues
Created Issue:
Activated detector-rails moved by a piston keep their activated state
Detector rails, which were activated by a minecart upon them, keep their active-state when moved by a piston, although there isn't minecart upon afterwards.
Detector rails affected by this bug can't be manually reset to normal function, they however change back to normal function after a certain time.What I expected to happen was...:
As there is no minecart upon them any more, after movement the detector-rail should change to off-mode.What actually happened was...:
Instead, the detector-rail keeps it's on state for a certain time.Steps to Reproduce:
1. Place a minecart on a detector rail
2. Move the detector rail (horizontally) with a piston
3. The detector rail stays on unexpectedly, although there is no cart on it.
Attachments3
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
is duplicated by
is duplicated by
Detector rails, which were activated by a minecart upon them, keep their active-state when moved by a piston, although there isn't minecart upon afterwards.
Detector rails affected by this bug can't be manually reset to normal function, they however change back to normal function after a certain time.What I expected to happen was...:
As there is no minecart upon them any more, after movement the detector-rail should change to off-mode.What actually happened was...:
Instead, the detector-rail keeps it's on state for a certain time.Steps to Reproduce:
1. Place a minecart on a detector rail
2. Move the detector rail (horizontally) with a piston
3. The detector rail stays on unexpectedly, although there is no cart on it.
- - Update (16.2.2013) - *
Detector rails, which were activated by a minecart upon them, keep their active-state when moved by a piston, although there isn't minecart upon afterwards.
Detector rails affected by this bug can't be manually reset to normal function, they however change back to normal function after a certain time.What I expected to happen was...:
As there is no minecart upon them any more, after movement the detector-rail should change to off-mode.What actually happened was...:
Instead, the detector-rail keeps it's on state for a certain time.Steps to Reproduce:
1. Place a minecart on a detector rail
2. Move the detector rail (horizontally) with a piston
3. The detector rail stays on unexpectedly, although there is no cart on it.
- - Update (16.2.2013) - *
Detector rails, which were activated by a minecart upon them, keep their active-state when moved by a piston, although there isn't minecart upon afterwards.
Detector rails affected by this bug can't be manually reset to normal function, they however change back to normal function after a certain time.What I expected to happen was...:
As there is no minecart upon them any more, after movement the detector-rail should change to off-mode.What actually happened was...:
Instead, the detector-rail keeps it's on state for a certain time.Steps to Reproduce:
1. Place a minecart on a detector rail
2. Move the detector rail (horizontally) with a piston
3. The detector rail stays on unexpectedly, although there is no cart on it.
- - Update (16.2.2013) - *
As noticed by user kbk, not only the rail's state is messed up, when the detector-rail is moved, but also the underlying block does not get/send it's updates properly too.
Detector rails, which were activated by a minecart upon them, keep their active-state when moved by a piston, although there isn't minecart upon afterwards.
Detector rails affected by this bug can't be manually reset to normal function, they however change back to normal function after a certain time.What I expected to happen was...:
As there is no minecart upon them any more, after movement the detector-rail should change to off-mode.What actually happened was...:
Instead, the detector-rail keeps it's on state for a certain time.Steps to Reproduce:
1. Place a minecart on a detector rail
2. Move the detector rail (horizontally) with a piston
3. The detector rail stays on unexpectedly, although there is no cart on it.
- - Update (16.2.2013) - *
As noticed by user kbk, not only the rail's state is messed up, when the detector-rail is moved, but also the underlying block does not get/send it's updates properly too.Detector rails, which were activated by a minecart upon them, keep their active-state when moved by a piston, although there isn't minecart upon afterwards.
Detector rails affected by this bug can't be manually reset to normal function, they however change back to normal function after a certain time.What I expected to happen was...:
As there is no minecart upon them any more, after movement the detector-rail should change to off-mode.What actually happened was...:
Instead, the detector-rail keeps it's on state for a certain time.Steps to Reproduce:
1. Place a minecart on a detector rail
2. Move the detector rail (horizontally) with a piston
3. The detector rail stays on unexpectedly, although there is no cart on it.Update (16.2.2013)
As noticed by user kbk, not only the rail's state is messed up, when the detector-rail is moved, but also the underlying block does not get/send it's updates properly too.
![[Mojang] Jeb (Jens Bergensten)](../../../data/assets/gravatar/jeb.jpeg){kind=small}
[Mojang] Jeb (Jens Bergensten)
relates to
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
Duplicate of MC-3114, please use the search function to see if your bug has already been submitted. Currently over 50% of tickets are being closed as duplicate.
This report is closely related to MC-3114 (and even dupes a part of it). Hope that is going to be fixed as well.
On Bedrock, Dectector Rails remains active after moved using sticky piston with minecart on this rail. I expect should return to deactivate state.
I’ve tried this on a slime block but the issue is the same.
This is the same as a fault resolved in 2013 for Java Edition MC-3114.--
https://bugs.mojang.com/browse/MC-3114
Can confirm.
Affects 13w05b.
I've just built a small device which recreates this report in a little bit different manner and highlights its possible relation to
MC-1361(at least I think these two could be connected). In this device the piston is retracted by the signal from the detector rail. If the delay of this signal is not long enough, device locks itself like a latch, and then blocks around the quartz pillar block under the detector become able to detect block updates.Here's a schematic for snapshots, feel free to play around.
Thanks for keeping this alive and updated!^^
@kbk: I agree, those Problems could be related somehow. However this here resets itself to correct function after some time, I'm not sure if
MC-1361does that.And sorry, I'm not quite sure, what your constructions is meant to demonstrate. I think it's more of a combination of multiple bugs/weird behaviors and not our core bug here?
@Florian
Yes, but the goal I was trying to accomplish here is to show that while a detector rail is, technically, a two-block redstone device (it strongly powers itself and a block it's attached to when active), not only the rail's state is messed up in this case, the underlying block does not get/send its updates properly too. So that when you power the piston off a rail - you get yourself a clock, and when you do the same off the quartz pillar under the rail - you get a BUD-latch. I suppose the latter effect is the direct logical conclusion of the rail's awkward reaction to being pushed.
Thank you, now I understand, what you mean. I added a short line to the describtion.
Seems like detector rails are even more screwed up, than I thought...
I hope this might get fixed with the big Redstone-Update, although this bug only affects few people.
In my case: I tried to build minecart-slots for a storage-system with combined boost-out/occupation-detection by switching from a detector-rail to a booster-rail using pistons, but this bug made it impossible (Booster-rails were actually not affected by this problem, but work as intended!). The occupation-detection should have set the path of the rails to the slots on hold, therefore avoiding minecarts getting returned to the wrong slot. I then had to use a time-based hold-circuit, which is however not fully error-proof.
Affects 13w09b.
Built a device that draws power from every possible source of the setup (normal detector - block under the detector - pushed detector - block under pushed detector). Apparently, when active detector is pushed, the block that gets under the detector can act as a separate power source if the adjacent redstone receives a block update.
As far as I can see, my fix to
MC-10889also fixed this