Factorio Forums

TL;DR

Stops could get a checkbox next to the circuit network setup that prevents other trains from choosing it as a destination once one is already on the way.

What?

Not much to illustrate, just a checkbox

Why?

I think the train tools are nice and intuitive, but one of the simplest use cases that newbies(read: me) are attracted to has a trap.
After getting tangled up in a mess leading to my first satellite launch I wanted a clean base with this setup:
- train grid with most cells only having 1-3 in- and outputs
- single-resource trains
- all schedules look like "Full load at O_X_RESOURCE", "Unload at I_X_RESOURCE"
- add cells when production is low, add trains whenever needed

Everything works well with some oversupply, except once a consumer activates all trains rush to it.
First arrives and disabled the stop, the rest either park behind(if there is a queue) or clog up the network for no reason.

After reading around a bit this is a common problem.
It's mostly solved solved by one of the following:
- using the LTN mod
- huge circuit network setup counting the required/active trains for each resource
- caving in and using dedicated multiresource haulers for each consumer
- giving up on the completely modular idea and have more rigid paths(megabases mostly use this approach)

There are lots of other train suggestions that would also cover this one.
Posted because I think this is the only thing missing from the "simple trains" toolbox.

Welcome to Factorio!

This sounds like a superb suggestion! While I still want more advanced tools in the future, just this simple thing would be a great step forward that will not confuse anyone while still improving things immensely so that we can be content for a while longer.

'Train stop' is the name if the item. 'Train stations' are a concept, basically a group of stops and all the other entitities locate together at the same outpost with somewhat related purpose.

The checkbox can't possibly be put on a 'station', but you meant Train stop and that should work fine. If several stops are in one station then checking the limiter on all of them would allow several trains to go for a station at a time, but that could be worked around by turning stops on progressively when there's enough demand to serve that many trains. And you want several trains to be able to go to all the stops with the same name concurrently as long as they choose different stops since otherwise, the idea breaks down. So, in conclusion, it seems like a fine idea.

Trains can reserve paths and there's a lot of similar logic for a lot of things in factorio. If you shoot rockets at natives then you can only send as many rockets as necessary to kill them. You can't shoot them more if there's already enough rockets mid air flying towards them to kill them, so you only shoot if there's another valid target. And bots reserve jobs and such. Hopefully, it's somewhat easy to implement so we can get this done quickly.

Edit: Maybe it could be a number limit. So instead of unlimited/1 checkbox toggle you have a unlimited/<any number> to limit the amount of trains that can go towards that stop if it's about the same difficulty implementation wise.

Yep, by stations I was referring to the 2x2, placable train stop items.
Fixed the naming.

This specific solution has come up a few times in recent months. Most of the time I think people have ended up agreeing with my solution that the better option is circuit controlled limits on the number of trains able to "path to or be at" a particular stop and circuit controlled train priority, with a bonus if we can get a circuit output for number of trains currently pathing to a particular stop. This set of available circuit conditions can easily allow very fine-tooth control over the number of trains routing to a particular stop, and also allow very simple setups like 'Only allow 1 train pathing to/sitting at this station' which is what's really needed to at least avoid the herd of trains problem.

Darinth wrote: ↑Fri May 03, 2019 12:17 pm This specific solution has come up a few times in recent months. Most of the time I think people have ended up agreeing with my solution that the better option is circuit controlled limits on the number of trains able to "path to or be at" a particular stop and circuit controlled train priority, with a bonus if we can get a circuit output for number of trains currently pathing to a particular stop. This set of available circuit conditions can easily allow very fine-tooth control over the number of trains routing to a particular stop, and also allow very simple setups like 'Only allow 1 train pathing to/sitting at this station' which is what's really needed to at least avoid the herd of trains problem.

Anything that solves the herding problem without a stateful+huge circuit tracker system, more is also good.
Did guess that it was brought up a million times before but didn't find anything.

Draba wrote: ↑Fri May 03, 2019 1:11 pm

Darinth wrote: ↑Fri May 03, 2019 12:17 pm This specific solution has come up a few times in recent months. Most of the time I think people have ended up agreeing with my solution that the better option is circuit controlled limits on the number of trains able to "path to or be at" a particular stop and circuit controlled train priority, with a bonus if we can get a circuit output for number of trains currently pathing to a particular stop. This set of available circuit conditions can easily allow very fine-tooth control over the number of trains routing to a particular stop, and also allow very simple setups like 'Only allow 1 train pathing to/sitting at this station' which is what's really needed to at least avoid the herd of trains problem.

Anything that solves the herding problem without a stateful+huge circuit tracker system, more is also good.
Did guess that it was brought up a million times before but didn't find anything.

I know a lot of people dislike dealing with the circuit system, and honestly I'm not a huge fan of some of it's aspects, so it'd definitely be nice to also have at least the number of trains able to be manually specified without circuits. While I may not personally consider it any big deal to add a constant combinator to my circuit controls, I absolutely understand people who don't necessarily want to deal with circuits.

Darinth wrote: ↑Fri May 03, 2019 1:52 pm I know a lot of people dislike dealing with the circuit system, and honestly I'm not a huge fan of some of it's aspects, so it'd definitely be nice to also have at least the number of trains able to be manually specified without circuits. While I may not personally consider it any big deal to add a constant combinator to my circuit controls, I absolutely understand people who don't necessarily want to deal with circuits.

I actually like the circuit system, but only for the cases where using it is still straightforward(no playing Sandstorm for me ).
A huge cell full of wires and combinators is an eyesore, my preference is a simple solution. Failing that a coding block to hide the jungle, like the lua box in From the Depths.
The circuit workarounds I seen were also stateful, can't just pick up/reshuffle/lose trains without dicking things up or having to add error handling.

I would also like something like this but with a configurable amount of trains being inbound on a station.

Inserters have configurable stack size. In GUI and via circuit wire. Same could be possible for stations.

And instead of having stations turn on/off with wires we could have just the limit.
So if we allow N trains in then N = 0 means that no trains are allowed to path to that station, which is the same as off.
If N is anything else that is the same as the station is on with a limit.
N = -1 can be unlimited amount of trains allowed in. Though a limit of 1 000 000 is in practise no different from unlimited since no one will ever build 1 million trains with the same station in their schedule.

Qon wrote: ↑Sun May 05, 2019 9:16 pm since no one will ever build 1 million trains with the same station in their schedule.

I fully expect someone from this community to do that just to prove you wrong.


On the topic at hand, does a station *know* how many inbound trains it has? What additional checks/calculations would be necessary?
While it would be useful for a few the same way as inserter stack size, it probably is a little more complicated than that, since it involves other entities.

Xeanoa wrote: ↑Mon May 06, 2019 9:13 am

Qon wrote: ↑Sun May 05, 2019 9:16 pm since no one will ever build 1 million trains with the same station in their schedule.

I fully expect someone from this community to do that just to prove you wrong.

I expect someone to think "I can do that" and start to try to prove me wrong. Trains are blueprintable after all. And give up when they realise that they have to manually set the trains to "auto" mode. 1 million trains, by hand, one at a time. And you have to open the GUI etc and can't just run by holding the copy settings button like you can with other things. Who would have guessed that the automation part is the one that requires manual intervention, a bit ironic don't you think?

You would have to write a command to set them all to auto mode for it to be possible. But that's trivial, so maybe...

Xeanoa wrote: ↑Mon May 06, 2019 9:13 am On the topic at hand, does a station *know* how many inbound trains it has? What additional checks/calculations would be necessary?
While it would be useful for a few the same way as inserter stack size, it probably is a little more complicated than that, since it involves other entities.

It only involves the trains themselves and the stop. Any train pathing to a stop would "tell" that to the stop which keeps a counter of how many trains are coming. When the counter is = limit then the stop shuts off (while still allowing trains on their way to see it as enabled). If the limit decreases below the count then some selection of trains to deny and force repathing on would have to be made. And for that, you probably need some sort of ordered data structure to keep track of which trains are closest or tried to get there first while also keeping the data structure fast when you want to delete trains from it in any order (as they might arrive in another order than the priority they were assigned when selecting the station). But arrival order is highly correlated with the priority so it might be fine to assume they will arrive at that order and just use a linked list that you loop through if prio is first come first served (last denied in case of limit decrease).

If you constantly set the limit to 1M (and have 1M trains with that station) and 1 then that might be a problem. Maybe just treat limit decreased below ingoing trains as the same as turning it off and on again with a new limit to make it as fast as toggling a station on/off. But that would probably mean that going from 2 to 1 would send away both trains incoming until they have looped around their schedule. So that's not a good solution either. So something better would probably have to be done to optimise it.

To extend this idea further, you could actually have a signal input for a number of allowed inbound trains rather than the limit always being 1. "Disabled" stops would simply have a value of 0 for the inbound train limit rather than a "Disabled" signal bool.

IronCartographer wrote: ↑Tue Apr 25, 2017 6:02 amWhat I would love to see is an extension of the Enable/Disable logic: Send a train stop a value (rather than a bool) for how many trains are allowed to path toward it at that moment. I'm not sure how efficiently that could be implemented, but it would be a huge step toward logistic network trains in vanilla. It would also prevent trains from pathing to a train stop that would be disabled before it arrived, causing this entire issue.

I fully support this, as you can see from the date of that old comment...

Edit: Ah, someone mentioned the same thing earlier in this thread. Excellent!

Darinth wrote: ↑Fri May 03, 2019 12:17 pm This specific solution has come up a few times in recent months. Most of the time I think people have ended up agreeing with my solution that the better option is circuit controlled limits on the number of trains able to "path to or be at" a particular stop and circuit controlled train priority, with a bonus if we can get a circuit output for number of trains currently pathing to a particular stop. This set of available circuit conditions can easily allow very fine-tooth control over the number of trains routing to a particular stop, and also allow very simple setups like 'Only allow 1 train pathing to/sitting at this station' which is what's really needed to at least avoid the herd of trains problem.

Qon wrote: ↑Mon May 06, 2019 9:35 am You would have to write a command to set them all to auto mode for it to be possible. But that's trivial, so maybe...

I made it a mod! Now trains start in automatic mode if built by robots:
Do Robots Build Automatic Trains?

Makes blueprinted trains start in automatic mode, automatically. So now you don't have to switch them from manual mode manually. With 'Recursive Blueprints' mod you can now completely automate scaling your train force!

You still need to place locomotives side-by-side as close together as possible from one corner of the 'infinite' map to the other corner to get 1 million trains though.

Qon wrote: ↑Sun May 05, 2019 9:16 pm Inserters have configurable stack size. In GUI and via circuit wire. Same could be possible for stations.

And instead of having stations turn on/off with wires we could have just the limit.
So if we allow N trains in then N = 0 means that no trains are allowed to path to that station, which is the same as off.
If N is anything else that is the same as the station is on with a limit.
N = -1 can be unlimited amount of trains allowed in. Though a limit of 1 000 000 is in practise no different from unlimited since no one will ever build 1 million trains with the same station in their schedule.

With hopefully one difference: With N=0 any train already pathed to the station would still go there. So you can basically turn off a station after all remaining trains have been serviced by setting N=0. This would also mean that a fluctuating N wouldn't cause trains to constantly repath and hog the UPS. N would only be checked when trains repath for one reason or another and ignored when the train already paths to the station.

mrvn wrote: ↑Thu May 09, 2019 10:47 am With hopefully one difference: With N=0 any train already pathed to the station would still go there.

Mmmmmmaybe? I'm not sure why. Is it just for performance?

mrvn wrote: ↑Thu May 09, 2019 10:47 am So you can basically turn off a station after all remaining trains have been serviced by setting N=0.

Stops are serviced by trains I would say. What does "all remaining trains have been serviced" mean and how would you keep track of that? Did you mean stops?

Qon wrote: ↑Thu May 09, 2019 11:34 am

mrvn wrote: ↑Thu May 09, 2019 10:47 am With hopefully one difference: With N=0 any train already pathed to the station would still go there.

Mmmmmmaybe? I'm not sure why. Is it just for performance?

mrvn wrote: ↑Thu May 09, 2019 10:47 am So you can basically turn off a station after all remaining trains have been serviced by setting N=0.

Stops are serviced by trains I would say. What does "all remaining trains have been serviced" mean and how would you keep track of that? Did you mean stops?

I mean stop and "all remaining" is all trains that have decided to path to that station. The game keeps track of which station each train did pick.

The point would be that any train on it's way would still arrive but no new train would decide to go to that station.

Is the goal for you to single tick the limit instead of holding it? Do you also wish train stops being turned off would have this behaviour now, where trains can continue to go there if they have already decided to?

I think hold signals would be easier to deal with in many cases.

Qon wrote: ↑Thu May 09, 2019 12:47 pm Is the goal for you to single tick the limit instead of holding it? Do you also wish train stops being turned off would have this behaviour now, where trains can continue to go there if they have already decided to?

I think hold signals would be easier to deal with in many cases.

Yes, I wish train stops had that option now.

My goal isn't to single tick the limit but anything but the simplest circuit network easily turns out that way. You quickly get something that will take several ticks to update and goes up and down till then or cycles between 2 or more values constantly. That should not result in trains repathing like crazy and making the game unplayable.

The solution to only check the N signal when repathing instead of repathing whenever N changes has the nice side effect that one can enable a station and allow e.g. 5 trains to path there. Then when 5 trains are on the way one can set it to 0 and forget about it. The 5 trains will arrive and no more. No need to slowly lower the limit to 4, 3, 2, 1 as trains arrive. Simply turn it off and forget about it.

mrvn wrote: ↑Thu May 09, 2019 1:33 pm Yes, I wish train stops had that option now.

My goal isn't to single tick the limit but anything but the simplest circuit network easily turns out that way. You quickly get something that will take several ticks to update and goes up and down till then or cycles between 2 or more values constantly. That should not result in trains repathing like crazy and making the game unplayable.

It could instead limit the repathing by not immediatly turning away trains. So if you set it to 0, 1, 0, 1, 0, 1 then the performance impact and train pathing would just be the same as if you just set it to 1. That would allow you to have hold signals instead of pulsed signals if you want that.

mrvn wrote: ↑Thu May 09, 2019 1:33 pm The solution to only check the N signal when repathing instead of repathing whenever N changes has the nice side effect that one can enable a station and allow e.g. 5 trains to path there. Then when 5 trains are on the way one can set it to 0 and forget about it. The 5 trains will arrive and no more. No need to slowly lower the limit to 4, 3, 2, 1 as trains arrive. Simply turn it off and forget about it.

But that sounds more complicated to me. And unless the train stop also tells the circuit how many trains are on their way it would be practically impossible for most to use. But I guess you would add that to the suggestion then to make your solution usable.

But it's not hard to "slowly lower the limit as trains arrive". That happens automatically. You just continuously set the limit to <resources missing>/<resources that fit in a train> and there's your limit, always up to date. It's trivial. You don't have to manually crank the combinators to make them update the values.

Well you _really_ want to avoid a situation where a train leaves a station, then the destination station reduces the number of trains it will accept, and suddenly a train is stuck on the rails with no path, because there is no station on its schedule that will accept another train. If the game only checks whether a station will accept another train when a train first chooses it's destination station, then that shouldn't be a problem.