Request: Max number of trains for stations

[Molay]

Let me lay out a typical sceneria where it's used: 4 provider stations and 1 requester station.

Each provider station sets maxTrain to 2. There's a bit of rail in front of each provider station for the second train to sit and wait.

Put 8 trains on the network.

Each provider station accepts it's train capacity. 4 will be loaded and ready to go. 4 will be waiting to enter their stations once the train in the station departs.

Achieving just this on same-name stations is extremely convoluted right now. Trivial with max trains.

Now the big difference with the requester station (unloading station):

With maxTrains: possibility to set amount of maxTrains depending on ressources on site. Set maxTrains to storageSpace/trainCargoCapacity. Will dispatch exact amount of trains necessary. Say you need 1 train to fill up storage, exactly 1 train is dispatched.

Without maxTrains: possibility to open station if storageSpace > trainCargoCapacity. Enough space for 1 load worth of trains available. Station opens. 4 trains depart. 1 arrives, unloads, storage fills and station closes. 3 remaining trains are now stranded and will repath back to loading stations.

The goal is addressing this very behavior.

Imagine if you have 2 unloading stations, at different locations (say opposite sides). Both open around the same time. The first one to open gets 4 trains going to it. The second one gets 0. They will arrive at the first station, see it close, and repath. After the first train arrives at the second station, it closes after 1 train unloaded. Remaining 2 trains have no more station to unload and will repath to loading station. But most likely the other 4 trains at the loading station (there's 8 remember) will also have departed by now. You get 8 trains moving on your network, 2 doing an unload and 6 doing nothing, just driving back and forth.

Addressing this in a semi reliable way currently is outside the scope of regular play and probably beyond the capabilities of most of the player base.

Of course there's other setups possible involving stackers, be it input our output stacker, or a "station" that holds surplus trains if the player put too many on the rails. Those are all options for the player to explore and exploit to improve their personal setup.

Fundamentally, maxTrains works with 1-1, 1-N, N-1 just fine. There may be different design consideration for each use. It may be more or less efficient in certain uses compared to using no limit. And possibly less efficient than using different station names with dedicated trains in many cases (trade-off).

The current system works just fine with 1-1 and 1-N, but totally breaks on N-1. It has all together difficulties and challenges when using same-name stations. Those difficulties are much worse currently than they'd be with a maxTrain option.

[Nosferatu]

If you cap the number of trains for "iron load" though it would create a problematic situation since the remaining trains would have nowhere to go. You can't allow him to just "skip" the station that just closed, that would mean the train would arrive empty at the unload. You can't allow him to repath to a train stop with similar name than the closed one, since there is only 1 left , limited to 2 trains incoming and they are on their way already.

Here is where the synergy should appear right ? it doesn't for my brain or explain to me again please.

This train would then no-path i guess ?

Currently in the game if a train is heading to a station AND that station closes down AND he has no where else to re-path to THEN he will skip the station.
I would expect the same behavior when the other station can not be repathed to because it's locked down because of "max number" reached.
It's inconvenient that an empty train returns to the smelters but way better then nopathing and blocking the main rail.

And it's up to the player to set the factory up in a way to avoid bottlenecks like this.

[IronCartographer]

I would expect the same behavior when the other station can not be repathed to because it's locked down because of "max number" reached.

That is not the behavior boskid has been testing. If you do want to prevent trains from getting stuck with "Destinations full" on the main line, you can either provide additional destination capacity, or simultaneously reduce the train limit of a train stop and disable it so that it cannot provide a destination for a train to attempt to path at all (if a station is entirely disabled, it will be skipped, overriding the default behavior of waiting for a limit to be raised).

Edit: There may be some interactions I'm not considering here. It's very hard to reason about this without live examples, unfortunately. In particular, I haven't actually used train stop enable/disable all that much...precisely because of the lack of inbound limiters thus far.

[seltha]

I set a challenge for my latest playthrough which was that I wasn't allowed to have a main bus or anything like that... I had to have individual mini factories connected by trains only (as soon as I unlocked them). So copper smelter factory, copper wire factory, green chip factory, yellow belt factory, red belt factory, etc... just to see what it would be like.

Vanilla trains, I found quite frustrating in this situation, especially with disabled stops... I tried to build a depot/stacker (perhaps I needed to google/watch youtubes on how - though that feels like failure) for trains to sleep until a remote mining outpost wakes back up again. In the end, I just couldn't get it working reliably, even with circuits (though I am a bit of a circuit noob). It was also a huge hassle running red/green wire over vast distances.

What I could get working reliably was the concept of a warehouse... so I now have dedicated trains per mine (and never disable stations), then a centralized warehouse for each raw item that can handle unloading/loading multiple incoming in parallel (plus some waiting bays for 'just in case'). It means I have oodles of trains, and congestion, and things called (eg) "Mine - Iron Ore - 7", "Mine - Iron Ore - 12", etc which is a bit much manual handling for my taste, but at least my trains don't do dumb things anymore.

Soooo.... I dunno... this proposed behavior might (?) help with my sharing-trains-between-mines problem, but the reality is the warehouse thing may still be my preferred way to handle it now that I've adopted that. At first it seemed like a good idea to have the copper smelter send a train off to collect ore from the mines directly, I was finding it would block incoming trains when the mines weren't producing fast enough to have any stations enabled, and the roundtrip (even on rocket fuel) was ridiculous which meant spiky production.

With the warehouse in place, I insulate the factory from resource gathering, the mines drain as fast as they can into the warehouse which then provides a buffer to smooth out the spikes. Probably doesn't help my UPS with the double-handling of materials, but it does help keep the factory ticking along smoothly when I have several million ore in reserve.

[mmmPI]

I set a challenge for my latest playthrough which was that I wasn't allowed to have a main bus or anything like that... I had to have individual mini factories connected by trains only (as soon as I unlocked them). So copper smelter factory, copper wire factory, green chip factory, yellow belt factory, red belt factory, etc... just to see what it would be like.

That sounds similar to what i'm currently playing too atm, making me ask :

1) what kind of network do you use: 2 tracks, each one way ? ( what i have)
2) what kind of trains ? ( Loco Wagon Loco for me, making my station not shaped as a loop but as dead end )
3) what are the general throuput order ?


mine is very small scale, 8 labs only 3 assembly making red science and the others same scale , running since long enough to have researched most technologies before space science.

Using 1 LCL train for green circuit, delivering around 1K/min total split into 3 different areas named the same.

In those conditions i am pretty happy with enabling the serviced area only when the buffer drop under a lower threshold ( by reading quantity on chest connected to station with a wire, say 1K.) , then the train stays until empty or until it receive a green signal, meaning the upper threshold is reached ( by using a decider combinator that send 1 green signal when green circuit>5K to the station, and station sending it to train).

For steel i am smelting iron near the patch, and use 1 LCL train that also services 3 areas with same system.
For iron i do the same i will transform into plate in as many different location as there is iron ore patch ( and for this reason i'm spreading out the miners ), for now i have 2 trains, each of them coming from their dedicated outpost, each train servicing 2 or 3 areas following the same system.
same for copper except one copper outpost has 2 loading bay because it was quite big so it can handle 2 trains.

All those the drop off station is the one that disable, the trains sit at the pick up location, filling up acting as buffer waiting for one of the station named identically to opens to unload a quantity that will trigger a condition for it to go back to loading area.


For oil it's the opposite, i have 1 trains that pick-up oil in 7 different very little outpost all named the same, that enables only when they have 25K since i'm using LCL trains, the train sits at the unload which is the centralized oil refinery place, acting as a tank, that when empty, reaches to the closest filled-enough outpost all named the same.


By distributing smelting i avoid the need of the warehouse, ( also the obvious difference in scaling i didn't used up more than 3 M iron total ).

Also one good side i dont have wire on the map, only from tank or chest to station, locally.

But i will face the same problematic situation with oil trains, if i ever want to use 2 oil trains to pick up from 9 or 10 different little outpost, and still want to unload into 1 single station all shaped as a dead end and all having the same name. Then i would need to cap the number of train going to oil outpost. Else the 2 of them could go to the same outpost, that will close after servicing the first train, leaving the second train facing a dead end ( and waiting on the main network if i don't build a stacker for 2 trains in all my oil outpost ? ).

(i could also call my oupost "oil-1" to "oil-5" , serviced by 1 train unloading in "oil-unload-1" and then "oil-5" to "oil-10" for the other outpost, serviced by 1 train unloading in "oil-unload-2" but it wouldn't be as good as it would force me to math out correctly the consumptions and productions.)

that's cheating clearly.

( i could also change the shape of the oil pick up station to allow the 2nd train to loop after it closes )

but it would be ineficient travel if the situation occur

The max number of trains for stations could be considered in this context. It would get rid of the inefficient travel. I would just parameter my oil outpost to accept only 1 train. And i could either use 2 unloading area, or use a stacker before the unload for trains to have a place to wait if all outpost are depleted, then 1 outpost opens, only 1 trains leaves, not both of them, the other one get unloaded and wait for another outpost to open.

Here comes back the weird situation when the 2 trains are on their way to a different outpost, named the same, one of them closing before the train reaches it for any reason the train has to repath. It would create the new error Destinations full" ? , or it should have a behavior that is unclear to me.

It seems to me that restricting to 1 incoming train is WAY easier to handle than trying to deal with restriction to severals trains for only 1 outpost.

[Molay]

Here comes back the weird situation when the 2 trains are on their way to a different outpost, named the same, one of them closing before the train reaches it for any reason the train has to repath. It would create the new error Destinations full" ? , or it should have a behavior that is unclear to me.

Depends how you close it.

If for some reason you decrease the maxTrains value to 0 while a train is on it's way, it would keep going there. The station is still open, it's just not accepting new trains from choosing it as a destination.

If you close the station itself with a circuit network, the train going there will no longer be able to go there, skip it and go to it's next station in schedule (in this case return to the oil unload). If for some reason you also set maxTrains at the unload to 0 in this time, it can't repath and will nopath instead (I.e. you broke your own train and it is stranded).

[boskid]

limit_trains_gui.png (34.41 KiB) Viewed 6661 times

For now i fixed waypoints logic (now they are considered into train stop limit logic) and added this GUI + signal is taken from CN.

stacker-can-be-anywhere--limit-amount-of-slots.png (1021.81 KiB) Viewed 6661 times

Nice feature of having limits is i can have multiple stackers scattered around map, each stacker's fake train stop can be set to limit amount of trains going into it.

Also testing this in simple N-to-N delivery system. Without limits:

N-to-N-without-limit.gif (976.31 KiB) Viewed 6661 times

And with limits:

N-to-N-with-limit.gif (732.24 KiB) Viewed 6661 times

I am still scared of this feature:
- since i can dynamically change trains limit, i did test of ore pickup where amount of ore in chests is divided by train capacity (this is amount of trains that can be sent and they will be loaded fairly quickly) and capped at 5 (amount of trains that can be held in inline input stacker). Works nice since on ore depletion there are less trains being sent, down to 0 trains when there is no ore. This creates some issues when during loading, amount of trains decreases and one of trains in queue fails to path to same train stop.
- there is still no repath logic when station becomes not full, so in case of back-pressure i am still using disconnected train stop with periodic enable/disable
- performance is not yet considered, i am recomputing all train stop current usages for every repath request.
- (i have to find a place where i managed to introduce desync)
- "No path" error may be misleading and "Destination full" may require some changes to pathfinder logic about finding train stops to tell they are accessible but marked as full - this would prevent path from being returned but would allow to change error being shown.

[Olacken]

This creates some issues when during loading, amount of trains decreases and one of trains in queue fails to path to same train stop.

COuldn't you make it so that the train that is currently loaded is counted toward the max but be the first one removed from the list when the amount of train decrease (And also probably the first to be added if he is not fully loaded to prevent the same probleme if the train stop is replenished during loding but not enough for a new train)

[Molay]

Thanks for the update boskid. The GUI would be quite functional like that already. There's something to be said about having a little slider, but requiring to use the CN and sending a signal may also help conveying the message to new players that this may be an advanced feature. It also nicely preserves current train logic unless people go out of their way to use the new system, preventing confusion among existing players. I think having it only being set by signal is indeed the proper way to go.

Works nice since on ore depletion there are less trains being sent, down to 0 trains when there is no ore. This creates some issues when during loading, amount of trains decreases and one of trains in queue fails to path to same train stop.

Is this a limitation of the current implementation? I'd advise that a train on it's way to a maxTrain-station is not affected by changing the maxTrain value after it departed. I.e. maxTrain property only is considered when choosing a destination. It is not considered for pathing purposes. A station with maxTrain = 0 would still be an open station, and able to receive incoming trains. It would just prevent new trains from departing towards it.

maxTrain = 0 being different from a station being closed/deactivated by CN seems like a critically important feature difference.

Good call on differentiating between no path and train limit reached error messages. I hadn't thought of that!

All in all very promising, I'm excited to see this concept progress, and hopefully, be implemented into the game

Thanks for your work boskid!

[boskid]

COuldn't you make it so that the train that is currently loaded is counted toward the max but be the first one removed from the list when the amount of train decrease (And also probably the first to be added if he is not fully loaded to prevent the same probleme if the train stop is replenished during loding but not enough for a new train)

This is only prototype implementation, it visits all trains to count how many times given train stop is referenced. If train stop is referenced 5 times and limit is decreased to 3, then first 2 trains that will repath for any reason, will not be able to reserve this train stop again and will go somewhere else. There are no lists anywhere. (There is one map<>)

Is this a limitation of the current implementation? I'd advise that a train on it's way to a maxTrain-train is not affected by changing the maxTrain value after it departed. I.e. maxTrain property only is considered when choosing a destination. It is not considered for patching purposes. A station with maxTrain = 0 would still be an open station, and able to receive incoming trains. It would just limit new trains from departing towards it.

This makes train repath logic even more complex. Now train would have to remember it was going to given trains limited train stop, and repath to it no matter what are train stop limits on it now. If this pathfind request would fail, it would be forced to unpin itself and perform another pathfind request. And this idea would collapse in case of train limited stackers, where trains are designed to never reach given fake train stop and so they would be stuck here forever. Now another option would be required on train stop: "perform train stop pinning".

All in all very promising, I'm excited to see this concept progress, and hopefully, be implemented into the game

From my point of view this concept is showing its limitations and has low chance of getting into release. Implementation is possible but code wise, it is shotgun surgery.

[Olacken]

This is only prototype implementation, it visits all trains to count how many times given train stop is referenced. If train stop is referenced 5 times and limit is decreased to 3, then first 2 trains that will repath for any reason, will not be able to reserve this train stop again and will go somewhere else. There are no lists anywhere. (There is one map<>)

Ah ok I thought it was the other way arround, the stop keeping track of all trains that reserved it (the "Trains with this stop:" let me beleive it could be the case but it makes sence that this is calculated when the player ask to open a train stop GUI)

I guess that mean the train stop only knows about the train that is currently stoped at it.

Then assuming any train can know if there is a train at the stop and it's previous pathing what about:

Am I already pathing toward stop A or is there no train stoped at A:

• Yes then is there more than the limit pathing toward stop A:
  • Yes path toward an other station
  • No path toward station A
• No then is there more than the limit - 1 pathing toward stop A:
  • Yes path toward an other station
  • No path toward station A

I also assumed a train stoped at a train stop is pathing toward it but I don't think it's relevant for that specific logic.

You could also have stops keep track of train pathing toward it (it doesn't really change the logic just how you get the information) but I guess it is maybe not possible with current implementation or not wanted from a design perspective (make syncronicity heavier if pathing is in an other thread from other entities or just not what you want of the train network to be).

Edit: Even that would make the syncronicity heavier since you need to access the train stop every time you want to repath

[DerGraue]

I read carefully through all the posts and the more I think about this idea, the more I like it.

But there are some very basic questions that are not yet answered. This is how I would approach it:

- If the train finds a viable station that uses the "maxTrain value" it saves this particular station A, call it train stop pinning
- if the train has to repath it will always path towards this station A, regardless of the current, new maxTrain value and how many trains are right now pathing there. This is mandatory, otherwise this system will not work properly.
- the only case when the pinned station is deleted for the train, is if: the station is deconstructed, the train is set to manual/deconstructed or if the station is closed
- you are not supposed to close the stations for the trains to work this way, you rely on the maxTrain value
- you can still close stations, but then the trains on their way look for a new station and if all stations with the same name are full the train will just stop dead on its tracks


- the search function for a viable station should work like this:
- if a potential target station is found it checks for the current maxTrain value and compares it to the trains currently on the way and if there is a train in the station.
- it does not check if the train is just departed, that is too complicated and unnecessary, it is for the player to make sure that the train can depart
- if the only target stations are all full with maxTrain value, the train will just do nothing and display "destination full", instead of no path, like some have already suggested.
- if there are no stations with the target name on the map or if all the target stations are closed with circuits, then the train will behave like it does now, it will just skip those stations
- if you don't set the value of maxTrain on a station, then it will just behave like the stations right now, the train won't remember the target station and can repath to other stations


There are many things that can fail if you build a system like this, players have to learn how to handle such a new system. But that is no reason not to try to implement this.

Anyways, TL;DR: Trains have to remember the target station, otherwise it won't work.
Thanks for reading and thank you for your time @boskid

[Olacken]

- if the train has to repath it will always path towards this station A, regardless of the current, new maxTrain value and how many trains are right now pathing there. This is mandatory, otherwise this system will not work properly.

I have to disagree on that with you sir

Imagine the following situtaion.

Station A, a very fast working station who work as hard as she can to empty her chest of iron plate as fast as possible but only once an hour because she is deserving a belt factory that don't see much use, just requested her third train of the hour because her hungry boss of an outpost is requesting more iron.
But at the same time not far from there clumsy player, the pocket filled of iron plate because he just ravaged on of his Iron smelter to build an even bigger, even faster and even fancier oupost, decide to relieve himself of all this iron he is carrying and see that not too far there is that good old station A.
Clumsy player jump on this occasion and give all his iron to station A.

Station A with a little bit of math and a lot of coffe realise that she don't need this second iron train and in fact quite the contrary realise that not before too long her hungry boss will stop requesting iron and she would become overfilled by it and wouldn't be able to let him go, so without a second tought(She took the time to redo the math too be sure though) proudly anouce that she only need two train.

Some time passes and as expected the oupost calmed down and is no longer requesting iron those two train are welcomed though hungry boss was especially hungry and Station A is a little bit depleted.

But suddenly a third train arrive Station A surprised ask this misterious train what he is doing here.

The train replied he was her for delivering Iron Plate, although Station A admitted she asked for a train, to come she swiftly withdrew her command so the train shouldn't be her and worst the train insisted that he wouldn't leave until he was fully unload but Station A doesn't have the place to unload the train.

So sadly the train stayed her for the hole hour waiting for the angry boss of Station A to restart production even though he had better things to d, a busy schedule ahead of him.

TL;DR: You need the train to repath if the number goes down or in certain situation(i.e player interraction unloading it's inventory or taking item from other) you will find yourself in a situation where a train will path toward a station and find itself waiting when it could have repathed early.

Edit: This problem could also arise in the solution I proposed so maybe it's up to the player to prevent any unwanted train by for exemple keeping track if the stop is currently loading a train and only update it's number when the train depart and if the train that is currently at the stop is not counted as a train pathing toward it reduce the number of train by one when the train arrive

[DerGraue]

snip

A perfect example of how a player can screw up a station or system, either by bad design or by doing something that was not intended in the first place.

[Olacken]

snip

I can snip too

I souldn't have used clumsy player.

And it s not because I haven't found a good exemple that one doesn't exist you could also not use it not to request only the number of train you need but use it to distribute your train equally to all active stops.If you open a new stop you want train to path toward it.

And I don't see why it is mandatory for a train to keep pathing toward the station even if the number of max train to this staion goes down

[IronCartographer]

I can snip too

Don't take that sort of thing personally--it's meant as a courtesy to others, putting in extra effort to create a direct reference without flooding the forum page with the entire contents of every message over and over.

Anyway, I did suggest the mechanic of an additional checkbox for pinning, or "Route as distinct temporary stop" as I like to imagine it: Temporary stops already exist, and need only be used as shadows for creating distinct destinations out of specific limited-inbound stops.

That said, this is all getting rather hacky and seemingly less than likely to be implemented in its current form. It's neat, but it's certainly not elegant when it meets the inner workings of the train handling system.

[mmmPI]

If for some reason you decrease the maxTrains value to 0 while a train is on it's way, it would keep going there. The station is still open, it's just not accepting new trains from choosing it as a destination.

If you close the station itself with a circuit network, the train going there will no longer be able to go there, skip it and go to it's next station in schedule (in this case return to the oil unload). If for some reason you also set maxTrains at the unload to 0 in this time, it can't repath and will nopath instead (I.e. you broke your own train and it is stranded).

I think it would be easier if there was no difference between the 2 and that in both case the 2nd train would:

(1) try to repath toward any train stop named the same as the one that just became unavailable , provided this other train stop has not reached the incoming train cap yet.
(2) In case there is none, go to next train stop on schedule.
(3) In case there is none, freeze and say "no path" or "All destination full" according to what is the problem.

It could look like this if for some reason the maxTrains value of "DROP" is decreased to 0, (same as if closed) :



the step (1) makes the 2nd train go back to the stacker/Depot, instead of trying to reach the unload. ( it needs to be 1rst reaction )
the step (2) is the actual behavior when a station is closed when a train is pathing towards it. ( if you don't build the stacker/depot the train would arrive empty at the unload)
the step (3) happens when you don't build the depot AND you set the MaxTrain of all unload to 0 or close them. You have 2 different error message.

This wouldn't be the most super smartest setup, there would be potential for inefficient travels, and the network would require chain signals at the entrance of all dead end to avoid train engaging a way, be forced to repath but requiring a station to go backward and break.

- "No path" error may be misleading and "Destination full" may require some changes to pathfinder logic about finding train stops to tell they are accessible but marked as full - this would prevent path from being returned but would allow to change error being shown.

What i propose is to use this new message as little as possible, meaning that when a particular train stop is full , a train that has to repath away shouldn't say "destination full" right away, nor should the train continue toward the train stop whose limit has been decreased) . It should try to find another trainstop with same name first, and in case none are available sneakily skip it and go to the next station on schedule. ( = if you don't build a depot it doesn't break ;trains arrive empty at unload they don't freeze).

Then if you don't build a depot and on top of that you close all the train stop possible that the train have on schedule except some that are already capped in MaxTrain value, then as Molay said it, congrats you broke your train, this time just for clarity you got a special message, quite rare that you can only get for one reason: you messed up MaxTrain value.

I hope it could make it more resilient to user mistake, while also not giving too much constraint.

The consequences for failing at setting up correct MaxTrain value, would be the same consequences for failing at enabling/disabling station. Trains unable to repath in dead end because a station close / limit is reduced. (right ?)

- there is still no repath logic when station becomes not full, so in case of back-pressure i am still using disconnected train stop with periodic enable/disable

What if a station that receive a max MaxTrain value = 0 is considered as if it just closed so all the trains with same destination in the stacker would naturally repath instead of the periodic thing? ( a form of soft disable ).

and/or if there was a repath when (MaxTrainValue - IncomingTrain) becomes positive in a train stop ?, ( this would require the number of IncomingTrain not to be hidden). then all non-moving trains pathing towards a train stop with same name repath. If it becomes negative this time all moving trains pathing towards a train stop with same name repath.

That could make a simpler explanation such as : You can set the MaxTrain Value, You can read the IncomingTrain, when they are equal the station act as if was closed , you can also close the station with enable/disable method.

Is that too many repathing that no trains will ever reach any station ?

what i don't understand would be: 5 trains are going to 1 particular "iron ore load" train stop, the MaxTrain value is also 5, eveything good, now the value increase to 6, because there is even more iron in the outpost, so a "repath" occurs right ? should it ?, as if a new train stop called "iron ore load" had just enable. Those 5 particular train that were going toward the first "iron ore load" may repath, and realise that the depot/stacker is closer than the far away outpost ( which is unwanted ), but they should repath toward a closer " iron ore load" ( how to tell the difference with the stacker ? ).

I fear the erratic behaviors that can occur if too many repathing.

But the video with the actual limit thing is something that is intuitive i feel, for many players it would be the way they would want their train to behave, there are many questions asked on the forum on how to obtain this, wether mods or circuits because that's an easy-to-picture logic i think. Then you realise how many little details are required to automate it but you start with the general idea already. ATM this particular general idea that feels quite common also feels not appropriate with factorio rail system so i don't use it really i do with other method, but trying out the new possibilities that comes from this feature is something i would totally do if possible

[Olacken]

Oh I didn't I was just in play mood and probably wanted to look funny (mostly for myself) that's why I includded a smiley after, maybe it was innapropriate (probably).

Anyway I don't really understand on what "route as distinct temporary stop" would resolve the issues op as with the current system.

Yes it is indeed looking very hacky and as Boskid said "it is shotgun surgery"

You need to store information of train pathing toward a stop somewhere(like a dictionary that have a stop id as key and a list/table of id the ids of the trains pathing toward it) or complexity will just be O(n) = n²

And even then there is the issue of train pathing toward a stop when a train is being unloaded and then the counter just decrementing and the train needing to repath.
And while solving that kind of issues with the algorithm I suggested (or a variant) could solve this very issue it could add some unwanted side effect. It could be avoided by circuit design however but add the task to the player for even any simple use case of the feature (if they notice it it's not necessarly something that is easy to spot unless you are play testing).

To conclude unless there is a simple side-effect-proof solution to that problem as much as I want it I don't think it should be implemented. That also applies to any unknown(by me) probleme that could arise.

And of course that is also assuming the solution I propose are even feasible in the game engine.

[Freddie Chopin]

COuldn't you make it so that the train that is currently loaded is counted toward the max but be the first one removed from the list when the amount of train decrease (And also probably the first to be added if he is not fully loaded to prevent the same probleme if the train stop is replenished during loding but not enough for a new train)

An interesting observation. This idea above, the basic idea of this thread and the prototype implementation by boskid - these are all almost identical to how "Train Supply Manager (TSM)" mod works ( https://mods.factorio.com/mod/train-pubsub ). It has a "train counter" which counts the trains currently en-route to that station _AND_ the train that is currently at the station. You can set the number of allowed trains explicitly (like "always no more than 3") or dynamically (like "as many to pick up everything that is currently in the chests"). I believe that if the train stop requests 3 trains, these 3 trains start going, and then the train stop decides that 1 train is actually enough, then the other 2 trains would still arrive at that station. I don't think this has to be fixed/changed for some rare corner cases that a player came and dropped/picked some cargo manually. I also think that once a train chooses a TSM-enabled stop as its destination, it will never repath somewhere else, as this would make no sense at all (maybe excluding extreme cases like - train stop being disabled, rails/stop being deconstructed, ...). This is because all "requester train stops" have to have unique names.

Generally it would be cool if thing like this would be in vanilla game, however everyone willing to use this right now, and _NOT_ wanting to use LTN, can try TSM mod. With recent additions it can handle any possible scenario mentioned above, including "N to M", where it manages dispatch of both empty and full trains.

[wobbycarly]

As someone who's tried to replicate the logic of LTN without installing the mod (how the F does one prevent the "race condition"?! ) I would love to see something like "max trains" or even an equivalent of LTN in the core game. I feel like LTN oversimplifies the problem of managing trains (I've watched quite a few Let's Play with LTN) so something between vanilla and LTN would very much appeal.