Can trains ever crash into gates across tracks?

[DRY411S]

After hundreds of hours where I have pushed biters back dozens of chunks away, and sealed the chokepoints, I've suddenly lost a gate tile. I have not been anywhere near this area for (I estimate) over 100 hours. The map is 280 hours old.

What could cause this? Can trains sometimes hit them?

Screenshot 2024-03-03 140906.png (341.18 KiB) Viewed 1299 times

Screenshot 2024-03-03 142144.png (12.37 KiB) Viewed 1299 times

[DRY411S]

It's nowhere near the borders/chokepoints I should add

Screenshot 2024-03-03 142438.png (219.11 KiB) Viewed 1297 times

[astroshak]

You sure that is a missing gate and not a missing wall?

As for why it is missing, I have absolutely no idea.

[DRY411S]

You sure that is a missing gate and not a missing wall?

As for why it is missing, I have absolutely no idea.

Yep it's the gate. The rail signal prevented me putting the double wall in which is why there is only 1 at the top of the pic.

[boskid]

They can crash into gates. Gates need to lower to stop colliding and trains (in automatic) only open gates on their path. If a train recalculates path while moving fast it may happen that a new path goes through a closed gate and the gate may not open quickly enough and the train will collide with it.

[Khagan]

They can crash into gates. Gates need to lower to stop colliding and trains only open gates on their path. If a train recalculates path while moving fast it may happen that a new path goes through a closed gate and the gate may not open quickly enough and the train will collide with it.

I'd call that a pathing bug. If the gate can't open in time, then the train should not be going that way.

[boskid]

I'd call that a pathing bug. If the gate can't open in time, then the train should not be going that way.

I would not be so sure about that. Lets think about this:
1/ Train could open all gates in the braking distance on all possible branches. That would be really expensive at runtime and especially expensive when trains would be modded with extremally high speed and dense junctions. Lets say this solution is unreasonable.
2/ Lets think what would happen if a train would have speed so high that it could reach from start to the end in just a 1 tick. Then there is no pathing ever possible that would give the gate enough time to open before the train would cross it. That case is clearly not a pathing bug, its just the execution of the path that causes train to collide because gate did not open in time.
3/ Gate could be force closed be a circuit network in which case the train will hit it anyway.

From all of the observations i would say that the gates feature was an afterthought and it should be considered to be buggy, not the trains. One fix would be to make a gate considered as not colliding as soon it is requested to open. Other would be to rewrite large parts of trains logic so it is aware of gates and could start braking in the middle of a rail block if there is a closed gate on the path but that would create new issues because then a gate would be considered a stopping position and as such if a gate would appear inside of an intersection the train would have to stop before entrance chain signal of that intersection and wait and once it would enter the intersection the gate would have to be considered "reserved" so it would not be possible to be closed by a circuit network. If that would not happen then a train would stop before a closed by circuit network gate while being in the intersection breaking assumptions of a chain signal and on top of that it would keep following chain signals reserved occupying more rail blocks of the intersection while not actively traveling. On top of that if a train would be forced to stop before a chain signal to the intersection when there are multiple possible paths and multiple gates involved, a train could possibly require a repath to choose a different gate than it was trying to go originally since the original gate may be closed while others are opened adding new repath condition. If a gate would be occupied for the purpose of train traveling through an intersection then the trains pathfinder would have to be constrained while in chain signal section to not choose other paths with closed gates that cannot be reserved immediately as the train could become stuck in the intersection. But then the gates have opening time and there is no reason to restrict pathfinder to not choose gates in the intersection that are minutes of travel away as they would be open anyway by the time train would reach them so a trains pathfinder would have to now also keep track of time taken by the train to estimate if a given gate blocking the other paths would be already opened and as such should not be causing restrictions on the trains pathing.

Calling train collisions with gates a pathing bug has a slight taste of saying "go fix that" and given all the reprecussions i am more likely to call it a Wont fix as the other reasonable alternative would be to get rid of the gates (or making them non colliding immediately when they are requested to open).

[DRY411S]

Interesting discussion.

Just to say that I have no mods installed that increase train speed, acceleration or braking. Full braking distance research has been completed. The only train going through the gate would be an empty 1-4 train, presumably slowing down, as it is very near the pickup station. I note that only 1 of the 4 gates was destroyed. It's possible that the others were damaged and repaired, but I did not notice this.

It seems to me that making gates non colliding immediately when they are requested to open would resolve this glitch. Would you like me to submit a bug report?

[boskid]

Just to say that I have no mods installed that increase train speed, acceleration or braking. Full braking distance research has been completed. The only train going through the gate would be an empty 1-4 train, presumably slowing down, as it is very near the pickup station. I note that only 1 of the 4 gates was destroyed. It's possible that the others were damaged and repaired, but I did not notice this.

Could it be that there was an empty train traveling from North to South (or South to North) and in the last moment it decided to turn West where it would collide with a not yet opened gate?

[Khagan]

1/ Train could open all gates in the braking distance on all possible branches. That would be really expensive at runtime and especially expensive when trains would be modded with extremally high speed and dense junctions. Lets say this solution is unreasonable.

Fair enough.

2/ Lets think what would happen if a train would have speed so high that it could reach from start to the end in just a 1 tick. Then there is no pathing ever possible that would give the gate enough time to open before the train would cross it. That case is clearly not a pathing bug, its just the execution of the path that causes train to collide because gate did not open in time.

If all paths contain closed gates that do not have enough time to open, then the train should work in the same way as if the route was temporarily blocked for any other reason (e.g. by other trains). That is, it has to go as far as (the last signal before) a closed gate, and stop and wait for it to open.

3/ Gate could be force closed be a circuit network in which case the train will hit it anyway.

In that case no path through it should be allowed. If trains can drive through circuit-closed gates then all the various 'safe' level crossings that have been designed over the years are broken.

Calling train collisions with gates a pathing bug has a slight taste of saying "go fix that"

My apologies if that was the way it came across. It is clearly a very rare bug, or this conversation would have happened years ago.

[DRY411S]

Could it be that there was an empty train traveling from North to South (or South to North) and in the last moment it decided to turn West where it would collide with a not yet opened gate?

• The gate that was destroyed was the entrance entering the outpost travelling West (trains are RHD).
• It's a stone outpost, with a train limit of 1 hardcoded on the stone load train.
• No trains coming from the North want stone.
• There are no more stone outposts North of this one, so there would be no trains coming from the South that were headed North of this outpost then suddenly repathed to this one.
• The only scenario I can think off where a train heading North or South suddenly turned West into the outpost are plate trains that used the outpost layout as a loop (the plate outposts use dynamic train limits).

Screenshot 2024-03-04 083209.png (51.19 KiB) Viewed 1066 times

Random thought. Could the signal on the same grid position as one of the gates be significant?

Screenshot 2024-03-04 085637.png (144.21 KiB) Viewed 1062 times

(The other stations in the outpost were not in use. They are unused from an old blueprint that I had not tidied up.)

[Trific]

I have observed trains using stop free paths as a loop to avoid having to stop or slow down for a train crossing in front of them, but never a path that has a stop on it.

[DRY411S]

I have observed trains using stop free paths as a loop to avoid having to stop or slow down for a train crossing in front of them, but never a path that has a stop on it.

Interesting. The 'Wall D' stop on that screenshot is disabled by a circuit. Does that make a difference to pathing?

[FuryoftheStars]

I have observed trains using stop free paths as a loop to avoid having to stop or slow down for a train crossing in front of them, but never a path that has a stop on it.

Interesting. The 'Wall D' stop on that screenshot is disabled by a circuit. Does that make a difference to pathing?

This doesn't mention disabled stops, so it may take some experimenting to see if they are treated as not being there at all:
https://wiki.factorio.com/Railway/Train ... _penalties

[Trific]

Interesting. The 'Wall D' stop on that screenshot is disabled by a circuit. Does that make a difference to pathing?

No, as far as I know, any stop imposes a path penalty of 1000. I've never observed a train taking a sidecut through a disabled stop, even though I have tons that would be convenient to do so. The stops where my fuel trains deliver fuel are all disable/enable because it's a very easy test for whether the chest they deliver to is empty or not.

[Illiander42]

How about if closed gates were treated as a wagon on the tracks?

[mrvn]

I'd call that a pathing bug. If the gate can't open in time, then the train should not be going that way.

I would not be so sure about that. Lets think about this:
1/ Train could open all gates in the braking distance on all possible branches. That would be really expensive at runtime and especially expensive when trains would be modded with extremally high speed and dense junctions. Lets say this solution is unreasonable.

That makes no sense. A train isn't going to repath all the time. Reserving only the gates on the path the train is actually reserving is enough. Just like it will only reserve signals along the path it is using.

When the train repaths then it has to reserve new signals and it should at that point reserve gates. If the new path has a gate that can't open in time then that is the same as a red signal along that path and the path finder will have to keep searching. And just like trains (now) keep their original path till they have left a chain signal segment they should also keep their original path till they have cleared a gate. Trains should never stop in the middle of a gate due to repathing.

Note: they could stop in the middle of a gate if you have a normal signal close after the gate and that stops the train.

2/ Lets think what would happen if a train would have speed so high that it could reach from start to the end in just a 1 tick. Then there is no pathing ever possible that would give the gate enough time to open before the train would cross it. That case is clearly not a pathing bug, its just the execution of the path that causes train to collide because gate did not open in time.

Actually no. The train already has a valid path. If every path to the new destination has a gate on it that can't open in time then the train should simply go into no-path state, break after leaving the current chain signal block(s) and eventually halt.

Now you might think that the tricky bit would be that as the train breaks new paths would open up because with less speed the gate can open in time. But that is not happening. The tricky bit should already be in the "can't open in time" calculations.

And yeah, this would make trains more complex. The game would have to calculate if the gate can open time if the train breaks while approaching the gate. Simple enough and not the problem. But assuming the gate can open in time with the train breaking the question then is: How much? How much does the train have to break so that it will arrive at the gate just when it reaches open state? This would make train behavior more complex because this wouldn't simply reuse the breaking point like signals use but would need a second point that is time based.

Thinking about it some more I now wonder: How do gates open anyway? Unless they open when the breaking point crosses the gate, in which case just don't allow any repath where the breaking point crosses a closed gate, there already has to be a "N-ticks before the train" point that the game tracks that triggers opening the gates. And then the same point could be used during repath to only allow paths where that point doesn't cross closed gates.

3/ Gate could be force closed be a circuit network in which case the train will hit it anyway.

That should be simple to avoid. Just like signals can't be turned red to stop a train that has reserved a path a circuit signal should not close a gate that has a train coming through, i.e. the breaking point has crossed the gate and reserved it.

Calling train collisions with gates a pathing bug has a slight taste of saying "go fix that" and given all the reprecussions i am more likely to call it a Wont fix as the other reasonable alternative would be to get rid of the gates (or making them non colliding immediately when they are requested to open).

That is exactly what we are saying.

It should be easy to only allow repath where the breaking point doesn't cross a closed gate. Not trivial but fairly easy. Mark every segment (block?) that has a gate and if that flag is set then on repath check if the gate is closed and before or after the breaking point. Is there such a flag already? I would hope so to optimize opening gates. Surely the game doesn't scan ahead of the train every tick to see if there is a gate to be opened.

[DRY411S]

Could my random thought above be eliminated as the cause. In the more than 7 years I've been playing factorio, I've never seen it happen before,

Random thought. Could the signal on the same grid position as one of the gates be significant?

[boskid]

... Reserving only the gates on the path the train is actually reserving is enough.

Well, lets start with most important observations, there are no "gate reservations" in the game. Train is only "kindly asking" gates to open within the braking distance and if they would be set to open painfully slow, they will get hit. On top of that when a train is moving it is really blind: the only structures it can see are signals on the path and what is the state of them. If a signal leads to an open block (and if its chain, next signal also leads to an open block [recursive]) the train is allowed to enter. Gates are only kindly asked "please open or i will collide with you".

If the new path has a gate that can't open in time then that is the same as a red signal along that path and the path finder will have to keep searching

But that will make trains go into a dead end: train would not be able to find a path through a closed gate, so by not deciding to go through it the gate would never be requested to open. I could optimize trains to gate opening logic by simply removing it, but that would basically mean a gate on a rail would make rail completly useless as it would not be possible to be ever used (except if a player is nearby causing the gate to open, which would immediately cause a rush of trains trying to kill character). If a gate would make rail useless, then the rail can be removed which i could enforce by making gates not buildable over rails. Is this going the right way?

If every path to the new destination has a gate on it that can't open in time then the train should simply go into no-path state

So you really want me to fix this by making gates not buildable over rails so if you want a gate you would have to remove the rail. That is functionally the same, it would cause train into no-path state.

Thinking about it some more I now wonder: How do gates open anyway?

Train searches for the gates up to the braking distance + 2 tiles and if any rails in that distance has a gate on it it is requested to open. It looks like the gate opening speed, max fuel acceleration, max train speed and braking researches are all in a careful balance so that in most cases gate has enough time to open, assuming the train is not repathing. If a train repaths then there are some places where trains are forced to slow down in an unexpectedly faster than usual rate to not go past a red signal but that is a better solution that allowing trains to ocasionally enter an occupied block from the gameplay point of view.

If you decide to change gate's opening_speed to be 1/10th of the vanilla gate opening speed, then i am pretty sure it will be hit by trains all the time even without repathing.

From the cost to gains balance i am not going to touch this. Gains are that trains would not hit gates in some rare cases. Possible costs are: trains pathfinder being absurdly more complex because having to track distances and passage of time for a train requesting path just so it can decide which gates "would open in time", making trains to always look ahead up to "max speed * opening time of slowest gate" distance to make sure all gates have enough time to open. I am just not doing that. Gates feature is far less important for me than core trains logic so until gates would be properly seen by trains movement code allowing trains to slow down and stop before them i am not going to apply any half measures and i am considering current state to be good enough. There will be no changes around this logic in 1.1.x because it would go in the way of expansion development causing a lot of merge conflicts that i am not willing to resolve.

[mmmPI]

If you decide to change gate's opening_speed to be 1/10th of the vanilla gate opening speed, then i am pretty sure it will be hit by trains all the time even without repathing.

I think this happened to me with modded (super) fast trains and gates a little to close to their train stop that got destroyed everytime a train departed.