Why does the train crash?

[Nemo4809]

train.jpg (141.44 KiB) Viewed 5158 times

The signal is red, it should stop and deadlock.

[boskid]

Train is allowed to pass red signal when red signal goes to a block that is already reserved or occupied by that train.

[Nemo4809]

Train is allowed to pass red signal when red signal goes to a block that is already reserved or occupied by that train.

Any reason for that? Just curious since it allows crashes to happen and seem to be an exception to train-signal behavior.

[boskid]

Any reason for that? Just curious since it allows crashes to happen and seem to be an exception to train-signal behavior.

https://factorio.com/blog/post/fff-299

[Nemo4809]

Any reason for that? Just curious since it allows crashes to happen and seem to be an exception to train-signal behavior.

https://factorio.com/blog/post/fff-299

Doesn’t explain why you would allow a train to enter a block that it itself is occupying though.

[netmand]

In the example track layout given in the FFF, if you put your long train on it, today's logic will let it through from right to left, despite leftmost signal between 3-2 will be red.

The real answer to your question: The train crashes because it was poorly scheduled for a track section that cannot handle its length. There's no value in it not crashing versus that behavior handling other situations where the train would need to cross into a block that it's still in.

[Nemo4809]

In the example track layout given in the FFF, if you put your long train on it, today's logic will let it through from right to left, despite leftmost signal between 3-2 will be red.

The real answer to your question: The train crashes because it was poorly scheduled for a track section that cannot handle its length. There's no value in it not crashing versus that behavior handling other situations where the train would need to cross into a block that it's still in.

I just think it's kind of silly. No train conductor will ignore a red signal in RL.

In the FFF example, the signals are poorly placed and things could easily be fixed by adding a signal to split the top curved track.

[darkfrei]

I just think it's kind of silly. No train conductor will ignore a red signal in RL.

In real life you have less crossings, less signals and less curves. There is no problem with rails self crossings.

[SyncViews]

The problem is with track as posted in the blog though. The games signal model can't handle this perfectly, at best they could add like a checkbox option but that is a lot of complexity.

In real life signalling is based on the path the train will take (and need to switch the points as such in advance as well anyway). You will notice there are way less signals, they are only in places where trains should stop and wait, not scattered between every point in a junction and immediately after a junction. You can see this in a few more transport orientated games.

I just think it's kind of silly. No train conductor will ignore a red signal in RL.

In real life you have less crossings, less signals and less curves.

Not really sure how true that is, some real life lines have some very complex junctions, and as for curves, well real life ones are far less tight, but almost straight tracks are pretty rare (mostly just the modern high speed lines). But what they don't have is 100's of signals all over the place, the routes trains will take and safely pass each other is planned ahead.

They also seem to plan the tracks out much more carefully, I looked at some quickly on Google maps where there is like 10 tracks from different directions crossing/merging at a station. There is a lot of "can't get there from here".

[Nemo4809]

The problem is with track as posted in the blog though. The games signal model can't handle this perfectly, at best they could add like a checkbox option but that is a lot of complexity.

In real life signalling is based on the path the train will take (and need to switch the points as such in advance as well anyway). You will notice there are way less signals, they are only in places where trains should stop and wait, not scattered between every point in a junction and immediately after a junction. You can see this in a few more transport orientated games.

I just think it's kind of silly. No train conductor will ignore a red signal in RL.

In real life you have less crossings, less signals and less curves.

Not really sure how true that is, some real life lines have some very complex junctions, and as for curves, well real life ones are far less tight, but almost straight tracks are pretty rare (mostly just the modern high speed lines). But what they don't have is 100's of signals all over the place, the routes trains will take and safely pass each other is planned ahead.

They also seem to plan the tracks out much more carefully, I looked at some quickly on Google maps where there is like 10 tracks from different directions crossing/merging at a station. There is a lot of "can't get there from here".

Unfortunately I’m unfamiliar with how real life trains work. However I’m fairly certain they don’t allow crashes and would prefer deadlocking than crashing - which kills and destroys property.

I do know some train systems don’t use rail side signals at all like the Shinkansen and instead use a centralized traffic control system.

https://en.wikipedia.org/wiki/Shinkansen#Signal_system

[DerGraue]

viewtopic.php?f=11&t=19619&p=302527#p302527

This used to happen before it was changed and it was extremely annoying. A small train could deadlock in all kinds of situations on itself. In your example your train can't path that way anyways and you would have to fix your rail layout.

[Beamup]

Unfortunately I’m unfamiliar with how real life trains work. However I’m fairly certain they don’t allow crashes and would prefer deadlocking than crashing - which kills and destroys property.

RL has very different considerations than a game. In Factorio, crashes are better than deadlocks in most cases - there's nobody to be killed and the resource loss is generally smaller than that caused by idle production due to deadlock.

Can you show an example where the current behavior causes the system to fail, but it could work if the behavior were something else? That would be a much more relevant motivation for change than a scenario which could never work no matter what.

[Nemo4809]

Unfortunately I’m unfamiliar with how real life trains work. However I’m fairly certain they don’t allow crashes and would prefer deadlocking than crashing - which kills and destroys property.

RL has very different considerations than a game. In Factorio, crashes are better than deadlocks in most cases - there's nobody to be killed and the resource loss is generally smaller than that caused by idle production due to deadlock.

Can you show an example where the current behavior causes the system to fail, but it could work if the behavior were something else? That would be a much more relevant motivation for change than a scenario which could never work no matter what.

IMHO the fact that it violates its own rules - i.e. an exception to the rule; to how signals work - is a good enough reason to change it.

What’s the benefit of this special rule? No one has explained it to me yet.

[Beamup]

Unfortunately I’m unfamiliar with how real life trains work. However I’m fairly certain they don’t allow crashes and would prefer deadlocking than crashing - which kills and destroys property.

RL has very different considerations than a game. In Factorio, crashes are better than deadlocks in most cases - there's nobody to be killed and the resource loss is generally smaller than that caused by idle production due to deadlock.

Can you show an example where the current behavior causes the system to fail, but it could work if the behavior were something else? That would be a much more relevant motivation for change than a scenario which could never work no matter what.

IMHO the fact that it violates its own rules - i.e. an exception to the rule; to how signals work - is a good enough reason to change it.

What’s the benefit of this special rule? No one has explained it to me yet.

The benefit is, as described in the FFF linked earlier, avoiding the crashes and desyncs caused by the old behavior.

The reality of software development is that any change comes with costs. Both the opportunity costs of whatever else could have been done with the same development time, and the risks inherent in any change to core behavior (see the last chart in the FFF). So if you want anything to actually be done beyond an entry in The Long List Of Things They Might Do Someday, a more practical motivation would really help that case.

But if your intent is to make more of a philosophical point than to bring about code changes, then I will say that I do agree with that philosophical point.

[Nemo4809]

Unfortunately I’m unfamiliar with how real life trains work. However I’m fairly certain they don’t allow crashes and would prefer deadlocking than crashing - which kills and destroys property.

RL has very different considerations than a game. In Factorio, crashes are better than deadlocks in most cases - there's nobody to be killed and the resource loss is generally smaller than that caused by idle production due to deadlock.

Can you show an example where the current behavior causes the system to fail, but it could work if the behavior were something else? That would be a much more relevant motivation for change than a scenario which could never work no matter what.

IMHO the fact that it violates its own rules - i.e. an exception to the rule; to how signals work - is a good enough reason to change it.

What’s the benefit of this special rule? No one has explained it to me yet.

The benefit is, as described in the FFF linked earlier, avoiding the crashes and desyncs caused by the old behavior.

The reality of software development is that any change comes with costs. Both the opportunity costs of whatever else could have been done with the same development time, and the risks inherent in any change to core behavior (see the last chart in the FFF). So if you want anything to actually be done beyond an entry in The Long List Of Things They Might Do Someday, a more practical motivation would really help that case.

But if your intent is to make more of a philosophical point than to bring about code changes, then I will say that I do agree with that philosophical point.

I'm not questioning why they do the reservations the way they do.

I'm questioning the reason for the "special rule" referenced in "there is a special rule, that a train can enter a reserved or occupied block as long as it is reserved by itself." - highlights by me. Why in heaven's name would you allow a train to enter an occupied block?

[Xeorm]

Unfortunately I’m unfamiliar with how real life trains work. However I’m fairly certain they don’t allow crashes and would prefer deadlocking than crashing - which kills and destroys property.

RL has very different considerations than a game. In Factorio, crashes are better than deadlocks in most cases - there's nobody to be killed and the resource loss is generally smaller than that caused by idle production due to deadlock.

Can you show an example where the current behavior causes the system to fail, but it could work if the behavior were something else? That would be a much more relevant motivation for change than a scenario which could never work no matter what.

IMHO the fact that it violates its own rules - i.e. an exception to the rule; to how signals work - is a good enough reason to change it.

What’s the benefit of this special rule? No one has explained it to me yet.

The benefit is, as described in the FFF linked earlier, avoiding the crashes and desyncs caused by the old behavior.

The reality of software development is that any change comes with costs. Both the opportunity costs of whatever else could have been done with the same development time, and the risks inherent in any change to core behavior (see the last chart in the FFF). So if you want anything to actually be done beyond an entry in The Long List Of Things They Might Do Someday, a more practical motivation would really help that case.

But if your intent is to make more of a philosophical point than to bring about code changes, then I will say that I do agree with that philosophical point.

I'm not questioning why they do the reservations the way they do.

I'm questioning the reason for the "special rule" referenced in "there is a special rule, that a train can enter a reserved or occupied block as long as it is reserved by itself." - highlights by me. Why in heaven's name would you allow a train to enter an occupied block?

Because there are legitimate reasons for a train to enter a block that's occupied by itself. Roundabouts being the obvious example.

Now, here's where the design problem gets fun. In a real world scenario you don't want the trains ever colliding. For obvious reasons. So there'd be additional checks in place for train size and signal positions to change the system to ensure no crashes occur. In this game though the trains crashing make more sense - it's far more illustrative to the player that a problem has occurred, and it's on them to fix.

Let's take the original example: train is too big to fit, hitting itself on the way back around. If the train were a little smaller, the system would work just fine. If the signal logic was changed the system wouldn't work, even though it should work. You'd have to do some fiddly changes for the signals in order for it to function. All of which would be annoying and counter intuitive. But here the player can see very simply "Hey, the train's too big for the loop" and think that they either need to shorten the train or lengthen the loop, or restrict the train from going through there. This is a much, much better outcome for everyone involved, and so it makes sense that this is what they did.

[Nemo4809]

Because there are legitimate reasons for a train to enter a block that's occupied by itself. Roundabouts being the obvious example.

Now, here's where the design problem gets fun. In a real world scenario you don't want the trains ever colliding. For obvious reasons. So there'd be additional checks in place for train size and signal positions to change the system to ensure no crashes occur. In this game though the trains crashing make more sense - it's far more illustrative to the player that a problem has occurred, and it's on them to fix.

Let's take the original example: train is too big to fit, hitting itself on the way back around. If the train were a little smaller, the system would work just fine. If the signal logic was changed the system wouldn't work, even though it should work. You'd have to do some fiddly changes for the signals in order for it to function. All of which would be annoying and counter intuitive. But here the player can see very simply "Hey, the train's too big for the loop" and think that they either need to shorten the train or lengthen the loop, or restrict the train from going through there. This is a much, much better outcome for everyone involved, and so it makes sense that this is what they did.

You could argue that having an exception to how signals obviously operate is more counter intuitive - a train blowing by a red signal. If a player is trying to learn how signals work, the game would be sending mixed messages.

The "fiddly changes" you speak of for a roundabout is just adding signals to split up the loop and/or make the loop bigger/shorten the train.

[Xeorm]

You could argue that having an exception to how signals obviously operate is more counter intuitive - a train blowing by a red signal. If a player is trying to learn how signals work, the game would be sending mixed messages.

The "fiddly changes" you speak of for a roundabout is just adding signals to split up the loop and/or make the loop bigger/shorten the train.

You could argue, sure. But I really don't think that'll be the first thought of people. The train is too big for this is much more likely the first thought than that they've misunderstood the fundamentals of the signal system. Indeed, even then my first thought would be "Huh, guess there's an except for when it is itself". The exception is pretty visible in this case. It would not be very visible with additional rules on how signals work.

[ptx0]

You could argue that having an exception to how signals obviously operate is more counter intuitive - a train blowing by a red signal. If a player is trying to learn how signals work, the game would be sending mixed messages.

The "fiddly changes" you speak of for a roundabout is just adding signals to split up the loop and/or make the loop bigger/shorten the train.

You could argue, sure. But I really don't think that'll be the first thought of people. The train is too big for this is much more likely the first thought than that they've misunderstood the fundamentals of the signal system. Indeed, even then my first thought would be "Huh, guess there's an except for when it is itself". The exception is pretty visible in this case. It would not be very visible with additional rules on how signals work.

you are arguing a theoretical person's theoretical response when there is a person here telling you their real response to this real issue.

i agree with the OP, this exception is dumb and should be removed, as it is only there to make ill-configured rail networks functional.

[Xeorm]

you are arguing a theoretical person's theoretical response when there is a person here telling you their real response to this real issue.

i agree with the OP, this exception is dumb and should be removed, as it is only there to make ill-configured rail networks functional.

My impression of the OP's post is the belief in how the network should work, and my explanation on why the network doesn't work that way. He understands what's wrong with the setup, and why it doesn't work, and wants to change things because he believes it should work differently. That is a very different discussion than discussing why it doesn't work.