Train Station reservation option by interrupts

[LoneWolf_LWP]

TL;DR

Allow in an interrupt to reserve all the stations for this train that are found/going to be visited, so that the next train with the same interrupt would not be dispatched if its not needed.
(by checkbox : to control this behaviour only when you want/need it)


What ?

11-01-2024, 18-18-04.png (64.17 KiB) Viewed 364 times

The stations that are found by the interupt would all get an incoming train on the 'C'/ and removed from the train limit parameter in the station if the option is checked. aka : reserved for that train.
Even if the train is going to the first station in the list the second one would also know/see that it is coming.


Why ?

Trying to do this by signals created at the stations (that also controlled the opening and closing of the station) is not working as the train interrupts and combinators are updated seperated from each other.

This results that all trains get set with the same signal.

But that signal was meant for one train to dispatch and change the current signal due to that the station is now seeing a train coming on the 'C' parameter that is used a confirmation we dispached a train and did not need anymore so remove the signal so no other trains are able to use it.

But the signal was not updated in time by the combinators due to the update order.

Resulting in a stampede of trains getting dispatched to do just one job for one train, and that was not the expected behaviour.


I'm confident that we can do it by complex combinator designs but then we are back to doing it like in 1.0 or just revert back to LTN or something (to be clear iI have nothing against those mod's).

But my impression was that we would be able to do it by interrupts more easely so the huge amount of combinaters (several at every station) could be reduced/eliminated improving ups in large save's/overhaul mod's.

By adding this and the option we already have for interrupts to interrupt other interrupts, enough fail safe could be build in by the player to avoid deadlocks (for example : if the route gets blocked go to a depot and wait until you can continue with the original interrupt).

The option would also be completly optional by check box for the players that don't want this behaviour to happen.

[ichaleynbin]

I've seen a lot of people with similar issues, enough that I'm sure this particular problem will be in the Discord FAQ at some point. That interrupt condition set is a very natural one and makes a lot of sense. There are plenty of solutions to the stampede problem, and plenty of other ways to avoid it, but it would be so nice if those conditions behaved nicely. I like the idea, as far as finding a way to integrate this into the game naturally with systems already in place, but it is also an interesting optimization problem in its own right, and I think we have the tools.

I like the suggestion but I could see reasons to keep things as they are

[danbopes]

I ran into this issue as well today. When the train limit on the requestor station opened up to 1, 14 trains were dispatched, all trying to deliver to that same station. It’s frustrating, as this seems like it could be addressed relatively simply.

Proposed Solution: A mechanism to check the station's reservation status across incoming trains could prevent multiple trains from queueing up unnecessarily. Something along the lines of:

Code: Select all

int incomingTrains = count_if(trains.begin(), trains.end(), 
    [&](Train& train) { 
        return std::any_of(train.schedule.begin(), train.schedule.end(), [&](const Stop& stop) {
            return stop.is_interrupt && stop.station == destination;
        });
    });

if (incomingTrains < destination.limit) {
    // Allow new train to be dispatched
}

This conceptually reserves the destination stations ahead of time for incoming trains, ensuring only the needed train is dispatched. However, the current Lua API and interrupt system make it challenging to implement this directly in mods, as we can’t easily intercept or manage train reservations at a low level.

Adding an option like this to the game would improve efficiency for players who rely heavily on train networks, particularly in larger games. It would also help reduce the need for complex combinator setups at each station just to handle simple dispatch scenarios.

[nyghtwulf]

I've run into this same issue in a different setup and would appreciate having this option. Which, is also similar to this: viewtopic.php?f=6&t=119346

There are probably ways to solve this with circuits and combinators, but that seems a bit janky when we just got all these new train interrupt functions and tools. I'd like to be able to control trains with train controls, not have to build a micro processor with combinator logic to manage dispatches and then deal with a host of other issues and bugs and probable edge cases.

It feels like a simple option as pointed out in the other thread, just give us an option to make interrupts respect already active temprorary stations as reservations on a station if said station is in a schedule, and even if the train is not enroute to that station.

Just adding to the thought for clarity, here's what I was working on..

train_schedule.png (77.13 KiB) Viewed 53 times

I have load and unload stations that have combinators that enable/disable the station if the station has enough material for a train load or has enough capacity to accept a load of material.
If I have multiple trains with this schedule, multiple load stations that provide the material and ready/open for pickup, and a single dropoff station enables as it can accept a load, then multiple trains will dispatch to each of the provider stations. And then all will get trapped/stuck as they try and deliver to the single requester station.

There is the 'Destination full or no path' condition which can be used to catch this and send trains back to a depot so that they dont clog the provider stations. But that doesnt solve the mass dispatch issue. This can be half solved with Enough Trains and a second interrupt to check train-self for a load that matches a given request. But that just seems like a lazy janky solution that would mean having to have extra trains than really needed as you'll have to account for each material's thundering heard.

A lot of tl;dr: Allow and/or have the option to make interrupts respect station train limits. Don't add new interrupts that contain a station that already is at its limit with trains that have that station in their temporary schedule and such trains are not yet heading to said at-limit station.

[bluegreen1024]

I was able to solve this by enabling only one train at a time among all trains waiting at "Depot" stations, using a combinator clock that sends signals to each station to trigger each train's wait condition one by one. But I agree that this is janky and some sort of automatic reservation system would be useful.