[0.17.79] Trains should repath at a blue chain-signal

[KriKri]

I built a train-base and some of my trains block the path a train originally chooses. If a train, thats waiting at a blue chain signal, it should try to repath.

The train chose ist path and will never move:

Factorio1.jpg (3.17 MiB) Viewed 4522 times

Green: open path; Red: other train


But there is more than one way for the train:

Factorio2.jpg (3.17 MiB) Viewed 4522 times

Blue: open path


TL;DR: Trains should repath at blue chain signals.

Edit: In this case this part of the factory produces copper wire and the trains to pick up the copper wire were blocking the trains for the copper plate. At that point, there were no path that would take longer than waiting because it blocked "itself". This is surely too much to check for waiting time to longer path time.
This was while I was still building the base and i wanted to test things while going along. I forced too many trains to go get copper wire and that happend. After I finished the base everything runs now smoothly.

[ssilk]

+11
If it is waiting he should try one path randomly after every x seconds.

[urza99814]

+1

There's a penalty applied when trying to path through an occupied station... But if two trains path to the same station at the same time, one occupies the station and the other ends up waiting at the intersection for that same station to be free rather than moving on to the next free station of the same name. So the pathing penalty doesn't seem to do much unless the train it's pathing around is stuck at the station for a long time.

Right now I usually do something like 'train ID * -100k' output on whatever the station is providing so it will disable as soon as a train stops, but that's a bit hack-y (and I'm still not sure if it will always work... Can a train have an ID of 0 for example? I don't think so, but the game doesn't actually tell you what those IDs can be) ... For a good solution you'd need multiple combinators, but I think repathing at blue chain signals would solve the same problem without all that.

[steinio]

Isn't this a whish since stackers exist?

There must be several such suggestions already.

[ssilk]

I there is a reason, why not implemented: It could be, that the alternative path is way much longer. So much, that it would be faster to wait instead.

There needs to be a limit to avoid that. Three ideas:
- The path is not more than X percent longer.
- The train waits since X minutes:seconds, before trying to go around.
- There are special signals, wich allow this kind of repathing.

[quyxkh]

For stackers/stations that get that busy I put a repath-forcing pair in front of the entry chain, that works, it's just "now pick the closest open stop according to the _current_ track conditions". I can see how forcing a repath at _every_ chain brake would be a bad idea, think about a (far-upstream) busy intersection on a big map? Ewww. Odds are very high there's no better exit to your destination no matter what. I'd imagine it's not worth beefing up the repath flexibility this late: there's an easy workaround, so fixing it "properly" has at-best-marginal gains.

[Sad_Brother]

I there is a reason, why not implemented: It could be, that the alternative path is way much longer. So much, that it would be faster to wait instead.

Closed signal should increase travel cost with time.

[Premu]

For stackers/stations that get that busy I put a repath-forcing pair in front of the entry chain, that works, it's just "now pick the closest open stop according to the _current_ track conditions". I can see how forcing a repath at _every_ chain brake would be a bad idea, think about a (far-upstream) busy intersection on a big map? Ewww. Odds are very high there's no better exit to your destination no matter what. I'd imagine it's not worth beefing up the repath flexibility this late: there's an easy workaround, so fixing it "properly" has at-best-marginal gains.

I have the same doubts here - just because somewhere on the path a section is blocked currently it doesn't mean it will be blocked once the train arrives. Forcing it to reroute might lead to trains to drive around far longer than necessary and thus essentially decreasing the throughput of the trainnetwork significantly. The risk of such a change is quite high.

[urza99814]

For stackers/stations that get that busy I put a repath-forcing pair in front of the entry chain, that works, it's just "now pick the closest open stop according to the _current_ track conditions".

Can you explain that "repath-forcing pair"? How exactly do you force a repath? That sounds very useful...

[quyxkh]

For stackers/stations that get that busy I put a repath-forcing pair in front of the entry chain, that works, it's just "now pick the closest open stop according to the _current_ track conditions".

Can you explain that "repath-forcing pair"? How exactly do you force a repath? That sounds very useful...

A train repaths when it has to brake for a red regular signal (or possibly any red signal, I haven't checked), so show it a red signal. Wire a block's entry and exit signals together, and set the exit signal to close if the entry signal isn't red. Choose a block length where arriving trains are going fast enough that their braking distance is longer than the block, the braking point will reach the exit signal before the train itself reaches the entry signal, the train starts braking, repaths, then it reaches the entry signal (with exactly enough speed to have the same braking distance as the rail block length), the entry signal goes red, the exit signal opens, and the train continues. You can get cute with combinators and time the exit signal so the train sees red for only 1-3 ticks, but for stackers and multistop stations where the train's already almost all the way there just making the segment reasonably long imposes only negiligible overall costs, and if congestion is bad enough that an arriving train is going so slow it doesn't have that braking distance, well, that means it recently had to brake for a red signal, so that work's already done, and as a final backstop it'll repath again if it has to wait five seconds at the following chain.

[Optera]

I think this request is as old as signals.
As TTD player I would love for trains to decide which track to use when they reach blue chain signal.

Closed signal should increase travel cost with time.

That's already the case, see "train_waiting_at_signal_tick_multiplier_penalty" in https://wiki.factorio.com/Prototype/UtilityConstants
However for stackers storing trains behind another this is not what we want and should be set to 0 for them to work properly.

[ssilk]

I there is a reason, why not implemented: It could be, that the alternative path is way much longer. So much, that it would be faster to wait instead.

Closed signal should increase travel cost with time.

Ah, good idea, and cheap implementation: When a signal turns to red it stores the current time-index. When a path should be calculated the red signals returns also the time, they are already red. Every now and then the path should be recalulated.

BTW: This does not help for crossings shortly before target stop, because there are always signals, through which the train needs to drive, which cannot avoided.

[Sad_Brother]

I think this request is as old as signals.
As TTD player I would love for trains to decide which track to use when they reach blue chain signal.

Closed signal should increase travel cost with time.

That's already the case, see "train_waiting_at_signal_tick_multiplier_penalty" in https://wiki.factorio.com/Prototype/UtilityConstants
However for stackers storing trains behind another this is not what we want and should be set to 0 for them to work properly.

No doubts you know it better than me. Please explain last statement better.

BTW: This does not help for crossings shortly before target stop, because there are always signals, through which the train needs to drive, which cannot avoided.

I cannot understand this too. Are you about the case, where train is already at the red signal? Are you about the case, when the train not reroute until it is already at the red signal? Then only implicit reroute signal would help.

[quyxkh]

It's perhaps worth pointing out that the wiki does say

• The train is braking for a signal (chain or regular) it cant reserve and the train is not inside a chain signal block. The train is forced to recalculate its path.

which isn't how it appears to behave in the game. I don't know what the actual logic is so I can't really fix it, but trains clearly (and fwliw I think correctly and desirably) don't repath when braking for a chain signal they can't reserve.

[Sad_Brother]

It's perhaps worth pointing out that the wiki does say

• The train is braking for a signal (chain or regular) it cant reserve and the train is not inside a chain signal block. The train is forced to recalculate its path.

which isn't how it appears to behave in the game. I don't know what the actual logic is so I can't really fix it, but trains clearly (and fwliw I think correctly and desirably) don't repath when braking for a chain signal they can't reserve.

I cannot see clearly on the opening picture if the train occupy a chain signal block.
I'm afraid little cross in the between of big crosses has chain signals and it can be the reason of bad behaviour.
Would someone test?

[disentius]

If the train is not repathing, the cost of the alternate path is greater than the cost of the path it wants to take. I believe this might be the case here.

[quyxkh]

If the train is not repathing, the cost of the alternate path is greater than the cost of the path it wants to take. I believe this might be the case here.

Play with the `-gc`-stop entry signalling (teleport to {-90,20}) on this map, it shows the behavior. If you uncheck the forced-repathing close condition, trains will sometimes wait for the since-occupied stop they initially pathed to even though there's an open stop when they start braking -- if they brake for a regular signal, they repath to the open stop, if they brake for the chain signal they don't repath to the open stop until five seconds after they stop at it. Trying to reproduce this on a simpler setup isn't working for me, so I'm not certain what's going on, but I had to add it on that map to get the trains to stop waiting needlessly.

[Optera]

I think this request is as old as signals.
As TTD player I would love for trains to decide which track to use when they reach blue chain signal.

Closed signal should increase travel cost with time.

That's already the case, see "train_waiting_at_signal_tick_multiplier_penalty" in https://wiki.factorio.com/Prototype/UtilityConstants
However for stackers storing trains behind another this is not what we want and should be set to 0 for them to work properly.

No doubts you know it better than me. Please explain last statement better.

I tried explaining it before here and here. Best way is to see for yourself though. Just use stackers like in OTTD or model railways and you will quickly see trains not pathing in empty slots.

[Sad_Brother]

Thanks for answer.
I was barely able to understand this:

Take a stacker for 3 trains.
Track 1 has two trains, 1 in station and 1 in stacker waiting for several minutes
Track 2 has 1 train in station

When 3 trains arrive at the stacker what happens is that Track 2 is filled with 2 trains and the 3rd train insists on going into track 2 as well instead of queuing up at Track 1 because tick penalty from the train waiting in Track 1 stacker is higher than the train_waiting_at_signal_penalty from Track 2.

In this example limiting the tick penalty to 99 would allow the 3rd train to queue up on Track 1.

As far as I understood your stackers are not parallel. In other words the problem is in bad design.
I can be wrong but cannot understand better without picture. Sorry.

...
That means with the trains waiting in the stacker for a long time, at some point their penalty will supersede the penalty of the red signal closed by the circuit network. So you could drastically increase the Signal Reserved By Circuit Network Penalty and/or set the Train Waiting At Signal Tick Multiplier Penalty to zero.

I just had exactly this behavior. When demand dropped trains waiting in the stacker accumulated absurdly large penalties.
The fix for my stackers was to set Train Waiting At Signal Tick Multiplier Penalty to 0.
...

There situation is better explained. But I think the real problem is in bad design again.
To prevent trains to go to specific closed signals both things are needed:
1. Upper limit for train_waiting_at_signal_tick_multiplier_penalty. But high enough so trains would be able to prefer closed signals.
2. Ability to set closed signal penalty from the logical circuit. To designate which signal would be open soon and which would be closed for long.

[nctdev]

There needs to be a limit to avoid that. Three ideas:
- The path is not more than X percent longer.
- The train waits since X minutes:seconds, before trying to go around.
- There are special signals, wich allow this kind of repathing.

4th - button in train GUI
5th - "smart locomotive" item