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
is duplicated by 2
Attachments
Comments 8
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|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-1361 does 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-10889] also fixed this
Can confirm.