Factorio Forums

Xeorm wrote: Sat Feb 15, 2020 6:23 pm

ptx0 wrote: Sat Feb 15, 2020 6:08 pmyou 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.

well, in the original posts where kovarex initially decided not to change the behaviour, it was for the reasons OP and I described.

but someone managed to convince him that it would be a good change to make, for no better reason than they thought it should work that way.


so if anyone should be defending the change, it should be kovarex.

Assuming that the layout in the Op's post is for illustrative purposes, it can be simply fixed by increasing the size of the loop, or removing a cargo wagon. As for why it ignores itself at signals, we need to venture into more complex arrangements. Before the change - as explained in the linked blog, trains would seemingly deadlock at complex junctions, and round-a-bouts. Seemingly, because it was difficult for players to see beforehand why a train may deadlock, and not necessarily understand why it had, when it happened.

The rules are simple, and worked in most situations.

Don't enter a reserved block.

However, when that reserved block is the tail end of that very same train (consider more complex junctions where the train may actually cover more than one block) The deadlock was arising all too commonly. Technically, the old rule was correct, but the simple rule was problematic.

The only exception made to the simple rule was to allow a train with the same ID to enter the block. The result, while not technically correct, prevents a deadlock happening when a train encounters itself. The downside is it may, in exceptional circumstances as seen in the OP's image, cause the train to crash into itself.

The rule now is;

Don't enter a reserved block unless it is reserved by the same train ID

Further checks and rules could be added to mitigate against this for sure, but at what programmatic and performance cost? Every train would need to be constantly checking every path available for length of track compared to its own length on the rare chance that it might encounter itself. I'm not sure calling the Devs stupid for making this change will win much traction in getting it reversed.

Factorio is about problem solving, and bad design decisions on the player's part are de rigueur. A bad loop or junction layout that causes a train to crash with itself is far easier to understand and remedy than a mistake in signalling in tight space that makes the whole train network deadlock for obscure reasons. The most pragmatic cure for deadlocks was taken even if it is not technically correct.

Squelch wrote: Sun Feb 16, 2020 12:32 am Assuming that the layout in the Op's post is for illustrative purposes, it can be simply fixed by increasing the size of the loop

it would necessitate resizing every single loop on the network because the train pathfinder does not apply a penalty to paths that would result in a train occupying its own block, i.e. collision on a loop.

i don't need all the loops on my network to be sized for large trains because i've provided paths they should go down, instead.

but with the current behaviour i must physically make it impossible for a small train loop to affect a large train by using separate rail networks.

also, i don't buy this thing you keep saying that if a train deadlocks instead of crashing into itself that it would be an "obscure reason", instead of deadlocking the train should say No Path, if there really is no other path to get there.

it's not that big of a computational leap either, the train pathfinder is already iterating serially through each possible segment in the list, it just now must check (as it did at one time before) whether the next block would be already occupied by itself. the block IDs are the same and it would be as simple as saying "if current_block_id === next_block_id".

ptx0 wrote: Sun Feb 16, 2020 10:23 pm ...

Nobody is forcing any particular design philosophy upon you. Factorio is good like that.

If you must insist on causing a train to deadlock in loops and complex junctions, there are two options available to you.

1. Add an extra slave signal via circuit network to follow the original signal's state causing the train to obey this new signal regardless of mutual collision.
2. Download and play an older version pre the changes made for this particular situation.

The net result will be the same I promise - no other train will be able to pass that section of track upon deadlock.

I have no energy for non sequiturs, so instead supply you with just one of the historic issues that might help explain why we are where we are now.

[0.12.22] [Dominik] Train block its own path with chain signals

Yes it really does go back a long way, and I'm sure there are many more examples and discussions to be found.

Squelch wrote: Sun Feb 16, 2020 11:16 pm

ptx0 wrote: Sun Feb 16, 2020 10:23 pm ...

Nobody is forcing any particular design philosophy upon you. Factorio is good like that.

If you must insist on causing a train to deadlock in loops and complex junctions, there are two options available to you.

1. Add an extra slave signal via circuit network to follow the original signal's state causing the train to obey this new signal regardless of mutual collision.
2. Download and play an older version pre the changes made for this particular situation.

The net result will be the same I promise - no other train will be able to pass that section of track upon deadlock.

I have no energy for non sequiturs, so instead supply you with just one of the historic issues that might help explain why we are where we are now.

[0.12.22] [Dominik] Train block its own path with chain signals

Yes it really does go back a long way, and I'm sure there are many more examples and discussions to be found.

your tone when approaching this issue leaves much to be desired, considering you aren't even a developer, please, go away.

Squelch wrote: Sun Feb 16, 2020 12:32 am Assuming that the layout in the Op's post is for illustrative purposes, it can be simply fixed by increasing the size of the loop, or removing a cargo wagon. As for why it ignores itself at signals, we need to venture into more complex arrangements. Before the change - as explained in the linked blog, trains would seemingly deadlock at complex junctions, and round-a-bouts. Seemingly, because it was difficult for players to see beforehand why a train may deadlock, and not necessarily understand why it had, when it happened.

The rules are simple, and worked in most situations.

Don't enter a reserved block.

However, when that reserved block is the tail end of that very same train (consider more complex junctions where the train may actually cover more than one block) The deadlock was arising all too commonly. Technically, the old rule was correct, but the simple rule was problematic.

The only exception made to the simple rule was to allow a train with the same ID to enter the block. The result, while not technically correct, prevents a deadlock happening when a train encounters itself. The downside is it may, in exceptional circumstances as seen in the OP's image, cause the train to crash into itself.

The rule now is;

Don't enter a reserved block unless it is reserved by the same train ID

Further checks and rules could be added to mitigate against this for sure, but at what programmatic and performance cost? Every train would need to be constantly checking every path available for length of track compared to its own length on the rare chance that it might encounter itself. I'm not sure calling the Devs stupid for making this change will win much traction in getting it reversed.

Factorio is about problem solving, and bad design decisions on the player's part are de rigueur. A bad loop or junction layout that causes a train to crash with itself is far easier to understand and remedy than a mistake in signalling in tight space that makes the whole train network deadlock for obscure reasons. The most pragmatic cure for deadlocks was taken even if it is not technically correct.

I'm less concerned with trains entering blocks they reserved. I mean why else would you reserve a block if you aren't allowed to enter it.

I'm more concerned that trains are entering blocks that are occupied.

ptx0 wrote: Sun Feb 16, 2020 10:23 pm with the current behaviour i must physically make it impossible for a small train loop to affect a large train by using separate rail networks.

How does the proposed behavior make this not necessary? Crash or deadlock, the actual problem here is the train and intersection do not work well together and will need addressed by the player or they will continue to have issues.

5thHorseman wrote: Mon Feb 17, 2020 6:30 am

ptx0 wrote: Sun Feb 16, 2020 10:23 pm with the current behaviour i must physically make it impossible for a small train loop to affect a large train by using separate rail networks.

How does the proposed behavior make this not necessary? Crash or deadlock, the actual problem here is the train and intersection do not work well together and will need addressed by the player or they will continue to have issues.

wut? because the pathfinder would decide whether the path were valid in the early phase and not send a train somewhere it can't go.

try to run a long artillery train across a city block map. you are better off manually guiding it with temporary stations the whole way.

Nemo4809 wrote: Mon Feb 17, 2020 2:25 am I'm less concerned with trains entering blocks they reserved. I mean why else would you reserve a block if you aren't allowed to enter it.

I'm more concerned that trains are entering blocks that are occupied.

For the purposes of this exercise, a reserved block and an occupied block are equivalent. The exception was added for - same train - block occupation which alleviates the difficult deadlocks that were commonly being seen, and as highlighted in the old report I cite. The unfortunate downside is that there is the possibility of a long train colliding with itself.

ptx0 wrote: Sun Feb 16, 2020 10:23 pm it's not that big of a computational leap either, the train pathfinder is already iterating serially through each possible segment in the list, it just now must check (as it did at one time before) whether the next block would be already occupied by itself. the block IDs are the same and it would be as simple as saying "if current_block_id === next_block_id".

Simply saying "just check if block ids are same" is not problem solving. First of all: train pathfinder gets its performance because of optimal substructure. This means that when pathfinder goes through nodes, if node is already expanded, it will never be expanded again because that would mean there was shorter path after expansion, that would mean there is priority queue implementation issue or there is negative weight somewhere. None of these apply here. Since every node will be expanded at most once, pathfinder is not allowed to "back off" some amount of nodes. Here if path goes from left of node 1, when node 1 is expanded, nodes 2 and 3 are added to open set and their current cost from start is set. Node 2 is processed next, this adds node 4 into open set with cost set, node 2 is closed. Next is node 3: when expanding it could update node 4 but cost by this path is higher, node 3 is closed. Next goes node 4 - if it would be the final node (train stop at the end), path would be reconstructed based of information from which node path came from (4 from 2, 2 from 1, 1 from start). There is no good (by performance) place to add check if current nodes block was already visited. It would require visiting whole cameFrom history of nodes when expanding every node that would be CPU expensive, or for every node would require keeping set of all blocks that were visited so far, that would be memory expensive. And that information would be useless because now trains would be prevented from choosing any path that would contain same block twice, even if train could not collide with itself. There is also no shortcut of "lets check if given block was already visited" because this would make every junction broken as expanding one leg would prevent other leg from being expanded.

Lets say we solved above issue and we found a way to detect during nodes expansion which nodes should not be expanded because train would collide with itself. In above sketch, lets assume segment under node 1 crosses somewhere with segments under node 4. Train is long enough that when path goes through node 2, train will collide with itself but when going through node 3, it will pass without a collision. So now when expanding node 4, your check would say "do not go that way, there would be a collision" and pathfinder would either return "no path" (wrong, since there exists path through node 3), or would be forced to reevaluate already closed nodes (node 4 but going from node 3). That would mean performance of pathfinder would drop a lot and for every rail segment there would be a lot more nodes to expand (every node would be related to another history of decisions, so there would be node 4a - for path going from node 2 - and 4b
- for path going from node 3) and this amount could increase a lot in case of multiple paths of same cost in a cascade.

Another problem to solve would be how to decide if train will fit on a given path. By simply taking length of train you will be off when train goes through curves since joint distances are not counted along rails. There would be also need to check at which distance rail segments would collide and how to handle cases where 2 rails would collide with each other multiple times. Doing perfect train movement simulation would be CPU expensive.

Lets say another approach would be taken: Make it impossible for a train to pass a red signal (even when trains are not interested in signals, they are interested in blocks and their reservations, signals are only artifacts that are computed based of blocks state - that would be in fact "prevent train from entering a new block that is already occupied, even if it is occupied by itself"). In case of path that would go through one block multiple times, train would have to slow before signal that goes to that block for the second time since braking point would not be able to pass that signal as block could still be occupied by back of that train. What if all signals in between would be rail chain signals? Should train be allowed to stop in the middle of intersection? That would be a bug since trains that enters chain signal section should be able to leave (that is it reserves all necessary blocks or none of them). Or should it be prevented from acquiring reservation for whole chain signal section? that would again require trains length that would not be exact, or whole trains movement simulation that would be CPU expensive.

Another issue: Trains reserve signals in advance based on its braking distance. What if that braking distance would require block's reservation twice (train is going fast or has slow deceleration) when train is not yet inside that block? That is, there would be something like "Train -- block a -- block b -- block a --> braking distance". To prevent this from happening, braking point would be not allowed to reserve "block a" for second time and whole "multiple reservations" solution could be thrown away through a window.

ptx0 wrote: Mon Feb 17, 2020 12:58 am your tone when approaching this issue leaves much to be desired, considering you aren't even a developer, please, go away.

*cough*

ptx0 wrote: Mon Feb 17, 2020 7:34 am wut? because the pathfinder would decide whether the path were valid in the early phase and not send a train somewhere it can't go.

But i will not be changing pathfinder as to prevent them from colliding since pathfinder works under assumption of 0-length train and collisions when happen, are quite funny

train would have to slow before signal that goes to that block for the second time since braking point would not be able to pass that signal as block could still be occupied by back of that train. What if all signals in between would be rail chain signals? Should train be allowed to stop in the middle of intersection? That would be a bug since trains that enters chain signal section should be able to leave

trains don't have to slow, you can dead-stop it and mark it as No Path.

train should be able to leave but I can also design a train network and send a train on a path where it will never be able to get to subsequent stations in its schedule once it gets to the first stop. I don't see a problem with some "strange behaviour" that stops all trains for the player to investigate. (it is really, not so strange, to see a train stop before it goes to end its own life)

hell, even if you want to be more creative, add a new error state similar to No Path that will dead stop a train and mark as Conflicted.

Squelch wrote: Mon Feb 17, 2020 8:18 am

Nemo4809 wrote: Mon Feb 17, 2020 2:25 am I'm less concerned with trains entering blocks they reserved. I mean why else would you reserve a block if you aren't allowed to enter it.

I'm more concerned that trains are entering blocks that are occupied.

For the purposes of this exercise, a reserved block and an occupied block are equivalent. The exception was added for - same train - block occupation which alleviates the difficult deadlocks that were commonly being seen, and as highlighted in the old report I cite. The unfortunate downside is that there is the possibility of a long train colliding with itself.

Just noticed your link. So it's an exception added to allow insignificantly signaled train networks to run?

The train system is not easy to grasp - not without outside help, e.g. tutorials. However, if the player is to get anywhere with trains, they are going to have to eventually learn how the train system works (what blocks are and how the signals work) and what are good practices (thankfully others have already figured this out).

I don't see the point in coddling the player in this case.

ptx0 wrote: Mon Feb 17, 2020 10:08 am I can also design a train network and send a train on a path where it will never be able to get to subsequent stations in its schedule once it gets to the first stop.

Exactly. There is nothing in Factorio that prevents you from shooting yourself in the foot. There is nothing that prevents you from killing yourself with a badly aimed nuclear bomb. There is nothing that prevents you contaminating a belt if you mess up your belt placement. There is nothing that prevents you from causing train collisions by driving manually. There is nothing that prevents you from designing a rail network, where half the stations simply can't be reached. There is nothing that prevents you from designing intersections which are likely to deadlock.

But the interesting gameplay comes from using nuclear bombs to clear biters, from designing belt layouts that work, and from designing rail networks which work (trains being able to path to their appropriate destinations, intersections that don't deadlock, some automated arrangement for refueling trains). Most of these are interesting because they are about design and layout and analysing and solving problems.

There is nothing in Factorio that prevents you from designing a factory where all the tracks/stations are reachable, or where trains will never collide or deadlock. It all comes down to how you as the player design your factory and rail network.

I see nothing in this thread that I consider a bug that should to be fixed by the devs. Everything can be fixed by smarter rail design by players. (You just need to make sure that every loop is larger than the longest train that will use that loop. This is similar to preventing deadlocks by making sure that the exit block for every intersection is large enough to hold the longest train that will use that intersection). (Indeed I would argue that the only real 'bug' present is that the game doesn't communicate the bit about a train being able to reserve the same block twice, which led Nemo to ask why doesn't the train stop at the red signal in the OP).

Also don't forget the situation in the following image. That is all one block. If you consider it as one intersection, you can even argue that it is correctly signalled. (Yeah you could argue that it should have more signals, but technically one signal on every approach and one signal every exit to an intersection, leaving the intersection itself as one large block, is enough to prevent collisions, assuming self intersecting loops aren't involved). Are you going to argue that the train should be prevented from self collision is that situation as well? Or that the onus should be on the player to design a rail network where that isn't an issue?

Nemo4809 wrote: Mon Feb 17, 2020 11:02 am Just noticed your link. So it's an exception added to allow insignificantly signaled train networks to run?

In essence, yes, I believe this was the case.

The train system is not easy to grasp - not without outside help, e.g. tutorials. However, if the player is to get anywhere with trains, they are going to have to eventually learn how the train system works (what blocks are and how the signals work) and what are good practices (thankfully others have already figured this out).

You are quite right. The same block, same train, deadlock situation can be quite frustrating and difficult to both plan for, and/or understand or be explained by those that do understand, in more complex junction arrangements. They were often reported as pathing bugs IIRC.

I don't see the point in coddling the player in this case.

That is subjective of course. The subtle gotcha's that same block, same train deadlocks were causing can be acknowledged as perfectly correct and expected behaviour. However, it was often complained about, and I assume the most pragmatic solution (and there are probably other technical reasons) seems to have been the addition of the exception with the downside of trains possibly eating themselves in some rare cases.

All told, the ultimate answer to your original question as posed in the OP -

Why does the train crash?

Because of the deliberate exception that was added quite some time ago to prevent subtle deadlock situations occurring, as opposed to the more obvious "this train does not fit this track layout"

Zavian wrote: Mon Feb 17, 2020 11:23 am Exactly. There is nothing in Factorio that prevents you from shooting yourself in the foot. There is nothing that prevents you from killing yourself with a badly aimed nuclear bomb. There is nothing that prevents you contaminating a belt if you mess up your belt placement. There is nothing that prevents you from causing train collisions by driving manually. There is nothing that prevents you from designing a rail network, where half the stations simply can't be reached. There is nothing that prevents you from designing intersections which are likely to deadlock.
...

Nicely put.

I would say the same point applies to the perennial "give me a magic button which stops too many trains picking the same stop because I built a lot of trains that all pick the same stop" threads.

Zavian wrote: Mon Feb 17, 2020 11:23 am
Exactly. There is nothing in Factorio that prevents you from shooting yourself in the foot.

Except the point of signals is to prevent collisions and deadlocks - if used properly.

They give you the tools to fix things ... except the tools didn’t work as expected because of an exception programmed into them.

Squelch wrote: Mon Feb 17, 2020 11:33 amWhy does the train crash?

Because of the deliberate exception that was added quite some time ago to prevent subtle deadlock situations occurring, as opposed to the more obvious "this train does not fit this track layout"

I kind of see it as

"because the tool provide by the game to prevent collisions did not work as advertised"

I don't believe this special exception was ever mentioned in the mini-tutorials - heck, even if it was, I probably forgot about it as I was overwhelmed with information and desperately trying to grasp how the signals work; and how I should be using them.

ptx0 wrote: Mon Feb 17, 2020 7:34 am because the pathfinder would decide whether the path were valid in the early phase and not send a train somewhere it can't go.

Does the train pathfinder take into account the train's length? I've never seen indication - or indeed need - of this. Or are you proposing they add that functionality?

Deadlock989 wrote: Mon Feb 17, 2020 11:42 am

Zavian wrote: Mon Feb 17, 2020 11:23 am Exactly. There is nothing in Factorio that prevents you from shooting yourself in the foot. There is nothing that prevents you from killing yourself with a badly aimed nuclear bomb. There is nothing that prevents you contaminating a belt if you mess up your belt placement. There is nothing that prevents you from causing train collisions by driving manually. There is nothing that prevents you from designing a rail network, where half the stations simply can't be reached. There is nothing that prevents you from designing intersections which are likely to deadlock.
...

Nicely put.

I would say the same point applies to the perennial "give me a magic button which stops too many trains picking the same stop because I built a lot of trains that all pick the same stop" threads.

Amusingly I was going to apply it to the "we can't limit the number of trains per station because it could cause trains to suddenly no-path if the player didn't set them up correctly" argument.

As was said above, everything is subjective.