Factorio Forums

TL;DR

When more than one train is waiting ("destination full") for a "train limited" station to offer a free slot, it seems to be arbitrary which train gets it. It would be cool if the "nearest" (routing logic) train gets a go.

What ?

2 Stations Iron-Ore-OUT each have a full train waiting ("destination full") for a free slot in one of two stations Iron-Ore-IN. When a slot frees up in station Iron-Ore-IN it would be cool if the nearest - according to routing logic - waiting train gets the slot. Right now I am observing behavior where a train would be waiting both in Iron-Ore-Out (1) and (2), Iron-Ore-In (1) would open a slot and the train at Iron-Ore-Out (2) would get it. Shortly after that Iron-Ore-In (2) would open a slot and the train at Iron-Ore-OUT (1) would get that. Both trains would take a very long path and pass each other in the middle.

Why ?

If implemented, the train limit feature would enable efficient large scale routing in vanilla factorio.

RTFM?

Please feel free to trash me, if the mistake is on my part...

As far as I know trains do not wait for each other to make their routing decisions so this could be hard to implement and you should avoid this scenario anyway in my opinion.

There should always be more slots at your smelters than you have trains running and if your mines are all closed because they are empty then your are in trouble too.

I would respectfully disagree

In order to secure full utilisation of your smelters you would need more(!) trains than you need. I always have (alot) more mines than I need. With the new train limit feature I can buffer ore trains at the mines and dispatch them exactly to where they are needed.

I use the same concept (OUT=>IN) all the way down to the final consumer, so you effectively get a pull system where full trains wait at the OUT station until they are needed at an IN station. OUT always has more capacity than IN.

I have more trains than I need.
But the stacker in front of the smelter can handle more trains than I need at the moment.
And the penaltys to routeing that are imposed by waiting trains + a few custom circuitrys gives me a nice trade-off between how far trains travel and how full my stations are.

But now I understand you. You want to do just in time delivery to save stacker space

I had a complex circuit system in place where I used signals to make the route to stations more costly depending on how "full" they were, effectively pushing trains away from stations that didn't need material to ones that were further away but empty. That worked - kind of - but was suboptimal with a bit of ad hoc rerouting of the trains whenever the capacity of the stations changed.

The signals before the station close depending on the amount of buffered material.
Train limits allow me to switch to a real pull system (not just the simulated one I describe above). It works! Great! Super! Happy! Big Smile! Except...

... it is arbitrary which trains gets the go. And I assume (hope) that there is some kind of algorithm use to choose which train gets a free slot. If that algorithm would chose the "nearest" waiting train all would be good

don't think this will be implemented in vanilla due to the overhead of determining which train is closest - train pathfinder performance is already spicy enough with a fair number of trains on the map.

you might want to try a mod like LTN that lets you do a closer approximation of what you're wanting.

though TSM is sounding perfect, you can use different priority queues and place the same station into a North, South, East, West priority queue.

but really, mods do the trick and vanilla doesn't need the overhead.

Mods are evil! They make things easy. Vanilla all the way!

But yeah, train scheduling is CPU intensive. It was using a huge amount of cycles in my 1.0 world. Probably due to the circuit-signal-scheduling-mech I was using then.

The same world with 1.1 train limits performed considerably better.

It would help just to use a "simple" proximity measure when selecting the train that gets the free slot. That way totally ridiculous routing as described in the OP wouldn't happen. (I know, "simple" isn't always simple. I write code for a living...)

@ptx0: btw...

I just checked LTN. It does the exact same crazy routing from the top of the map all the way to the bottom, even if there are enough resources right next to the depot. (I'm not sure I did LTN correctly. Just two hours in, but with a basic setup with 4 providers, 1 requester and x depot tracks/stops it shouldn't be that hard. And yes I get the encode network ID setting. Not what I would want as I do want an overflow if resources at the top are indeed missing...)

@factorio: please do consider the op. vanilla can do it!

ralfoeldi wrote: Mon Nov 30, 2020 12:33 pm it seems to be arbitrary which train gets it. It would be cool if the "nearest" (routing logic) train gets a go.

Why not the train that is idle for the longest time ?

What i have observed so far is :

tick1 a station open, tick2 trains that are made active by previous opening calculate a path, tick3 train start moving.
You can open close a station every tick, no train will ever move to it, it need to stay open at least 3 ticks.

My hypothesis for what happens is :

During tick2 trains created first based on their ID are updated first. So whichever train has the lowest ID (amongst those awaken by the station) is sent to fill in the request

I have no idea what happens if the first train cannot reach the station, i guess it's the second lowest ID, but when and how their path are caculated i have no clue.

I suspect that if the first trains fits, the game doesn't check all potential train and close the request as soon as a fitting train is found following the ID order. Which would make it very costly to make a change that would require all possible path calculated and compared in one tick so that the game chooses the nearest train.

On the other hand, i may be completly wrong, maybe the game already check multiple path at once to iterate faster through the different trains. it would be nice to have some real information


Given the picture it would be easier to call the station using different name, [iron out north]&[iron in north], [iron out south]&[iron in south], the train limit would then allow the system you describe at a local scale instead of map-wide.

If you want to expand the system you could have 10 [iron mine north] and 10 [iron mine south], the game would still choose "arbitrarily" from which outpost the full train is pulled but it only gets to pick in a list of humanly preselected area. It involve keeping track of flow per area, [sum of miner /sum of furnace /area].

With the proposed suggestion this would be done automatically by the game, and automatically updated. It would also be more forgiving in case you have a local unbalance in an area like [Iron north] since a train from another area like [iron south] would be pulled instead. there wouldn't be area no more.

There is also the centralization option, where you create a hub in a central location, and have some full trains wait there. In the example you could place it between the [iron in north] and [iron in south]. It wouldn't reduce the overall amount of unecessary travel time, but it would normalize the response time of material given the fix distance between an unloading area and the hub.

You could also combine both. Make several mini local hub.

I like the various trade-off, it gives several opportunity to test things, rather than the vastly superior way that is suggested, it's so good it must be costly in CPU-power

ralfoeldi wrote: Wed Dec 02, 2020 1:09 am
I just checked LTN. It does the exact same crazy routing from the top of the map all the way to the bottom, even if there are enough resources right next to the depot.

There it has reasons. It picks up a train randomly, because otherwise some depots run empty and others are more than full. If you want it more intelligent use train-networks in LTN.

@factorio: please do consider the op. vanilla can do it!

This is not so simple as it looks, because you need to calculate a route for each train, to do this correctly. Very CPU-heavy. You cannot just use the air-distance, that would make it in some cases very wrong.

Hi mmmPi,

I'm aware of all the options. Splitting areas, etc. And I've never asked for anything from the devs since playing since 0.13(?), solving all the challenges due to restricted features. (And never using mods )

What bugs me here, is that with train limits the game is soooo close to being able to handle a large scale system beautifully with vanilla! A "simple" proximity selection would be enough.

Hi sslik,

ssilk wrote: Wed Dec 02, 2020 8:05 am This is not so simple as it looks, because you need to calculate a route for each train, to do this correctly. Very CPU-heavy. You cannot just use the air-distance, that would make it in some cases very wrong.

Routing? Fine. "Accepted" (not that it is up to me to accept anything).

But the air distance couldn't possibly be worse than the status quo and would be better most of the time and... wouldn't cost (that much) CPU.

If a mod that would use that air distance to dispatch the nearest train could be made, would you use it ? or would you consider it make things too simple and it's evil ?

if such mod was to be very popular i think devs could and would have a look at the code,and the feedback the mod receive.

Also it would represent a change that some people may not like, and even make a mod to revert the change because they didn't like it and wanted more challenge:).

mods are greats ! if one such mod existed i wouldn't shame myself using it It would help convincing me that the air distance is a good approximation during fun practice, or the other way around, would get rid of that from the game and be a different challenge !

There are alternatives, i listed them because from your post it was unclear if you faced a problem and/or suggesting a solution.

There may be other similar suggestion from other person in the same situation but unaware of the alternatives, ( that are not as "simple"). The train limit is brand new

mmmPI wrote: Wed Dec 02, 2020 10:04 am If a mod that would use that air distance to dispatch the nearest train could be made, would you use it ? or would you consider it make things too simple and it's evil ?

Only if I wrote it myself

I've used LUA professionally, but the learning curve to mod myself is just to time consuming right now and I'm still hoping the devs will pick up on this - eventually.

Nilaus just commented on train limits. He sees it as a game changer for large scale train networks. And it could be. But everybody trying it will run into the same issues as stated in my OP.

(And now I'll shut up. I'm not trying to bump my post )

ralfoeldi wrote: Thu Dec 03, 2020 12:39 pm Nilaus just commented on train limits. He sees it as a game changer for large scale train networks. And it could be. But everybody trying it will run into the same issues as stated in my OP.

I don't run into those issues, I've got 247 trains on my network, the map is incredibly large, as well.

As long as you concentrate everything of one kind in one place you're fine. One block of iron smelters, one block that needs green circuits, one block that needs copper plates.

As soon as you place consumers of one item further apart, you'll run into the described problems. One use case would be to place smelters at the edge of your "civilized" areas in order to minimize rail traffic. My map has smelters north and south and as soon as all ore patches in the middle are empty (damm mining productivity 680%) no ore train should traverse the middle of the map. And right now - without some tricks - they do, i.e. decide to go from the northernmost mine to the southern smelters.

BTW: 304 Trains + you can get around the problem with a "honey-pot" station. Place a stacker + 4 red signals + station somewhere north and somewhere south. This prevents the trains from going all to far away unless they really have to. But... it's ugly.

Edit: Yes, seperating north and south into different "zones" would solve the problem, but then the system wouldn't be able to self regulate, i.e. move trains to where mines and smelters are.

ralfoeldi wrote: Thu Dec 03, 2020 4:45 pm As long as you concentrate everything of one kind in one place you're fine. One block of iron smelters, one block that needs green circuits, one block that needs copper plates.

As soon as you place consumers of one item further apart, you'll run into the described problems. One use case would be to place smelters at the edge of your "civilized" areas in order to minimize rail traffic. My map has smelters north and south and as soon as all ore patches in the middle are empty (damm mining productivity 680%) no ore train should traverse the middle of the map. And right now - without some tricks - they do, i.e. decide to go from the northernmost mine to the southern smelters.

no, i just don't design my network in a way that asks for it to be broken.

I have a single iron plate producer, I have a single steel producer, I have many stations to drop these items at, and I'm using long trains so that when the train arrives, it is in a stacker with 3 or 4 (or more) other trains all holding at least 100,000 of whatever item is required. sometimes more than 200,000.

so I don't care about latency, I care about throughput.

if you want North, South, East, West plate producers, you just need to set up the receiving station names so that they're "Iron Receiver West", and so on. then your West provider will only ever go to West receiver.

and if you want West to travel to East, you can have a backup receiver station that is enabled only when the main receiver is empty.

all that just to say your wish is unnecessary for the compute overhead it'll consume, it can be resolved with clever design.