[MC-3114] Activated detector-rails moved by a piston keep their activated state Created: 15/Nov/12  Updated: 22/Nov/17  Resolved: 04/Mar/13

Status: Resolved
Project: Minecraft: Java Edition
Component/s: None
Affects Version/s: Minecraft 1.4.4, Minecraft 1.4.7, Snapshot 13w02b, Snapshot 13w05b, Snapshot 13w06a
Fix Version/s: Snapshot 13w10a

Type: Bug
Reporter: Florian K Assignee: [Mojang] Jeb (Jens Bergensten)
Resolution: Fixed Votes: 3
Labels: detector, minecart, piston

Attachments: PNG File 2013-02-16_17.48.16.png     PNG File 2013-02-28_15.09.44.png     File mc3114.schematic     PNG File piston-detector1.png     PNG File piston-detector2.png     PNG File piston-detector3.png    
Issue Links:
Duplicate
is duplicated by MC-8465 Detector rails being pushed by piston... Resolved
is duplicated by MC-9445 Detector Rail powers redstone underne... Resolved
Relates
relates to MC-54818 A powered rail that should be unpowered Resolved
CHK:
Confirmation Status: Confirmed

 Description   

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.



 Comments   
Comment by [Mojang] Jeb (Jens Bergensten) [ 04/Mar/13 ]

As far as I can see, my fix to MC-10889 also fixed this

Comment by kbk [ 28/Feb/13 ]

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.

Comment by Florian K [ 16/Feb/13 ]

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.

Comment by kbk [ 16/Feb/13 ]

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

Comment by Florian K [ 16/Feb/13 ]

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?

Comment by kbk [ 16/Feb/13 ]

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.

Comment by kbk [ 02/Feb/13 ]

Affects 13w05b.

Comment by [Mod] CubeTheThird [ 21/Nov/12 ]

Can confirm.

Generated at Sun Jan 12 12:00:08 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.