Factorio Forums

Addendum to #p217256:

Of course train stops can't and shouldn't read the inventory of trains or their "own" inventory (i.e. those chests standing at the rails). They have to be connected to a network, and use the data from them. The train network shouldn't and needn't to be that smart to order a train with 137 iron plates... The player needs to be smart enough to use the train network effectively.

The train network only knows the signals "(station #...) needs item ..." / "(station #...) provides item ...", which will activate parking trains in "robot mode" or with a matching schedule wait condition for a train network signal. Trains stay almost stupid; they're going to a pickup station, then the drop station, and when their cargo is empty, they return to their parking stop. The player has to ensure, that the proper items and amounts are loaded.

Uffz. No long answer this time.

Yesterday morning I begun to make some drawings about what I think, the train-logistics should work. I wanted to present it.
Instead I found some flaws - things that we forgot.
For example: How many trains should be ordered? Sounds simple, but the problem is, that we need to limit the number of trains that fulfill a logistic-order. Of course I have some ideas...

The problem is: Now I need to make some of my drawing-sheets again... well, we'll see...

Do we need a limit?

It's up to the player to prevent requests for 1 single iron plate.
If it's requested a train will be sent to ship it.

It's also up to the player to make sure orders don't pile up.

How would a bot network with only 5 logistic bots handle more orders/min than it can fulfill?
That's basically the same problem. A lot of code from bots might be reusable for the train logistic network.

Optera wrote:It's up to the player to prevent requests for 1 single iron plate.
If it's requested a train will be sent to ship it.

No, you have a request if 100,000 iron-plates and a a provision of 100,000.
An order is created. Free trains will be searched to fulfill that.
Train1 is assigned and on the way to provider.
Train2 is assigned and on the way to provider.
Train3 is assigned and on the way to provider.
Train4 is assigned and on the way to provider.
Train5 is assigned and on the way to provider.
Train6 is assigned and on the way to provider.
Train1 arrives at provider.
Train7 is assigned and on the way to provider.
Train8 is assigned and on the way to provider.
Train9 is assigned and on the way to provider.
Train2 arrives at provider.
Train3 arrives at provider.
Train10 is assigned and on the way to provider.
Train11 is assigned and on the way to provider.
Chaos...

That's basically the same problem. A lot of code from bots might be reusable for the train logistic network.

With bots this is no problem, cause bots don't use any "space". Trains use a lot of space, if you order too much at once the result is ugly.

We need to estimate, how much trains can be handled per minute by the provider and requester. Which means:
Train1 is assigned and on the way to provider.
Train2 is assigned and on the way to provider.
Wait for statistics.
Train1 arrives at provider.
Time for filling is measured.
Train1 leaves, Train2 arrives at provider.
First statistics known.
Train3 is assigned and on the way to provider.
Train 2 leaves.
Train1 arrives at requester.
Train 3 arrives at provider.
Train1 leaves and immediately reassigned, goes to provider.
First complete statistics known.
Train4 is assigned and on the way to provider.
No more trains will be assigned, cause statistics calculates, that no more can be handled.

aober93 wrote:I dont like this, its just a workaround. Trains arent like robots. Robots carry 1 item, and they are all equal. Trains carry everything at once, or are pure copper/iron trains, have different length and setup. And if you apply the logistic robot flaws on trains you come to the conclusion that reaction times become a nightmare, while trains start to cluster. Good that robots dont deadlock, but trains do.

Thank you. I've been saying this all along.


Also think of this: A requester requests 100 iron plates, a provider provides 1000 iron plates. So a train is dispatched to fetch 100 iron plates, picks it up and delivers it. Now what happens?

The inserter unloads the wagon into a chest. Another inserter takes the item out of the chest and puts it onto a belt. Hey, now we need to request one more iron plate to get back to 100. The provider still has lots of iron plates. So a train is dispatched to fetch ONE iron plate. The second inserter takes another iron plate out of the chest and puts it on the belt. Hey, now we need to request one more iron plate to get back to 100. The provider still has lots of iron plates. So a train is dispatched to fetch ONE iron plate. ...

Consider the amount of extra circuit you need to requests items in batches and keep track of what got requested, delivered and used. Handle miscounts due to power loss or the player taking some items out of the chest (or from the belt) on the fly. 99.99% of users will end up with too many or too few items and deadlock.

Or will the request station handle this? In what size of batches will it request items? With trains you want them to be full but with request stations you want to request before you are empty. Those two objectives conflict. So either you run trains only half filled (didn't request enough) or only half emptied.(requested more than can be unloaded). The first will be horribly inefficient, the second will deadlock because left over items will collect and prevent the requested items to be loaded eventually.

The solution to this is to combine requests but then the complexity becomes exponential and way too much for the game to solve on the fly.

ssilk wrote: No, you have a request if 100,000 iron-plates and a a provision of 100,000.
An order is created. Free trains will be searched to fulfill that.
Train1 is assigned and on the way to provider.
Train2 is assigned and on the way to provider.
Train3 is assigned and on the way to provider.
Train4 is assigned and on the way to provider.
Train5 is assigned and on the way to provider.
Train6 is assigned and on the way to provider.
Train1 arrives at provider.
Train7 is assigned and on the way to provider.
Train8 is assigned and on the way to provider.
Train9 is assigned and on the way to provider.
Train2 arrives at provider.
Train3 arrives at provider.
Train10 is assigned and on the way to provider.
Train11 is assigned and on the way to provider.
Chaos...

Now I see where you're going.
To me this only happens with insufficient designed train network. Just as you can't expect one yellow belt to feed 100+ furnaces. If you need to transport 100k plates/min you simply need sufficient capacity. No system in Factorio is "one size fits all"-"place and forget" (well except solar power).
Sidenote: One 2L-6C-2L ships 24k plates at once. Shipments like that can keep 1rocket/0.5min bases running without problem.

We need to estimate, how much trains can be handled per minute by the provider and requester.

mrvn wrote: Also think of this: A requester requests 100 iron plates, a provider provides 1000 iron plates. So a train is dispatched to fetch 100 iron plates, picks it up and delivers it. Now what happens?

The inserter unloads the wagon into a chest. Another inserter takes the item out of the chest and puts it onto a belt. Hey, now we need to request one more iron plate to get back to 100. The provider still has lots of iron plates. So a train is dispatched to fetch ONE iron plate. The second inserter takes another iron plate out of the chest and puts it on the belt. Hey, now we need to request one more iron plate to get back to 100. The provider still has lots of iron plates. So a train is dispatched to fetch ONE iron plate. ...

Consider the amount of extra circuit you need to requests items in batches and keep track of what got requested, delivered and used. Handle miscounts due to power loss or the player taking some items out of the chest (or from the belt) on the fly. 99.99% of users will end up with too many or too few items and deadlock.

We shouldn't do that for the player. As said above, Factorio is fun to figure out and balance systems. The system just needs to offer possibilities for players to tune them to their needs.
Players need to make sure their station doesn't request 100k plates every half hour but instead 10k/3min. They also need to make sure it doesn't request a single plate (heck both need only 3 combinators, 2 if you use a bit black magic)

Or will the request station handle this? In what size of batches will it request items? With trains you want them to be full but with request stations you want to request before you are empty. Those two objectives conflict. So either you run trains only half filled (didn't request enough) or only half emptied.(requested more than can be unloaded). The first will be horribly inefficient, the second will deadlock because left over items will collect and prevent the requested items to be loaded eventually.

The solution to this is to combine requests but then the complexity becomes exponential and way too much for the game to solve on the fly.

Logistic Train network is about delivering on demand, not maximizing capacity. Those are different use scenarios, not conflicts in itself.
If you want to maximize train capacity have trains run on normal schedule, waiting at stations to be full. You will possibly have wasted more capacity with trains standing around.

I've finished my first working version of a proof of concept on how train logistics can work.
[Mod 0.14] Logistic Trains

That's what I always say: Code (mods) over suggestions. I looked a bit around and some of the solutions you made are so simple, that nobody would ever suggest it. I put my drawings waste paper.