Should LTN use the vanilla train limit?

[mrvn]

I noticed that vanilla train stops now have a train limit that can be set manually or via circuit.

I wonder if LTN could use that, set to the train limit virtual signal. In cases where trains time out I think that would prevent trains piling up before a broken station and grid locking the whole rail network.

PS: I still think sending a new train on timeout is wrong when the old train clearly still exists and is scheduled for the station.

[Blokus]

In some sense you still need the LTN train limit to tell the dispatcher how to behave (otherwise the behavior will have "try catch" structure which you would really rather avoid).

But in any case this is only relevant in the scenario of either a timeout or having non-LTN trains with LTN stops in their schedule. Neither of those actually seem useful; the one relevant change that I'd advocate for is the option to simply disable the timeout entirely.

[mrvn]

In case it wasn't clear: I mean for LTN to set the train limit to the limit signaled by the train-limit signal at the lamp.

[ptx0]

but why?

[mrvn]

To prevent more trains going to the station that the station can handle. For the case of LTN rescheduling trains due to timeout. Or as you mention when adding a manual train to the mix. I sometimes order myself a train, dump all my wood in it and send it to a wood consumer manually. Potentially the station could overflow there.

Currently the choice with timeouts for delivery is:

A) have LTN detect timeouts and send another train and the station overflows
B) don't detect timeouts and not send another train and you will never notice the station is broken

There is no: Warn about timeouts but don't send another train if the trains scheduled to arrive still have that schedule.

It's one of those "better safe than sorry" feature requests.

[ptx0]

you mean the timeout that you can extend to like 10700 ticks? That's the only one that can't be disabled but LTN is really about on-demand deliveries, if you want trains to sit there forever unloading without a timeout, TSM is probably up your alley though these days, LTN isn't really needed much thanks to the train limit.

[mrvn]

No, I mean the one you can set to 0 to disable. But then you don't get told about stuck trains.

[MisterFister]

I sometimes order myself a train, dump all my wood in it and send it to a wood consumer manually. Potentially the station could overflow there.

By sheer accident, my personal gameplay habit on this particular issue seems to be a valid workaround for the error case you're describing. If I want a designated recipient of a certain [FREIGHT], then I build a designated vanilla_trainstop location to send it to -- and a have a small quantity of those.

For one or two instances, I've experimented with having two parallel dropoff locations, one as the vanilla_trainstop and one for LTN deliveries. The reason I've never really had significant success in doing that is for reasons outside of what your scope, in this thread, seems to be. Basically, my dream is to have a city-block complex set aside as a base-wide buffer -- and of course I can specify which [FREIGHT] types are allowed or disallowed at any given buffer location. My problem that always causes me to abandon this is that it really seems that networkID settings on the buffer_dropoff and buffer_pickup locations need to be properly set. Ideally, I'd create one city-block for wood, maybe another city-block for those certain raw-ores that build up in your inventory when I'm decommissioning depleted outposts (or in a hurry to deplete one as quickly as possible because I absolutely HATE building on top of unharvested resource patches) and I can see the benefits both of having dedicated single-item city-blocks or also for multi-freight locations.

The only thing I do now is to create dropoff locations as dead ends, with no LTN-requesting and also no LTN-providing functions. I know neyworkID settings are the way to make this less-silly, but networkID settings are something that I am simply mystified by. (Mental note...) So I never really engage in this. But for the parts that I AM successful at, I know that simply setting aside a certain vanilla_trainstop for manually-ordered deliveries is the best overall insurance against the issue you're describing. (For large scale movements, such as when I'm relocating accidentally-large-buffer requester or provider locations, or when decommissioning large sections of my starter base, I can either disconnect the relevant ltn_trainstops from their constant_combinators, or once I even just temporarily disabled the LTN dispatcher entirely until I was done doing what I'd planned.)

Less-relevant tangent:

My paving-material production locations (concrete, landfill, modded pavements such as AsphaltRoads, etc.) are very amenable to the reverse of this. I build the pickup location as a vanilla_trainstop only, with a permanently stationed train (manually seeding the location with 20-25 nuclear_fuel pellets will last basically an entire game for train fuel purposes.) The train's schedule is very simple:

[PICKUP_LOCATION > until-full]
["LANDFILL #1" > until empty]

And that's it. "LANDFILL #1" (case-sensitive, of course) almost never exists on the map, so the loaded train simply defaults to waiting patiently at the loading platform. When I need a train of landfill, I place a vanilla_trainstop in the wild, manually rename it to LANDFILL #1, and I wait. Typically, I have a #1 location and a #2 location, so for filling in an extremely large lake, I might call both trains at once. Otherwise, I simply have two to choose from, in case I deplete the buffer from one or the other and need to manually alternate.

Perhaps this core idea can be somehow re-tooled to address your needs? Maybe not, but I thought I'd mention it.