Feature Request : Configureable LTN Stop Signal Priority

[brokenshakles]

Heyo! I love LTN, but certain behaviors of the LTN stop annoy me, most notably the facts that A: Yellow Signal overrides Blue signal when a train is at a provider/requester, and B: blue signal is terminated before a train leaves a provider/requester if the trains LTN schedule order has been completed, but it is being overfilled via the inserter resolution delay that LTN provides (wonderful feature, by the way). Would it be possible to make station signal priority configurable across a network ID? Or just across then entire mod? A global setting would be better than nothing. I would also appreciate an option to enforce blue signal even if current station order is complete.

[Optera]

There is no override.
Yellow: Train is on the way
Blue: Train is parked at stop

[mrvn]

Note that a train can be at a stop but not parked. This happens when the train wants to leave but there is a signal right after the stop that prevents it from leaving. E.g. because another train blocks the exit. Cargo wagons will be closed then indicating a train on the way even if it's standing still right at the stop.

Afaik that's the only way to get a yellow light with a train at the stop.

[eduran]

Why would you want to change the LTN lamp behavior?

Afaik that's the only way to get a yellow light with a train at the stop.

You also get a yellow light if a train is stopped but not controlled by LTN.

[brokenshakles]

There is no override.
Yellow: Train is on the way
Blue: Train is parked at stop

If I have a blue signal and a new train queue's up for that stop, the signal output changes from blue to yellow when there is a train parked at the stop. The exit from the requester/provider in question is always clear, there are only two trains on my network right now. Furthermore, the stop doesnt seem to enforce the train pop limit for that station when set. There are no trains on my network that are not controlled by LTN.

[Optera]

I can't reproduce that behavior.
New deliveries to a stop with parked trains under LTN control increase the blue signal count.

[brokenshakles]

Are you using a stop that is both a requester and provider? Edit: It looks like station timeout knocks blue signal out as well. Edit 2: That may be my entire problem, so in increased timeout to an hour and see if that fixes.

Edit 3: Yep that did it. So instead of my orignal request, which seems to be already implemented, how about an option where station residence doesn't increase the delivery timeout? With the new 0.17 balance, unloading a train with 6 yellow inserters with the first inserter stack upgrade tech (2 items per insert) loading and unloading a basic train car can easily take in excess of the default timeout of 5 min. In lieu of that, how about increasing the default to 15 min?

[mrvn]

Are you using a stop that is both a requester and provider? Edit: It looks like station timeout knocks blue signal out as well. Edit 2: That may be my entire problem, so in increased timeout to an hour and see if that fixes.

Edit 3: Yep that did it. So instead of my orignal request, which seems to be already implemented, how about an option where station residence doesn't increase the delivery timeout? With the new 0.17 balance, unloading a train with 6 yellow inserters with the first inserter stack upgrade tech (2 items per insert) loading and unloading a basic train car can easily take in excess of the default timeout of 5 min. In lieu of that, how about increasing the default to 15 min?

When the timeout triggers the delivers is removed from the list. So the train would no longer be LTN controlled. And then as eduran said the blue goes away.


In all my games the first thing I do is raise the default provider/requester limits and the timeouts. When I play with LTN I try to get it early. And then loading/unloading always hits the default timeout. LTN should realy rather check if the train is still on schedule and made progress. So when it is parked at a station check if the item/fluid count made progress in the last 5 minutes rather than an absolute time to finish the delivery. A warning that a delivery seems to take too long before actually forgetting it and sending a second train into a deadlock situation would be nice.

[brokenshakles]

When the timeout triggers the delivers is removed from the list. So the train would no longer be LTN controlled. And then as eduran said the blue goes away.


In all my games the first thing I do is raise the default provider/requester limits and the timeouts. When I play with LTN I try to get it early. And then loading/unloading always hits the default timeout. LTN should realy rather check if the train is still on schedule and made progress. So when it is parked at a station check if the item/fluid count made progress in the last 5 minutes rather than an absolute time to finish the delivery. A warning that a delivery seems to take too long before actually forgetting it and sending a second train into a deadlock situation would be nice.

This was very much along the lines on what I was thinking, really, there should be 2 timeouts, one for station residence, and one for rail network (non-station) residence. Whenever a train switches from one of these modes to the other, the relevant timer should be reset. So if I have a trip from the depot with a requester and provider the process should go Leave Depot -> Rail Network Timer Reset -> Enter Provider -> Station Residence Timer Reset -> Leave Provider -> Rail Network Timer Reset -> Enter Requester -> Station Residence Timer Reset -> Leave Requester -> Rail Network Timer Reset -> Enter Depot -> Station Residence Timer Reset (of course depot residence does not tick this timer, but we reset here to keep the pattern clean.) Furthermore, if the Station Residence timer times out, we should recieve a report that describes both the train and station, in the case of a Rail Network Timer timeout, we should get the train and X and Y Co-ords.

Edit: Optera, would you mind editing the topic title to reflect the change in discussion?

[Optera]

Way too much overhead for no gain.
LTN already has 2 timeouts, Stop and Delivery. Stop can be set to 0 to turn it off entirely if you don't like it or be entirely replaced by circuit control. With that you can create your own stop timeouts on a per station or even per train basis.

[mrvn]

Way too much overhead for no gain.
LTN already has 2 timeouts, Stop and Delivery. Stop can be set to 0 to turn it off entirely if you don't like it or be entirely replaced by circuit control. With that you can create your own stop timeouts on a per station or even per train basis.

The stop timeout is fine-ish. Too low for the inserter speed when you first get LTN stops. The real problem is the delivery timeout.

1) A train that is on schedule and being loaded or unloaded should not run into the delivery timeout.
2) Sending a second train on the same delivery as the one that is stuck makes the problem worse. A second delivery only makes sense when a train has disappeared or had it's schedule tampered with.

Every time this has happened I've ended up with stations getting too many trains, overflowing the buffer storage and items ending back at the depot. Which for liquids is a real pain as they can't be automated. I think I never run into the case of a train being deconstructed or destroyed. I simply don't do that to LTN trains.

Switching/resetting timeouts at every turn does seem like overkill for little gain. But adding a bit of logic about when a train is actually lost and when it is just slow would be a huge benefit.

[Optera]

Switching/resetting timeouts at every turn does seem like overkill for little gain. But adding a bit of logic about when a train is actually lost and when it is just slow would be a huge benefit.

Because constantly polling train speed and comparing to max_speed to detect traffic jams vs long travel times has no overhead.

[mrvn]

Switching/resetting timeouts at every turn does seem like overkill for little gain. But adding a bit of logic about when a train is actually lost and when it is just slow would be a huge benefit.

Because constantly polling train speed and comparing to max_speed to detect traffic jams vs long travel times has no overhead.

Doing it once (or once per) the delivery timeout hits has no noticeable impact.

I'm talking about the following check:

When the delivery timeout hits:
- check if train still exists
+ if gone remove delivery so a new one can happen (message: delivery lost due to train loss)
- check the train schedule is as it should be
+ if not as it should be remove delivery (message: delivery lost due to schedule tampering)
- all seems to be OK, must be a stuck train
+ reset timeout and output warning (message: delivery might be stuck)

That's one check every few minutes and only when a delivery runs into the timeout. The important part here is to not send another train when the old one is still on schedule.

PS: Does a destroyed or deconstructed train even run into the timeout? I remember some code that checks deliveries and removed dead ones already.

[Optera]

Loosing track of a train already is a hard fail state.

The check you refer to was removed for a reason before your pull re-enabled it.

[mrvn]

So do I get it right then: The only way to ever run into the timeout is when a train is stuck? May be No Path, out of fuel, deadlocks in the signals or slow inserters.

[Optera]

So do I get it right then: The only way to ever run into the timeout is when a train is stuck? May be No Path, out of fuel, deadlocks in the signals or slow inserters.

Or when the timeout is set lower than round trip time.
I'm not going to automate this. Eyeball how long round trip time is on your base and set the timeout to 150% or 200% of it.

[mrvn]

So do I get it right then: The only way to ever run into the timeout is when a train is stuck? May be No Path, out of fuel, deadlocks in the signals or slow inserters.

Or when the timeout is set lower than round trip time.
I'm not going to automate this. Eyeball how long round trip time is on your base and set the timeout to 150% or 200% of it.

I might. Next time I run into a traffic jam I'm going to play with that.