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 1163 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 852 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.

[lelick]

Upvoting this

[Rayffer]

I've ran into this issue and it's sad that I have to go through these hops, via a clock to be able to enable this behavior, feels hacky and non intentional to me, as the train's schedule actually includes the station.

[AileTheAlien]

I'm still trying to work around this problem. Because I only dispatch one train at a time from my depot, and requester stations and provider stations fill and drain slowly, they usually only get enough room for one train. (All my stations are named the same way, like "[iron plate icon] provider" or "[steel plate icon] requester".) But I still occasionally end up with two trains that have been dispatched to fetch, for example, iron plates, and then the requester station only has room for one train. The second train ends up waiting at the iron-plate station, with nowhere to go. My trains will always empty their cargo before going back to the depot, so they won't contaminate stations with incorrect materials, but this still means that I need extra trains.

As far as I can see, this isn't solvable. You could store lists of train IDs in combinators, when they get dispatched to fulfil a request for a specific resource. However, because you don't know what specific requester station a train is going to service, you can't update the train-limit of any specific station. This makes it more possible to have too many trains dispatched. I think in my case, my provider station is filling up quicker than requester stations, so more than one train can be dispatched to get iron plates, even though the requester station only has room for one train. But it's like, 2am, and I'm sick of trying to make trains work sensibly. I already solved the problem of trying to dispatch trains with interrupts, but keeping item-icons in their names, but now I've stumbled into the problem of too many trains being dispatched...which apparently other people found a month before me. (Aka, this whole thread. )

I was able to solve this by enabling only one train at a time among all trains waiting at "Depot" stations

Do you have a set of blueprints for requester stations, provider stations, and depots you could share? I'm already only dispatching one train at a time, but I don't have a solution to too many trains being dispatched for a resource. (That is, more than the requester station can unload.) Dispatching only one train at a time is easy, since I have a single depot station, and just make the other trains wait with signals:

depot that only sends one train at a time

depot.png (1.24 MiB) Viewed 500 times

[feng]

I just opened forum now because I wanted to make a suggestion thread about the exact same thing. Giving us a checkbox on train station targets to get reserved when being part of a schedule and a train is en route. Something like "Reserve Station Slot before approach" checkbox on every target station.

Right now interrupt conditions like "only true if Pickup is free AND Dropoff is free" only work when you only got 1 Pickup station (train limit = 1) lol
If you got multiple Pickup stations for 1 item, as many trains will depart as you have opened pickup stations... even if you only have 1 Requester station open as the requester station limit gets not used until the trains depart from Pickup Station after loading and travel to Requester Station.

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.

I think you are talking about some different issue as the problem we talk about is not solvable just with a "depart clock" at the depot as this would just result in getting all the trains departed one after the other but still overfilling the Requester Station.

I built a solution on my own without using the train limits. Basically a "client-server" setup, with the server circuit at the depot getting signals from Pickup and Requester Stations and saved in separate memory cells. They generate then a "delivery order" which gets send to the trains at the depot (with a tick cycler and Depot Station IDs). After a train departs from depot, the availability in Pickup Memory cell and Requester Memory cell gets subtracted by 1. Its working but eeeeeeh, needs many combinators for avoiding hiccups and its absolutely fragile to power outages.... Hello @ Fulgora

[Calid]

+1

[nyghtwulf]

I'm still trying to work around this problem. Because I only dispatch one train at a time from my depot, and requester stations and provider stations fill and drain slowly, they usually only get enough room for one train. (All my stations are named the same way, like "[iron plate icon] provider" or "[steel plate icon] requester".) But I still occasionally end up with two trains that have been dispatched to fetch, for example, iron plates, and then the requester station only has room for one train. The second train ends up waiting at the iron-plate station, with nowhere to go. My trains will always empty their cargo before going back to the depot, so they won't contaminate stations with incorrect materials, but this still means that I need extra trains.

The workaround I am using is two parts. I make use of the 'if destination is full' interrupt to catch when a train is trying to deliver to an already being fulfilled station. This interrupt is set to interrupt all others and send the train back to the depot. This does not solve multiple trains being dispatched to multiple same-item providers for a single station requesting. To fix that, I have 2 separate delivery schedules; 1 is to deliver to the requester if the train has a full load. This interrupt is BEFORE the 'go to the provider to get a load and then deliver' interrupt.

While this works, it means I have to compensate with additional trains to deal with trains being parked in the depot with materials.

The interrupt system really feels like they wanted players to run trains in a very specific manner. All provider stations are named the same (aka 'Load'), regardless of item type. All trains are set to go to Load as their default. Then interrupts are used to detect what item was just picked up and what explicitly named station they should be taken to. If no 'Load' stations are available, you can use the 'destination is not valid or full' interrupt to send the trains to a waiting depot.

It feels somewhat confining when with just a few additional options players could do a lot more things with trains.

[feng]

The interrupt system really feels like they wanted players to run trains in a very specific manner.

Exactly, they even wrote it in one of their FFFs that you need a depot for catching the overloaded trains...

So we just added a special interrupt condition called "Destination full", which allows us to make an interrupt to send a train to a depot if all the item inputs are occupied, so it doesn't block the current station.

Some people noticed a row of depot stations in some of our screenshots, this is what they were for.

I'm surprised though that Wube was happy with this solution... as it is more a workaround than a solution. A solution would be if only as many trains as needed would be on tracks.

It feels somewhat confining when with just a few additional options players could do a lot more things with trains.

I hope that they will add more features with 2.1. They already confirmed some new circuit features and also in one FFFs about train stations they said something like "station names can't be set dynamically YET". So... fingers crossed.