[MC-753] Double T-Junction Rail problem Created: 26/Oct/12  Updated: 27/Jan/14  Resolved: 21/Oct/13

Status: Resolved
Project: Minecraft: Java Edition
Component/s: None
Affects Version/s: Minecraft 1.4.2, Minecraft 1.4.7, Snapshot 13w04a, Snapshot 13w10a, Snapshot 13w10b, Minecraft 1.5, Snapshot 13w11a, Minecraft 1.5.1, Minecraft 1.5.2, Minecraft 1.6.1, Minecraft 1.6.2
Fix Version/s: None

Type: Bug
Reporter: Jochen Theodorou Assignee: Unassigned
Resolution: Works As Intended Votes: 6
Labels: None
Environment:

Ubuntu 64bit


Attachments: PNG File 2013-01-27_11.46.50.png     PNG File 2013-01-27_11.47.12.png     PNG File 2013-01-27_11.47.26.png     JPEG File step1.jpg     JPEG File step2.jpg     JPEG File step3.jpg     JPEG File step4.jpg     JPEG File step5.jpg    
Issue Links:
Relates
relates to MC-14574 Rails not changing direction if there... Reopened
CHK:
Confirmation Status: Confirmed

 Description   

Problem:
Once you get the rails into a configuration as seen in the attached
You cannot change the orientation through a signal anymore.

"What I expected to happen was...":
The button press can still change the orientation

"What actually happend was...":
The signal is simply ignored

"Steps to reproduce":
1.) Arrange the rails in an S like in
Under each bent there is a button.
2.) add the missing rails like in
3.) press a buttons to see one of the rails moving like in and
4.) press the buttons to form the figure seen in

Once this configuration is reached you can press the buttons as much as you want, the rails won't change.

This bug appears also in 1.3.2. I did not test 1.3.1. I didn't check if the single player mode is affected as well (but I would assume it is).

The problem with this bug is, that it requires some structure to be build bigger than needed, since you need to place an extra rail between the two bent ones. Also, if you accidentally get into the configuration of step5.jpg, you are stuck and need to rebuild.



 Comments   
Comment by Jochen Theodorou [ 27/Jan/14 ]

Since no one did answer I guess the answer of what the intension is, is simply: minecraft can't be changed this way.

Comment by Jochen Theodorou [ 22/Oct/13 ]

Since this got closed as "Works as intended" can somebody please explain me why this works as intended and what the intension is here?

Comment by kbk [ 06/Mar/13 ]

Can confirm in 13w10b. Not sure if not intended though.

Comment by Jochen Theodorou [ 02/Feb/13 ]

Alex, my (and not only my) stations are broken, yes, because I expected this to work and it does not. Basically you speak against all behavioural changes. If that is the policy for minecraft, then things like the Redstone update should never happen as well.

Comment by Alex Campbell [ 01/Feb/13 ]

Pressing the button leads to step3/4.jpg because only the rail that receives the redstone signal is affected.
Your proposed changes would not prevent any rails from switching that could switch before, but they will make rails switch that did not switch before, possibly breaking things.

Your stations are broken, not the game, and I don't think Mojang will change a game mechanic that isn't broken in order to fix someone's minecart stations while breaking a lot of other ones.

Comment by Jochen Theodorou [ 01/Feb/13 ]

Alex, if you argument like that, then pressing a button from the configuration in step2.jpg, should not lead to a configuration as shown in step3.jpg/step4.jpg but instead directly to the configuration shown in step5.jpg. And then I would expect that pressing a button would change step5 into step2. I would still not expect step5 to be a "final" configuration. Coming from that direction, that it doesn't care whether the other piece stays connected or not, seems to be wrong to me. I can understand implementation wise why it is like this now, but that doesn't make it right

The problem with corner rail is then to define how they switch. An isolated (nowhere connected) corner rail has in theory two ways to switch, thus should not. If we don't use connected, but possibly connected and that simply as "there is another rail" and don't care about the orientation of that rail, then I could define the following rules: A rail with 0, 2 or 4 possible connections cannot switch. A corner rail with one possible connection can switch the unconnected side. A corner rail with 3 possible connections can switch the opposite directions, meaning east-west or north-south. Please note: I define here only the way a corner rail can switch, not how a rail becomes a corner rail

These rules are local enough for the implementation, since it has no cascading effects. The cases with 0,2 and 4 possible connections are today also not switchable, thus it does not disable anything that could switch before. And they allow my double T-Junction to work.

I strongly assume that the switching rules are as they are because of the event of placing a rails, in other words: from how to make them a corner rail. And I think those should be different rule sets.

Comment by Alex Campbell [ 01/Feb/13 ]

When there are two different ways a corner rail piece could connect, a redstone signal will switch between them.
In step2.jpg, both of the corner pieces can switch directions while still connecting (note that it doesn't care whether the other piece stays connected or not).
In step5.jpg, neither piece can switch direction without becoming disconnected at one end.

Comment by Jochen Theodorou [ 29/Jan/13 ]

If that is how they are intended to work, then you can surely explain what the reason for this behaviour is. For me I see I can flip directions with a button normally. But here it stops working once a certain configuration is reached. So what is the reason for being able to switch the rails into a fixed position, that is no escaping from?

Comment by Alex Campbell [ 29/Jan/13 ]

Has this design ever worked? This is how rails are intended to work...

Comment by Kumasasa [ 27/Jan/13 ]

Confirmed. See screenshots.

Comment by A Full Name [ 11/Jan/13 ]

This is horrible. I have designed several different railway stations that totally depend on double T-junctions to work correctly. I never got around to building any of them, and I guess I never will, because all of them are very tightly knit and intolerant of change. I can't fix them to work around this bug, so I'll have to discard them all and redesign from scratch.

Generated at Sun Jan 12 11:52:06 UTC 2025 using Jira 9.12.2#9120002-sha1:301bf498dd45d800842af0b84230f1bb58606c13.