Factorio Forums

Hey,

We've broached a topic of max number of trains. Boskid, I'd like to hear about the complications with the system if you find the time.

For reference, my most recent post in the FFF about it (admittedly not the correct place to discuss it;) )

I think you're overthinking it.

Each station would get a new field #maxNumberOfTrains and #TrainsCurrentlyIncoming

The player sets maxNumberOfTrains it to some amount. Say 1. TrainsCurrentlyIncoming is a hidden field used by the game to track how many trains are incoming to this station.

If there are for some reason 20 trains waiting to depart, the first train (procedural processing, there's always a first train) to make this station his destination. This will increase the TrainsCurrentlyIncoming field by 1. Now maxNumberOfTrains is equal to TrainsCurrentlyIncoming, so the other trains won't even attempt to leave.

If the train has departed the station, or changed it's destination for any reason, TrainsCurrentlyIncoming gets decremented by 1. Now any of those 19 trains (first to check) will claim that spot and depart.

There should be no reason why a train would be stranded in the wild (at least no new reason, outside currently existing reasons). They only depart as needed. You can set a higher amount of allowed trains if you want to create a buffer area for them.

As to your idea of "only X of those 100 trains are allowed to go to that station", well, I don't exactly know what you mean. If the station has a certain name, and the train has that station name in it's schedule, it should be a viable destination. If it's not, your schedule is wrong and should be changed. If you want to do some crazy magic, you can of course still recreate everything with dozens or hundreds of combinators, arcane mathemagics and blocking of rail signals and disabling of stations.

For most uses, a maximum amount of trains will be doing exactly what LTN is doing now. Have a number of stations with the same name requesting the same input. A number of stations with the same name offering the same output. The only thing this would not do is make trains "universals". You'd always need to have X trains dedicated to, say, the iron plate delivery. But that's certainly not a bad thing all things considered.

It feels like an incredibly easy feature for the player to handle. You just click on a station, and in the GUI you have a slider (with textbox perhaps for typing number?) to enter the number of trains that are allowed to come here at any one time.

It would be incredibly powerful, and to me be the last missing QOL change to make vanilla an equal experience to modded. As of now, trains are quite unwieldy as you expand, and using the same station name has unnecessary complications and limitions. Currently you can end up with stranded trains if you do it poorly. A maximum limit of trains per station would be foolproof and not require any complicated setup.

Edit: Also, maxNumberOfTrains should be able to be set via signal. Instead of closing/opening stations, just adjust the number of trains allowed. 0 would default to a closed station.

Think of it as now we have 2 states: Closed station and open station. Closed takes nothing. Open takes everything.
With the change we'd have 3 states: 0 for closed stations, 1-x for maximum number of trains allowed, infinite (no limit/current behavior/takes everything).

Edit: To clarify, this change would not change train pathing behavior or anything like that. It would merely alter the destination decision process, by prohibiting going to a station that already has the maximum number of trains inbound. It's just a change in this process.

Feel free to join the discussion as to why it would be a good or bad idea. Boskid seems to have gone over it and identified serious issues with it already.

I would love to see @boskid's cases where this actually causes problems.

boskid wrote: Sun Jan 26, 2020 7:31 pm

Molay wrote: Sun Jan 26, 2020 10:06 am +1 for adding a "max trains at this station: X" field. Would make life so much easier.

I am not going to discuss this topic under FFF since it has nothing to do with FFF-331. Today i did some evaluation of this concept and it looks pretty much garbage, a lot of input and output stackers were required to make standard N to 1 (ore to smelters) work decently. If you are brave enough to face with problems of this concept, create new topic and i will throw at you some cases that are ugly to solve and makes this mechanic useless.

Please, throw away so I can find some sort of reason to not want this.

The problem seems pretty straight forward. If the train station maxes out and hard caps, then the pathing for any other trains will break. Broken pathing causes trains to stop. Stopped trains ruin everyone's day.

When does a station decide that it's full? Is it when the trains choose the station as their destination? Is it when the first trains line up in the stacker and call dibs? How does one define a "stacker"? What if a train lines up, and suddenly decides to path next door? Finally, who really cares about max train limits? It's not really a thing that comes up in normal play.

I think you'd be able to solve more problems and have a greater success rate by implementing your "max station" with circuit logic. Read the stacker, and when it's full, force the trains elsewhere. I suspect that most of the tools already exist in game to make it happen. If the circuit network is missing one particular ability, then it'd be easier to ask for the missing piece to complete the design.

bobucles wrote: Mon Jan 27, 2020 12:10 pm The problem seems pretty straight forward. If the train station maxes out and hard caps, then the pathing for any other trains will break. Broken pathing causes trains to stop. Stopped trains ruin everyone's day.

When does a station decide that it's full? Is it when the trains choose the station as their destination? Is it when the first trains line up in the stacker and call dibs? How does one define a "stacker"? What if a train lines up, and suddenly decides to path next door? Finally, who really cares about max train limits? It's not really a thing that comes up in normal play.

I think you'd be able to solve more problems and have a greater success rate by implementing your "max station" with circuit logic. Read the stacker, and when it's full, force the trains elsewhere. I suspect that most of the tools already exist in game to make it happen. If the circuit network is missing one particular ability, then it'd be easier to ask for the missing piece to complete the design.

In my opinion the author was quite accurate.
"Broken pathing" is absolutely possible with already implemented disabled stations. Author's suggestion will help to solve it.
Incoming trains counter is updated when train chooses station. Author was very clear in that. No magic "stacker". Logic is very simple and straightforward. Literally, author described algorithm.
This feature will not solve all difficulties, but will significantly improve trains management in vanilla.
I also was skeptical when I read the heading, but after reading the description, I admit it is a good idea.

To put at ease any fears of dropped functionality, let me rephrase and expand on how stations accept trains; essentially handling another state in my proposal by circuit logic: the current disabled station state.

First the basic 2 states as by max train number:
Where M is maxTrainsPerStation (M being a value from 1 to infinite) and C is currentTrainsScheduledAtStation (forgot what I called the mock variables earlier but that will do)
1) M > C : new trains can calculate path towards station and depart, incrementing C by 1.
2) M <= C : new trains can not path toward this station and keep looking for other stations of the same name periodically

A train en route to a station as per 1) will not suddenly stop if M becomes <= C, but continue on. There is no reason for it to keep doing the destination selection if it's en route!
State 2) is a soft close preventing new trains from departing only.

The last state would be the current disabled station via circuit network:
3) train station closed via circuit signal. Current behavior is maintained.

This will preserve current functionality while expanding on it with the simple to use MaxTrainsPerStation field a player can set with a slider/textbox.

So essentially 3 states:
1) open (M > C) new trains can select station as valid destination and path towards it(increments C by 1)
2) soft lock (M <= C) no new train will path to this station unless one leaves it/changes path by player action (decrements C by 1)
3) hard lock (current behavior, circuit network disables station)



Hope that addresses potential issues and clears it up a bit.

Ok so yesterday i did prototype for a "train stop trains limit" concept. Implementation is quite simple and has its own limitation.

Prototype adds lua "trains_limit" on train stop. For now this is manually controlled value. When collecting train stops to reach, i am doing scan over all trains to gather amount of trains related to each train stop (if is parked on given train stop or if has path that ends on given train stop). That way if train stop has enough trains related to it, it will not be added to train stops given train can path to. Tiny exception: if train was already going to given train stop, this train stop is allowed (its counter is not incremented when doing scan over all trains so it should be 1 less than a limit). This has its limitation because some trains may see given train stop as unreachable/disabled but i am not repathging possible trains when amount of related trains falls below threshold. This will be important later with back-pressure examples.

What this prototype does not do: it does not allow using CN to set limit, nor repaths trains (as mentioned above).

For my tests i am using save file for which i do not remember where it came from. It is called "Megabase_Rail_1_1_Everything_v018.zip". Inside level.dat there are some mentions of user "Headjunkie". This save file is enough for experiments (assuming rail crosssections are fixed, because they have rail signals in place where rail chain signals should be used, without fixes sometimes trains deadlock on crosssections).

Now lets discuss some use cases that happen in Factorio.


1 to 1 train delivery.

This is simplest rail setup. There is 1 train stop where items are loaded and 1 where items are unloaded. This setup does not benefit when using "trains_limit". It can be simply controlled by changing amount of trains with same schedule and adjusting train input buffers (maybe couple of sections with rail signals so they can stand behind a train that is being loaded/unloaded).

In case trains limit would be used and set to 1, train leaving pickup(load) station would reserve drop(unload) train stop. When next train would be loaded quickly before first reaches drop train stop and is unloaded, second train would no-path. If trains limit would also be used on second drop train stop, this train after being unloaded would nopath if there are more trains in loop than total slots in both train stops.


N to 1 train delivery

This use case can be easily achieved by using trains with dedicated schedule. If given pickup train stop is near, prepare for example 2 trains that would contain given station in schedule and common smelter station. That way is is easy to control amount of trains going to each pickup station.

In tested map there are for example 2 stations named "Iron Source 2-1" and "Iron Source 2-2", each with 2 dedicated trains. There is also "Iron Source West West 1" with 7 dedicated trains and "Iron Source West West 2" with 5 dedicated trains. There are more iron sources but i skipped them for this tests. Setup that is here works fine as it is. Amount of trains going to smelters is limited.

Now lets use trains limit on this pickup stations. Each train stop will receive limit equal to amount of trains in loop before change and rename each train stop so they are under same station name "Iron Source".
For now there are no major issues if pathfinding since in all cases each train has at least one train stop it can path to in every case. There are some througput issues showing. Trains that came from near pickup train stop, when going to smelter station, will reduce amount of trains related to given pickup train stop. That means that trains that were going to far away pickup train stop, are now rerouted to near train stop (since they are from same station and this train stop is closer/has lower total cost). This means that less trains are going to far train stop and so item input flow is limited to 3 out of 4 train stops. Some trains are simply always waiting on train stop that is near.

To fix throughput issue, lets simply add more trains with same schedule.

In case of low ore consumption, this may give something like this:
In this case input stacker is too small but in most cases it works fine.

If ore consumption is high, trains will be quickly unloaded and they will be sent to pickup station. Since there are more trains than total slots in all train stops, some of them will no-path right on unload station. This means if all ore pickup stations are full, no more trains will be sent to them. They will instead no-path.
I did not add repath after limit drops so they are stuck, but this is prototype limitation. They are sitting in smelter station blocking other trains right in case when we need a lot of ore (we are in high ore usage condition). This means now there is need for output stacker - place with fake pickup train stop that is behind CN closed rail signal. This prevents them from going into nopath.
This output stacker has to be of special kind: any train must be able to exit without waiting for other trains to leave. Doing output stacker without this property means that if blocked train will be first to repath and will see pickup train stop being not full, it will repath, will reserve given train stop and now pickup train stop is again full. Train in front is unable to leave since all train stops are again full.

For now it was only trains limit on pickup train stops.

Smelters here is using input stacker with train stops. Lets try to use trains limit on them to reduce congestions in case of low ore usage. On each stacker train stop lets set limit of 1 train. This means if train will manage to reserve given train stop, it will have guaranteed place in input stacker and so no congestion should happen. Here small note: train that passed stacker train stop (waypoint), is no longer related to given train stop and so it does not make it full.

This limit on stacker train stops makes back-pressure to happen. Trains that are on ore pickup train stop will not leave until they have guaranteed spot in input stacker. This could be a nice feature since less trains are in transit. Amount of trains in transit is limited by amount of stacker train stops total limit.

Because of prototype limitation (no repath for trains with nopath), i made single disconnected stacker train stop not connected to other rails. By CN it is pulse enabled for 1 tick every 120 ticks. Performance right now is not important.

For what i do not fully understand, trains started to behave weird. Train could enter on stacker lane and instantly repath to adjacent stacker lane. This path would be however all around smelters. They started to block stackers since train in front of them would in that case be almost instalty reserved by other trains far away and train would not be able to reserve given stacker train stop again. Sometimes they also started to nopath, i do not know why (yet?)

I cannot make fake stacker train stop to prevent them from nopath since this would remove back-presssure: all trains on far train stops would always be able to path to it and would leave pickup train stop. To fix this, input stacker of same size as output stacker would be needed (shared input-output stacker would be better).

For now, trains were using input stacker train stops as waypoints. This has nice feature that trains that are going for unload train stops are only after input stacker train stops and so they are near. This means i could setup trains limit on unload train stops. Trains in stacker would start to repath so fake ore drop train stop was required.

Why even using input stacker? Lets set each unload train stop to some nice amount of trains, lets say 3. Here throughput also plummets. Input stacker is now useless. It could be that all 3 slots of limit could be allocated by 3 trains that are far away. This ore train stop is not going to get any ore until this trains will arrive, going through whole map. Doing fake ore drop train stop makes it worse: now some trains could be in input stacker lured by enabled fake train stop. At some point ore train stop becomes not full. Train that is on the other end of map reserves this slot. All trains in stacker are unable to move since all ore drop train stops are full. Train that is going from other end of map meets full input stacker and is unable to reach ore drop train stop.

At this point i stopped testing this concept as at every point it starts to introduce more issues than features it would introduce.

-- edit:
Refs given by Bilka: 70248 64162 56375 67740

(My bad, TL;DR - at least properly - yet.)

KoblerMan wrote: Sun Jan 26, 2020 6:17 pm

ThunderFD wrote: Sat Jan 25, 2020 8:07 pm

KoblerMan wrote: Sat Jan 25, 2020 5:45 pm

GottZ wrote: Fri Jan 24, 2020 3:57 pm scenario:
you have 5 iron ore mines with chests and loaders attached.

0 ore in the chests: train station outputs a request value of 0 cause it is unreasonable to send a train to a empty station

1 - amout of circuit calculated train cargo: train station outputs a request value of 1

n train cargo + 1 ore available: n+1 output signal until the number exceeds the maximum number of trains the station can keep off the main rail (waiting station with signals) (comparator ftw)

if you use signals / toggle train stations, you will send out all available trains that have this station set as next target.

to counter that, you'd have to create individualized train depot stations with separate logic to only let trains move when a circuit logic signal is present.
problem:
two trains leave.. great.
but they arrive at the same station even though two separately positioned stations are available.


additionally it would be awesome if circuit logic could tell a train to skip the next N stations with one tick so it would be possible to use multiple cargo trains for different items and balance them through circuit logic.
even better: make it so configured stations can be targeted with a circuit logic expression that was send by the current train station.

Guess what? You can do EVERYTHING HERE with circuit network logic.

You can configure any given station to turn off under specific conditions, including (but not limited to) being occupied already by a train; not having enough resources in chests to justify allowing a train in; or knowing based on remaining resources to mine (such as none left) that the remainder of resources in the chest is the only amount that the station can provide, then allowing a train in to pick up the last of the resources and permanently disable the station afterward. I know this because I've done it all before. Why add logic like this into the trains when you can create it yourself?

Side note: if any of you are particularly interested in doing this, my hint to you is that most logic is actually handled at the resource pickup area. Also, remember that trains themselves can hold logic. A friend of mine actually theorycrafted wireless transmission of data using logic and the train network, and I watched it work. It was like magic to me.

what if you have 5 trains waiting at iron plate stations full with iron plates to deliver - now one iron plate unloading station goes active again and boom! multiple trains on their way - there's no easy solution to limiting how many trains go to a station if multiple are waiting for a station with that name to unlock
... you could do a super complicated thing with global circuit wires and blocking off the trains with signals, but then you probably can't dispatch to different stations at the same time as the trains would path to the same station, without going super crazy... or am I missing something very obvious?
I'd love a limiter of how many trains can be on their way to a station at the same time

I've run into the same problem before, and it's very difficult to do on a global train network. But, it can actually be done wirelessly. What you do is have a stacker in front of something that keeps a count of trains that leave, and compares them to the number all the possible stations that train could go. It has a counter that decrements for trains leaving and increments for arriving. A station that opens sends a pulse out that requests a train once, and it is received by your trains in holding. If the number of trains currently out for pickup is greater than or equal to the amount of currently open stations, you do not allow more trains through. In doing this, you can limit how many trains can arrive at each station.

My friend theorycrafted this and employed it after experimenting with wireless trains. Because it's wireless, there is a lot more overhead and you can see latency on networks where pickup outposts are further away. It's actually for that reason that we decided to scrap the idea and just went for a global circuit network instead. If you think you could figure out how to reproduce the wireless idea and make it more efficient though, by all means give it a shot.

I believe I saw this recent video that showcases what you are describing here ?
https://www.youtube.com/watch?v=hXIU3lYV53o [РУ/ENG]

boskid wrote: Mon Jan 27, 2020 2:53 pm 1 to 1 train delivery.

This is simplest rail setup. There is 1 train stop where items are loaded and 1 where items are unloaded. This setup does not benefit when using "trains_limit". It can be simply controlled by changing amount of trains with same schedule and adjusting train input buffers (maybe couple of sections with rail signals so they can stand behind a train that is being loaded/unloaded).

In case trains limit would be used and set to 1, train leaving pickup(load) station would reserve drop(unload) train stop. When next train would be loaded quickly before first reaches drop train stop and is unloaded, second train would no-path. If trains limit would also be used on second drop train stop, this train after being unloaded would nopath if there are more trains in loop than total slots in both train stops.

Does this need fixing? It can either be viewed as having too few stops for the amount of trains handled, similar to the case of having too many trains for too few segments. Except that the stations are the segments here. Perhaps this is also just a use-case where the user would use no train limit, as per usual. It doesn't strike me as any more offending than trying run 4 trains on 4 rail segments. They jam. Though it probably speaks to having _no train limit_ (i.e. all trains allowed) be the _default_ setting.
I see two potential fixes, the first one complex:
If it has to be addressed, the data each train station holds would need to be expanded: Each train station would need to be aware of the train currently in it and looking to leave (done unloading/loading, ready to depart, but no path). If another train targets this station as it's destination, but before being refused because the max number of trains already is at this station, check if a) there is a train looking to leave the station and b) the train looking to leave accepts the incoming train's current station as a valid input. If it does, outgoing train's new destination is incoming train's origin and they can both depart. Bit of work to setup, if the stations keep their current train in memory not too computationally intensive (wouldn't need to check all stations or trains or anything; just compare candidate to ask if he can come to this station, with the train currently at the station).
The second one prone to error (not recommended, could be used to test in known system):
As soon as a train is able to leave, but can't path, reduce the the CurrentNumberOfTrainsAtStation by 1, even before it left. Odds are, it will unstuck (as it's _likely_ to go to a station that can now dispatch a train towards the fake-open station). Could lead to problems. Would not recommend. But it's quick and dirty, could be used for testing very quickly? Sort of simulates the correct effect if you work within your test setup (only two types of stations: ore provider and ore delivery).

boskid wrote: Mon Jan 27, 2020 2:53 pm N to 1 train delivery

This use case can be easily achieved by using trains with dedicated schedule. If given pickup train stop is near, prepare for example 2 trains that would contain given station in schedule and common smelter station. That way is is easy to control amount of trains going to each pickup station.

In tested map there are for example 2 stations named "Iron Source 2-1" and "Iron Source 2-2", each with 2 dedicated trains. There is also "Iron Source West West 1" with 7 dedicated trains and "Iron Source West West 2" with 5 dedicated trains. There are more iron sources but i skipped them for this tests. Setup that is here works fine as it is. Amount of trains going to smelters is limited.

Now lets use trains limit on this pickup stations. Each train stop will receive limit equal to amount of trains in loop before change and rename each train stop so they are under same station name "Iron Source".

simple_limit.png

For now there are no major issues if pathfinding since in all cases each train has at least one train stop it can path to in every case. There are some througput issues showing. Trains that came from near pickup train stop, when going to smelter station, will reduce amount of trains related to given pickup train stop. That means that trains that were going to far away pickup train stop, are now rerouted to near train stop (since they are from same station and this train stop is closer/has lower total cost). This means that less trains are going to far train stop and so item input flow is limited to 3 out of 4 train stops. Some trains are simply always waiting on train stop that is near.

I'll need to ask for clarification. You say "That means that trains that were going to far away pickup train stop, are now rerouted to near train stop".
Does this mean that:
a) trains that are _currently_ on their way to far away pickup train stop change their intended destination to a near train stop?
or
b) there are now too many trains slots open for the nearby stops (i.e. maxTrainPerStation is so high that it gets all trains on the network to go there)?

In the case of a), I would argue that a train currently en route to a destination should at no point change it's mind as to what it's destination is. If this is currently the case, what are the benefits of it? It's bound to cause problems with same-name stations, as the pathing will pick the shortest path if it's rerun constantly during travel. Also, is that not unnecessarily computationally intensive?
In the case of b), I would argue that the maxTrainPerStation was poorly set. Now this is not an attack or anything. You're working with an existing train system and trying things out. With a new way of doing trains. I'd argue that all (or even most trains) going to the nearby station is a result of one or two things:
- The nearby train stations accept more trains than is desired. Their desired acceptance should be reduced.
- If the stations still manage to satisfy all trains (load them on time), the stations were initially set up with fewer trains to be long-lasting for some reason. Again, to simulate that intent the number of allowed trains should be reduced.
- If the stations are struggling/unable to satisfy all trains (load them on time), the stations were never designed for such a high volume of trains. Again, to simulate that intent the number of allowed trains should be reduced.

boskid wrote: Mon Jan 27, 2020 2:53 pm To fix throughput issue, lets simply add more trains with same schedule.

I believe the issues observed above do not warrant adding more trains to fix the throughput issue, but rather playing around with the settings of how many trains are allowed per station. It worked fine with the given amount of trains. It should be possible to approximate the throughput (if the rerouting is not a path change while en route, as I explain in a) above).

The addition of trains is going to lead to the below explained complications, which are to some extent also encountered in current setups. The only novel issue being a no-path error by adding more trains than valid stations, which is an issue created by oversaturating the system. (again, like putting too many trains on a rail system with too few segments; except that segments are stations when working with the same-station-name-maxTrain-paradigm).

boskid wrote: Mon Jan 27, 2020 2:53 pm In case of low ore consumption, this may give something like this:

low_ore_usage.png

In this case input stacker is too small but in most cases it works fine.

If ore consumption is high, trains will be quickly unloaded and they will be sent to pickup station. Since there are more trains than total slots in all train stops, some of them will no-path right on unload station. This means if all ore pickup stations are full, no more trains will be sent to them. They will instead no-path.

Basic issue of more trains than stations. Resolving for equal amount of trains and stations was proposed above. Resolving for more trains than maxTrainPerStation slots is not possible without adding intermediary stations (stacking/waiting area, to which you'll come in a moment).

boskid wrote: Mon Jan 27, 2020 2:53 pm high_ore_usage_nopath.png

I did not add repath after limit drops so they are stuck, but this is prototype limitation. They are sitting in smelter station blocking other trains right in case when we need a lot of ore (we are in high ore usage condition). This means now there is need for output stacker - place with fake pickup train stop that is behind CN closed rail signal. This prevents them from going into nopath.

Output or input stacker are useful to work with the system if you use more trains than you have stations. I.e. adding fake stations as you correctly call them.
A tradition stacker for incoming trains (i.e. a set of parallel rails accepting incoming trains, only managed by rail signals and not stations) will work just fine with maxTrainPerStation property. If a station accept 20 trains, and you want all trains to be able to be as close as possible to delivery, you'll need a stacker with 19 slots leading to the unloading station. Each slot in the stacker can accomodate 1 value of maxTrainPerStation. I.e. stacker size + maxTrainPerStation(for all stations on the schedule, both for loading and unloading) give you the total amount of trains able to navigate the network.

This is not fundamentally different to a regular rail network. You can't just add 20 trains out of nowhere without it risking to clog up crossing or segments of your rail. In this case, it doesn't risk clogging up your network, instead it clogs up your stations. I guess that would be a positive, in a sense? It's still ultimately a problem with the rail network itself.

boskid wrote: Mon Jan 27, 2020 2:53 pm high_ore_usage_output_stacker.png

This output stacker has to be of special kind: any train must be able to exit without waiting for other trains to leave. Doing output stacker without this property means that if blocked train will be first to repath and will see pickup train stop being not full, it will repath, will reserve given train stop and now pickup train stop is again full. Train in front is unable to leave since all train stops are again full.

I'm not sure I understand the design of the stacker. A train unable to find a designation is blocking trains that found a designation. Why was there a train with no correct designation in the way blocking other trains in the first place? If it's the case that the train went out to a destination, stopped and for some reason tries to find a new destination, then I don't understand why that would be the case. A valid destination was found. It should not be removed and the train should keep heading there. Only by direct player interaction or finishing it's journey should the train be able to find it's next destination.

If the problem a result of a station being disabled entirely?

Please elaborate a bit on this point. I'm not entirely sure what's going on here.

boskid wrote: Mon Jan 27, 2020 2:53 pm For now it was only trains limit on pickup train stops.

Smelters here is using input stacker with train stops. Lets try to use trains limit on them to reduce congestions in case of low ore usage. On each stacker train stop lets set limit of 1 train. This means if train will manage to reserve given train stop, it will have guaranteed place in input stacker and so no congestion should happen. Here small note: train that passed stacker train stop (waypoint), is no longer related to given train stop and so it does not make it full.

This limit on stacker train stops makes back-pressure to happen. Trains that are on ore pickup train stop will not leave until they have guaranteed spot in input stacker. This could be a nice feature since less trains are in transit. Amount of trains in transit is limited by amount of stacker train stops total limit.

I would recommend not using a stacker made out of stations, but to use a stacker made out of signals instead. I'm not sure about the exact size of stacker. Let's say it has 12 lanes. If you put a station on each lane with max train limit to 1, this will reduce throughput, as only 12 trains can move at any given time.
Let's say you have 3 unload stations, and don't use stations for your stacker, but signals. If each station accepts 4 trains, 12 trains can move at any given time. Same as above, without making each spot in the stacker reserved, but dynamic.
If you want more trains moving than your stacker has capacity (reasonable, it's what we do now anyways), you do the same thing as you currently do and guess how many extra trains you can support (by rapid unloading etc). Say you determine it's fine to have 24 trains travel at any one time, because they'll be unloading fast enough, you can say that each station now accepts 8 trains. It's the same as currently assigning extra trains to a line.

Either way, I'm unsure how this is a problem in itself?

boskid wrote: Mon Jan 27, 2020 2:53 pm Because of prototype limitation (no repath for trains with nopath), i made single disconnected stacker train stop not connected to other rails. By CN it is pulse enabled for 1 tick every 120 ticks. Performance right now is not important.

For what i do not fully understand, trains started to behave weird. Train could enter on stacker lane and instantly repath to adjacent stacker lane. This path would be however all around smelters. They started to block stackers since train in front of them would in that case be almost instalty reserved by other trains far away and train would not be able to reserve given stacker train stop again. Sometimes they also started to nopath, i do not know why (yet?)

I cannot make fake stacker train stop to prevent them from nopath since this would remove back-presssure: all trains on far train stops would always be able to path to it and would leave pickup train stop. To fix this, input stacker of same size as output stacker would be needed (shared input-output stacker would be better).

For now, trains were using input stacker train stops as waypoints. This has nice feature that trains that are going for unload train stops are only after input stacker train stops and so they are near. This means i could setup trains limit on unload train stops. Trains in stacker would start to repath so fake ore drop train stop was required.

I'm not sure I understand either. Perhaps images of what exactly is going on would help. Sounds like the train on the stacker (stacker station, right?) might have skipped parts of it's schedule, until it reached the stacker portion again? Perhaps the oversaturation of the network at this point? Perhaps just a bug? I'm sorry but I really have a hard time "seeing" the situation in my mind here.

boskid wrote: Mon Jan 27, 2020 2:53 pm Why even using input stacker? Lets set each unload train stop to some nice amount of trains, lets say 3. Here throughput also plummets. Input stacker is now useless. It could be that all 3 slots of limit could be allocated by 3 trains that are far away. This ore train stop is not going to get any ore until this trains will arrive, going through whole map. Doing fake ore drop train stop makes it worse: now some trains could be in input stacker lured by enabled fake train stop. At some point ore train stop becomes not full. Train that is on the other end of map reserves this slot. All trains in stacker are unable to move since all ore drop train stops are full. Train that is going from other end of map meets full input stacker and is unable to reach ore drop train stop.

I can see this being a poor use for the maxTrainPerStation feature and how it would result in bad throughput. There's really nothing more I can say to that. It should most likely not be used in such a way. Preferring intermediate dropoffs (i.e. getting a OreStationEast (for all ore fields) and OreDepotStationEast (storage/exchange location closer to the base) would probably be preferable. Obviously the longer the path, the higher the latency from train departure to arrival. The lower maxAmountOfTrains, the higher the throughput loss. The deadlock in the system is ultimately a result of having more trains than are handled by your stacker and station capacity. Without the maxTrainPerStation property set to a low value, you'd have regular behavior of trains being "stored" somewhere on the rails, in transit, etc.

boskid wrote: Mon Jan 27, 2020 2:53 pm At this point i stopped testing this concept as at every point it starts to introduce more issues than features it would introduce.

I'm saddened to hear this and would like you to reconsider about it. I hope I have been able to address some of the issues, and while I still need some clarification, I fail to see a genuine problem with the maxTrainPerStation concept. What we figured out is that it has it's own challenges and use-cases. Some situation may be best left unchanged (default behavior: unlimited amount of trains). There may be many issues related to using a pre-existing rail system designed to work another way, adding on trains to fill a perceived shortcoming, and then observing a lot of undesirable behavior.

Respectfully, I think much of it went wrong around here

boskid wrote: Mon Jan 27, 2020 2:53 pm To fix throughput issue, lets simply add more trains with same schedule.

and caused a whole slew of complications.

As to the part where you said trains are starting to behave "weird", I genuinely don't understand the full scale of the test done. Why they would essentially try to repath to a station they are already on is beyond it. I don't see how it would be possible under the system I proposed. If you have any further insight? I'm absolutely puzzled by it, and would like to solve this odd little problem

I hope you had an opportunity to look at my post preceding yours as well (was probably made while you were typing out your response), and if there are any questions, concerns or problems please bring them up and I'll be happy to work with you towards a solution

Again, thank you for committing time and effort into looking at this proposal. It means much to me, and I'm yet hopeful that the issues unrelated to the rail design itself are fairly minimal. It would be fantastic to add this feature to vanilla factorio; essentially the power of LTN, without the need for depots!

Cheers

Firstly, for clarity let's try to use Train Stop for a specific destination, and Station for all possibly scheduled stops of the same name. It may be a bit late to introduce that formality, but it's good to avoid confusion where possible.

A train stop max-inbound-cap (ideally set by circuit network) was specifically motivated by the situation where enabling a single train stop could result in many trains suddenly pathing there at the same time. Without a cap, the only possible prevention is wiring up every corresponding stacker-exit signal to restrict the number of trains departing.

This is not an N to 1 case, but rather 1 to N: A large central array with many smaller destinations, potentially being overwhelmed and causing jams if their decentralized stackers are too small for the sudden influx. This can be mitigated by having a wasteful (and potentially side-effect inducing) bypass branch allowing trains to abort and return, but the other issue remains: While swarming the first train stop to have been enabled, none of the trains could consider going to another distant train stop of the same name and schedule slot enabled shortly after the first one they tried to reach.

Both enable/disable control and max-inbound-capping can cause unwanted and confusing behavior (dead-end "No path"ing on a subsequently-disabled terminus branch or "Destinations full"ing if pathing to a station lacking enabled&below-inbound-cap stops), but together they have synergy: The limit is intended to address an issue with the enable/disable feature itself.

Thank you IronCartographer.

Yes I'm entirely at fault for making it more confusing than necessary by not formally coining terms for destination/origin stations and adhering to it.

What you bring up, I realize, has been completely missing from the discussion: the motivation for the system. While it was clear to me and probably many others, I should have addressed it plainly in the opening. This just being "one more attempt to fix the issue", I went straight to a solution without mentioning the issue. Oopsie

You explain the raison d'être of my proposal perfectly. A test scenario would ideally be built around it, that being it's use-case.

Thanks!

Molay wrote: Mon Jan 27, 2020 6:38 pm I'll need to ask for clarification. You say "That means that trains that were going to far away pickup train stop, are now rerouted to near train stop".
Does this mean that:
a) trains that are _currently_ on their way to far away pickup train stop change their intended destination to a near train stop?
or
b) there are now too many trains slots open for the nearby stops (i.e. maxTrainPerStation is so high that it gets all trains on the network to go there)?

b. Since trains going from ore pickup to ore drop no longer reserve near ore pickup train stop, other trains will try to go to this ore pickup train stop first since it is closer.

Molay wrote: Mon Jan 27, 2020 6:38 pm I'm not sure I understand the design of the stacker. A train unable to find a designation is blocking trains that found a designation. Why was there a train with no correct designation in the way blocking other trains in the first place? If it's the case that the train went out to a destination, stopped and for some reason tries to find a new destination, then I don't understand why that would be the case. A valid destination was found. It should not be removed and the train should keep heading there. Only by direct player interaction or finishing it's journey should the train be able to find it's next destination.

Issue is that if on single stacker lane there are 2 trains, it may happen that train behind will repath and reserve ore pickup train stop, however train in front of is preventing its exit. Train in front is unable to reserve ore pickup train stop since it is full.

Molay wrote: Mon Jan 27, 2020 6:38 pm I would recommend not using a stacker made out of stations, but to use a stacker made out of signals instead. I'm not sure about the exact size of stacker. Let's say it has 12 lanes. If you put a station on each lane with max train limit to 1, this will reduce throughput, as only 12 trains can move at any given time.

Well by having stacker with train stops (all of them are of same station. station=group of train stops with same name) i was later able to limit amount of trains going to ore dropoff and provide nice back-pressure. This also has a nice property that trains will by default fill stacker in a way that does not block incoming rails on multiple trains going to same stacker lane. In this place stacker will balance after some time because of repath and penalty of segments that are occupied by train.

Molay wrote: Mon Jan 27, 2020 6:38 pm I'm not sure I understand either. Perhaps images of what exactly is going on would help. Sounds like the train on the stacker (stacker station, right?) might have skipped parts of it's schedule, until it reached the stacker portion again? Perhaps the oversaturation of the network at this point? Perhaps just a bug? I'm sorry but I really have a hard time "seeing" the situation in my mind here.

I found out what was issue here. Waypoints force special train behavior. Train may show it is going to stacker train stop but its braking point is already ahead and so train internally no longer keeps stacker train stop reserved. Other trains reserved all stacker train stops slots. When train was forced to repath on signal (because braking point was unable to reserve rail signal), it repathed from its current position, failed to reserve stacker train stop and entered nopath (or pathed to adjacent lane). To fix this, i would have to keep reservations for waypoint train stops until they are officially passed by train.

IronCartographer wrote: Mon Jan 27, 2020 7:10 pm A train stop max-inbound-cap (ideally set by circuit network) was specifically motivated by the situation where enabling a single train stop could result in many trains suddenly pathing there at the same time. Without a cap, the only possible prevention is wiring up every corresponding stacker-exit signal to restrict the number of trains departing.

This is not an N to 1 case, but rather 1 to N: A large central array with many smaller destinations, potentially being overwhelmed and causing jams if their decentralized stackers are too small for the sudden influx. This can be mitigated by having a wasteful (and potentially side-effect inducing) bypass branch allowing trains to abort and return, but the other issue remains: While swarming the first train stop to have been enabled, none of the trains could consider going to another distant train stop of the same name and schedule slot enabled shortly after the first one they tried to reach.

This is one of use cases that would benefil a lot from this feature. On map on which i was testing pathfinder performance, there was train stop to pickup stone, 6 trains that were almost always loaded with stone and ready to leave, and train stop on opposide side of map where train stop was enabled when not enough stone was in dropoff chests. Of course all 6 trains would try to go there but at some point 5 of them would go back since 1 was first and train stop was disabled before they could reach.

That all sounds very promising, boskid! To me it seems that there are no inherent major problems with the maxTrains concept if I'm reading you correctly. Just as with our now well known and studied rail layouts that have proven to be effective, the maxTrain property seems to offer it's own interesting design challenges for the player to explore and learn about; just as I had to explore why trains would no nopath all the time when first playing around with them all those years back.

Have you had an opportunity to further explore the merits of the system in 1-N situations? In my opinion that alone would justify the addition, and solve the long outstanding issue you described at the end. Particularly combined with the ability to set maxTrain via signal depending on the needs of the station.

Are there still any major problems remaining you want to throw at us to see if we can help resolve them?

I hope I didn't misunderstand that the idea is still being considered and explored?

Thank you!

boskid wrote: Mon Jan 27, 2020 2:53 pm If ore consumption is high, trains will be quickly unloaded and they will be sent to pickup station. Since there are more trains than total slots in all train stops, some of them will no-path right on unload station. This means if all ore pickup stations are full, no more trains will be sent to them. They will instead no-path.

....

I did not add repath after limit drops so they are stuck, but this is prototype limitation. They are sitting in smelter station blocking other trains right in case when we need a lot of ore (we are in high ore usage condition). This means now there is need for output stacker - place with fake pickup train stop that is behind CN closed rail signal. This prevents them from going into nopath.

You are overthinking this here. If our mines are dry then those few trains waiting in the stacker won't make a difference.
The base will soon starve. An output stacker will only delay that a little bit.

My solution to the problem was to have alarms at the smelters that went off when the buffer chests start to get empty.
Then you have to build new mines fast or face the starving of your base..

Nearly a year ago I had a factory where nearly all train transport was not done with fixed assignments but with n to m OR n to 1 solutions.
I think it's efficiency would have been way better if I had the "Max number of trains" feature back then.

Here is the download link: https://drive.google.com/open?id=10UgIx ... c0UHJBHhc0
There is a lot broken due to migration but the trains and smelters are fine.

This is just another entry in the eternal "take this challenging design puzzle I don't like solving out of the game" parade. The only argument made in favor of this change is "it makes the game easier". That's more fun for some, less fun for others. There's _lots_ of simple, fun builders out there. There aren't so many challenging, fun builders. Managing dozens of mining outposts without dedicated trains is doable and challenging, it involves lots of tradeoffs, simplicity, efficiency, reliability, the works. Add this and it's reduced to a dwiw toggle.

quyxkh wrote: Tue Jan 28, 2020 7:06 pm This is just another entry in the eternal "take this challenging design puzzle I don't like solving out of the game" parade. The only argument made in favor of this change is "it makes the game easier". That's more fun for some, less fun for others. There's _lots_ of simple, fun builders out there. There aren't so many challenging, fun builders. Managing dozens of mining outposts without dedicated trains is doable and challenging, it involves lots of tradeoffs, simplicity, efficiency, reliability, the works. Add this and it's reduced to a dwiw toggle.

You should read boskid's post if you find the time, the obvious design challenges when working with maxTrain are different and novel to the current train paradigm. Perhaps this will soften your elitist attitude a little bit.

At it's core, it's going to allow for things not currently realistically possibly due to train behavior limitations and yes, also add a modicum of convenience to the management of trains. Notably when stations run out of ore and a new one needs be established.

While I appreciate that some players embrace the pain of pushing a square through a round hole, I don't think this is a common attitude. Nor does factorio strike me as a game designed to force players into hacky overengineered solutions to address basic issues. Thank you for your input and confirming that the system is so efficient that it turns trains into a dwiw toggle. I think boskid may still be testing however how true that statement is

Cheers

quyxkh wrote: Tue Jan 28, 2020 7:06 pmManaging dozens of mining outposts without dedicated trains is doable and challenging, it involves lots of tradeoffs, simplicity, efficiency, reliability, the works. Add this and it's reduced to a dwiw toggle.

It's possible for a while but when the distances to your mines grows the number of trains that start the journey and are not needed when they get there rises.
You can't do anything against that except building logistic hubs

Nosferatu wrote: Tue Jan 28, 2020 9:14 pm You can't do anything against that except building logistic hubs

Except not getting into that jam in the first place, which is literally just building outposts you're going to need anyway.

Some of inbound train limit effects are possible to produce with circuit-controlled signals if you wire up every branch of every stacker where a train might be waiting, but it will not affect trains that are moving and potentially re-pathing with a resulting overload of simultaneous trains.

This is not trivializing vanilla behavior, and indeed as Molay said it brings with it and inspires its own design challenges.

IronCartographer wrote: Mon Jan 27, 2020 7:10 pm A train stop max-inbound-cap (ideally set by circuit network) was specifically motivated by the situation where enabling a single train stop could result in many trains suddenly pathing there at the same time. Without a cap, the only possible prevention is wiring up every corresponding stacker-exit signal to restrict the number of trains departing.

This is what i had in mind when happily reading the discussion here instead of little post here and there following an FFF.

Thread on which i commented amongst other thing this that is still bugging my mind :

mmmPI wrote: Mon Jan 27, 2020 8:22 am Also if you reduce the amount of train a station is allowed to handle on both end of a schedule. A=>B=>A. You had 3 trains allowed to A and 3 to B ( 3 trains total going back and forth) , you reduce the number to 1 and 1. ( 1 train is now "too many" ).

What is the train doing ? It can't be piling up behind any of the station A nor B, since that would not respect the condition, of "max_number_incoming_train", it would hang there not being able to just repath toward the next station in schedule.

This why i assumed some sort of depot where trains goes to park waiting for a call similar to taxi depot ( or LTN depot) , whereas busses would never need this since they would be running non stop and parking only at pick-up or drop-off location.

Reading this thread i feel like i was right. Using a stacker after the unload feels exactly like a depot in LTN. It is a place where (somewhat mismanaged ) trains shall wait instead of clogging the main rail network.

This just moves the problem to my eyes, instead of the risk that all trains depart to the same outpost that can't service them and pile up in front of it creating a jam. Those trains NEED a safe place to wait so that only the correct amount is sent to each outpost.

Now suppose you have 2 train stop called "iron load" open, and both accept 2 trains that are on their way ( so 4 total) . 1 of the stop closes after one train arrive and takes all the iron.
2 trains still go to the other train stop that is still open undisturbed, one train is now full of iron and goes to the unload. And the 2nd train that was aiming at a now closed train stop would repath toward the other open one where 2 trains are heading already. (this is without max_number_incoming train).

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 ? this doesn't solve the original problem, if one station opens, instead of all your iron trains going to it there would only be the number set by circuit, that's supposed to make things easier from what i read, but it requires a systemic approach rather than just adding 1 train after 1 train on dedicated lane (which IS easier and less error prone in my opinion).

The number of trains sent is supposed to prevent a jam caused by all trains going there. But unless i'm missing a thing, it's not "foolpoof", the situation i described would be really hard to debug if for some reasons the 2 trains going to the open station are slow/stuck/far away/out of fuel or any reason that prevent them from reaching their destination fast. It would leave a situation where you have one train saying no path, while you could see for yourself that there is actually a path. You wouldn't be able to know that 2 trains have already reserved the stop and if on top of that they are stuck somewhere ( let say by the train saying no path) then the stuff would just deadlock.

And if you tell me that i need to reduce dynamically the number of trains allowed to go to one outpost depending on the quantity it holds so that it doesn't close itself when some trains are still heading towards it to avoid the problem, i'd say that sounds fun but misses the point of not making overengineered methods.

Quick comparaison with LTN functionning, from memory so i may be wrong or things have changed, but i sort of remember that if you close a train stop while a train is heading there, the train would just repath to the depot, not to the next station on schedule, not freezing on spot, which is also sometimes causing problems, when a non-empty train end up in the depot after an unload was closed for example, the non-empty train can be later sent to a pick-up destination where it could mix its content, and even worse later when it goes to an unload while still non-empty of the previous undesired cargo in this case that may contaminate an unload station. ( those things are part of what makes me consider LTN as "advanced feature", use if you know what you are doing thing)

I'd be interested to try out the new thing, maybe as a mod ? I do not see it a simplifying the game by adding an easy to use powerfull feature. It is a powerfull feature, but hard to master and use which makes the challenge exciting but maybe not suited to vanilla game. Still curious to see how it unfold

If you're limiting stations to a small number of trains, I don't see the benefit to conditionally disabling the station.

If you had 4 source stations and 2 destination stations and 8 trains, you could limit the sources to 2 trains each and the destinations to 4 trains each. It would work in every way I can think of, provided you had enough stackers at each station.

boskid wrote: Tue Jan 28, 2020 11:03 amIssue is that if on single stacker lane there are 2 trains, it may happen that train behind will repath and reserve ore pickup train stop, however train in front of is preventing its exit. Train in front is unable to reserve ore pickup train stop since it is full.

I cannot think of a reason why you would ever set up a stacker this way, or a situation in the normal game where this setup would not cause problems eventually.

This is not an argument against train limiting, it's an argument against double stacking.