Can trains ever crash into gates across tracks?

[Qon]

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.

When I use a tank and have robots, everything is a gate

If gates don't want to get hit then it's their responsibility to pay attention and move out of the way fast enough

Would be less fun to deal with gates if they were sturdier than trains and you lose your trains when they collide...

[Khagan]

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.

That's fair enough, but it would be nice to see it fixed at some point in 2.x. I would have thought it could be done with a path penalty for closed gates (small for a gate that is free to open, larger and increasing with time for one that is locked by a circuit condition), and then when a path that includes a gate is chosen (despite the penalty), brake for a closed gate in just the same way as for another train blocking the tracks.

[mmmPI]

When I use a tank and have robots, everything is a gate
If gates don't want to get hit then it's their responsibility to pay attention and move out of the way fast enough

When i use many exoskeletons legs, every wall is a gate. Also every gate on the screen opens when an arrow key is pressed. Therefore gates pay attention to legs. As a conclusion i suggest adding more legs to trains. It would not be less fun.

[mrvn]

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

Obviously, or the problem wouldn't exist. Reserving gates would be a solution.

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?

No, you misunderstood that.

A closed gate is only supposed to be a blocker for path finding if it can't open in time. From what you mentioned above how gates open that means only within the breaking distance does the path finder have to check gates.

Another misunderstanding: When the repathing can't find a path with gates that can be opened the train would break and come to a standstill. At speed 0 every gate has enough time to open so now the path finder can find path and the train would restart. That would be the worst case. More common would be that the repathing would follow the existing path for the breaking distance and only then start to change to the new destination. That is the same behavior as when a train is in a chain signal section that prevents the train picking a path that collides with itself for roundabouts.

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.

Not at all. Except for the exceptional case of repathing right before a gate the gates have plenty of time to open and are not a stopper. And unless the train drives into a dead end before it comes to a standstill the "no-path" state would be purely temporary till the train speed is reduced enough (or zero depending on how often you repath) till gates do have enough time to open.

If the train does try to re-path but can't and then slowly breaks into a part of the train network that has no path to the new destination then that is the same as if the train had re-pathed just a second later. This is nothing new, it can already happen with chain signals. Or it just happens on a clear rail because the train is in a part of the rail network where it would need to turn around and you have no loop where it can turn. Most easily this happens with 2 ended trains and terminal stations. The train would be expected to turn around at a station but if it re-paths in the middle it can't change direction.

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.

I didn't know that trains are force to break harder than they should to keep them out of red signals. I've seen trains just come to a dead stop in some cases. Like when you remove a rail in front of the train.

Does this over-breaking ever happen when repathing due to signal or train stop changes or does it only happen when rails/signals are removed (or signals added)?

As you say gates simply open using the breaking point as trigger and are supposed to be fast enough to open in time then. So the path finder would use the same logic. That's perfectly fine. This is only about repathing suddenly hitting gates. If gates are too slow and normal paths already collide with them then that is a whole different problem. To solve that gates would have to be handled completely different and both path finding and gate opening in general would have to change drastically. Not expecting that to happen.

Also I'm not expecting this to be fixed in 1.1.x at all. But consider fixing it in the expansion please. Checking along the breaking distance for gates when re-pathing or simply always keeping the original path up to the breaking point on re-path (with gates) should be a fairly simple solution.

PS: do trains take damage when they crash into gates or only the gates?

[boskid]

A closed gate is only supposed to be a blocker for path finding if it can't open in time.

That would require introducing a time factor to the trains pathfinder which is not going to happen.

At speed 0 every gate has enough time to open

False. If a gate requires a minute to open and train is directly next to it, the gate will have not enough time to open without making train to wait. That means that trains pathfinder has to find a path first so the train would even consider asking the gate to open but that means gate would have to be aware of gates and would slow down correctly when approaching them.

That is my last post under this topic, i am not seeing any suggestions here that would be significant from the technical point of view, its just bunch of "trains should do that" statements.

[mrvn]

A closed gate is only supposed to be a blocker for path finding if it can't open in time.

That would require introducing a time factor to the trains pathfinder which is not going to happen.

At speed 0 every gate has enough time to open

False. If a gate requires a minute to open and train is directly next to it, the gate will have not enough time to open without making train to wait. That means that trains pathfinder has to find a path first so the train would even consider asking the gate to open but that means gate would have to be aware of gates and would slow down correctly when approaching them.

That is my last post under this topic, i am not seeing any suggestions here that would be significant from the technical point of view, its just bunch of "trains should do that" statements.

As already said the "can open in time" in the game means the breaking point is in front of the gate, not behind it. That's how the gates work and how the initial path is found so it won't crash into gates. Nobody is asking you to change that.

So no introduction of a time factor and no gates that take a minute to open. If somebody wants those then put a signal in front of it that turns green when the gate is open and open the gate yourself when a train approaches.

And at speed 0 we are back at the original situation where the game finds a path for trains at a standstill. That does seem to work out quite nicely, as in trains don't constantly crash into gates. Are you telling me trains crash into gates all the time and I'm just lucky this never happens in my games so far?

I guess there could be some really rare cases where the train will break and come to a standstill 1 pixel in front of a gate. And then it can accelerate into the gate in basically no time so it never opens in time. That should be even rarer than trains re-pathing and turning into a gate at speed so it can't open in time.

gate-crasher.png (161.59 KiB) Viewed 1111 times

It can happen though. Maybe gates should be opened even by standing trains 2 tiles in front of it?

For the re-pathing it's easily fixable by checking for breaking distance + 2 (that was what you said when gates open, right?). I assume that +2 fudge factor is so that gates open in time for trains leaving a station or signal. Because when they start from standstill the breaking distance will be 0 and then they accelerate and probably screw up the timing for gates to open like in the screenshot above.





I'm not sure how much more technical I'm supposed to be than saying that the re-pathing should check for closed gates within breaking distance + 2 (the same fudged thing used to open gates already) along the proposed path and consider those impossible. And use the same "stay on path" logic as with chain signal sections.

Sorry to give you one more "trains should do that" statement: Trains should not behave in an obviously destructive way.