Add Train-Logistics

[ssilk]

Trains are currently not able to fulfill complex logistic requests. That has been discussed many times now. Many ideas like to control the train-stops (turning them on/off - some threads are going around this), train-routes (where you can set a train onto a route that it shares with many others ad if you change the route you change the route for all the other trains, too) and much more.

My current idea is this: Introduce train-logistics.

Similarity to the Logistic-System (with robots)
Logistics for the robots works currently so, that the logistic-system looks for the requested and provided items and creates orders out of that. The orders are in a order queue. The orders are then assigned to a free robots.
Train-logistics should work similar. First I show my bad drawings-talent:

IMG_1675.jpg (1023.41 KiB) Viewed 19980 times

Well, this is not the Yellow submarine. The truth is: It's just really ugly. But I think it is good enough. Indeed it's the 3rd version of this idea. So I will explain this picture from top to down and left to right.

Requester-train-stop
This is just another type of train-stop. It's able to read the request-signals from a circuit and forward them into the train-logistics (which is not visible in this picture, cause it's something virtual - you can compare it with the logistic network). The signals are then taken as "item-request for this train stop", just like a requester chest does this in a logistic network.

Request-Combinator
A new type of combinator, which is able to read all current open requests (from requester chests) in this logistic network, including the requests from ghosts, that have no item to be built. A request is in that case positive, a surplus (provider chests/storage chests) is negative. That is useful, if you want to have default number of items:
You can add a constant combinator to add some default requests, like "this network should have always 100 repair packs available". The constant combinator sends +100 repair-packs, and that is signaled to the Requester-train-stop until the Request-Combinator sends a signal of -100 repair packs which is added 0 (which means, there are no requestes any more).

Provider-train-stop
Like the requester-train-stop this train-stop is able to read the providing-signal from a circuit network and forwards it into the train-logistics as "offer". In this case the offer is just the summed up content of the chests that can fill the wagons.
If there is both - a request and an offer - the train-logistic will queue a train-order.

Train-Ports
That is just another type of train-stop. Trains without order will wait here for new orders. Each train-port can be set to one or more items - that works like a filter: Only trains, that are able to transport exactly the same item-types as specified in the train-port can be directed by the train-logistics to such a train-port.

Wagons and Locomotive
A train can receive orders from the train-logistics. How? I think to a third position of the manual/auto-switch: train-logistics (or it is a special locomotive or the loco is equipped with a special train-logistics-module). In that case the schedule of such a train cannot be controlled by the player, it is controlled by the train-logistics only (when turned into automatic mode).

The wagons need not to be special, but the player needs to set a filter on each stack in the wagon! (A better interface for setting up many filters is a prerequisite for this, there are already mods, that can do this.)


Step by step
So, assumed a requester-train-stop requests 100 repair-packs and a provider-train-stop, that provides that packs. As said this would create an order in a queue.
For this order the train-logistic will now search a train, that is able to transport that order of 100 repair-packs.

It searches therefore all train-ports for repair-pack-filters. If found it searches for trains, that are on the way to that train-port or are waiting in front of it (a bit more complex than this). One of that trains is then given a new schedule: Drive to the Provider-train-stop, that provides the repair packs and wait, until minimum 100 repair are loaded into the train (or wait 2; then drive to the Requester-train-stop and unload the repair-packs or wait some seconds; then drive to the matching Train-port and delete this schedule.

Edit: I just want to mention here, that if a train has it's order and will be filled, with the needed item, the number of filled items are subtracted from the current request of the requester station. This is just exactly as with the logistic network currently.

Wagon-Filters define their purpose?
I think I need to explain this need for filtering a bit deeper.
The problem is, that if a train would be able to transport any kind of item is, that we need a fourth kind of train-stop: A storage-train-stop. A train needs to drive to this train-stop, if he has finished his order, but meanwhile the requesting train-stop doesn't need so much items anymore (for whatever reason). In this case we need to unload the remaining items somehow, cause if we would not do that, the wagons could contain more and more garbage and the train-logistic would fail.

So why not adding such a type of station? Cause that is not fun. I can say that, cause I have made some tests with quite big train-systems and there is no added fun, if you always make sure that the non-empty trains will empty.

It is also much more interesting, if you need to think about how many trains of each type you need and this slight difference to the logistic network enables players to understand the usages of storage chests etc. much better than yet.

So if you want to transport iron ore you need to set up a train with any length and set all wagons stack-filters to iron-ore. The train then can only transport iron-ore.
If you want to have a supply-train, you can set up the wagons so, that the filters include repair-packs, walls, ammo, lasers etc. etc.

What is with the train-stations? How are the trains filled/cleared then?
That is the problem of the player.

Filling: Add (requester-)chests for each type of item and insert them into that train until full.
Clearing: Takes out the requested items until empty or number of requested items is requests is reached (smart inserters).

This suggestion enables only basic operations: Creating dynamic schedules between train-stops by fulfilling requests.

For more clever operations there is much headroom from improvements. For example: Circuit network could be enabled to read the order of the current train (how much items should he bring?). That would enable to fill the train only to the needed values.

And then?
I think it would also be possible to have "multi-purpose-trains". Trains, that don't need to be fixed to some item-types by setting the filters of the wagons. But that is just a very different story and before that can be thought about the simple version (this suggestion) should work.

[mrvn]

Moved this post from viewtopic.php?f=6&t=34174 conditional train stops, cause there it was off-topic. -- ssilk

That is the question. The wanted target could be reached with some different approaches.
Me for example think, that a train should not be controlled by the train-stops. There are different ideas like having "routes" for this.

I made some kind of counter-suggestion: viewtopic.php?f=6&t=34225 Add Train-Logistics

I don't like that idea. It works badly for robots and you have thousands of them. With just a handfull of trains you will get flooded with requests and the AI will never figure out a good order to visit trainstops to fullfill them all. It will be inefficient as hell if it works at all. Also no way to set priorities and way to much to implement in the code.

If you can use combinators to the set the trains next stop(s) then it's up to you to implement the logic and make it efficient. I think that has to be the end goal.
My suggestion is just to tie us over till then.

[ssilk]

Hm. I don't know why you think it works bad for robots. Robots aren't involved into this suggestion, if you don't want; you can use this suggestion completely without robots.
The point is not to fulfill requests, it fulfills orders.
A request-station requests X iron ore. A provider station provides some iron ore. In that case an order is made. An order is: Bring iron from A to B. It searches then a train, that can transport iron (cause the filters of the wagons are set to iron). It creates a schedule for that train: Go to A, wait until X iron filled or more than Y seconds gone. Go to B and wait until empty or Z seconds gone. Go to a port station that matches your wagon filters and clear the schedule then.

If you can use combinators to the set the trains next stop(s) then it's up to you to implement the logic and make it efficient.

As it is now.

I think that has to be the end goal. My suggestion is just to tie us over till then.

Good point.

[mrvn]

Hm. I don't know why you think it works bad for robots. Robots aren't involved into this suggestion, if you don't want; you can use this suggestion completely without robots.
The point is not to fulfill requests, it fulfills orders.
A request-station requests X iron ore. A provider station provides some iron ore. In that case an order is made. An order is: Bring iron from A to B. It searches then a train, that can transport iron (cause the filters of the wagons are set to iron). It creates a schedule for that train: Go to A, wait until X iron filled or more than Y seconds gone. Go to B and wait until empty or Z seconds gone. Go to a port station that matches your wagon filters and clear the schedule then.

If you can use combinators to the set the trains next stop(s) then it's up to you to implement the logic and make it efficient.

As it is now.

I think that has to be the end goal. My suggestion is just to tie us over till then.

Good point.

I mentioned the robots because that is what the logistic robots do. They are your train idea without the rails. And there I'm sitting right next to a distant roboport waiting for some iron ore, of which I have 30k in the system available for minutes with 5000 logistic robots idle. Then when I give up and walk to where the iron ore is suddenly 200 logistic robots come out of the roboport next to the iron plates, pick them up, fly 2 tiles and give them to me. And so on.

In your example you say the train goes to A, picks up the iron and then goes to B to deliver. But hey, between A and B there is C where it can pick up some copper plates and drop them of at D along the way. It might also take a little detour to E to pick up some batteries which F requested 50 tiles further down the road.
Instead your train will go A, B, 300 tiles to turn around, C, 1000 tiles to turn around, D, 500 tiles to turn around, E, 700 tiles to turn around, F. Logistic robots can only carry one item at a time so they have to go A, B, C, D, E, F. Possibly with multiple robots. But trains carry a lot of items and fullfilling orders in parallel with the same train will be crucial and basically impossible to solve by the game engine. Not so by the human mind and then you can encode that solution into combinators.

[Nemoricus]

I like the idea of logistics trains. The only thing I'd like to add is the idea of telling the whole train that it's an iron train, or a copper plate train, or an electric/advanced circuit train. Setting each stack filter in every wagon sounds like it would be very tedious.

[ssilk]

I mentioned the robots because that is what the logistic robots do. They are your train idea without the rails. And there I'm sitting right next to a distant roboport waiting for some iron ore, of which I have 30k in the system available for minutes with 5000 logistic robots idle. Then when I give up and walk to where the iron ore is suddenly 200 logistic robots come out of the roboport next to the iron plates, pick them up, fly 2 tiles and give them to me. And so on.

Not relevant here, cause you obviously use it wrong. That is a different thing; I would like to help - if I can - but here it is off-topic...

On the other hand: The comparison itself (Trains are the new bots) is right:
- Trains wait in the port for orders.
- A train is picked for order, if it is waiting at a station [or "on the way" back to the port (and still able to change his direction)]

In your example you say the train goes to A, picks up the iron and then goes to B to deliver. But hey, between A and B there is C where it can pick up some copper plates and drop them of at D along the way.

Yes, I know. But I tell you a reason, why this should not be implemented yet: Because it is a mathematical problem of a class, that is not easy to solve; while the suggested idea is really easy to solve (and already solved).

If that works, you can make it more complex. That is how good software is developed.

trains carry a lot of items and fullfilling orders in parallel with the same train will be crucial and basically impossible to solve by the game engine. Not so by the human mind and then you can encode that solution into combinators.

You can do that, when you program your trains, yes.

This suggestion is:
Go to A (because train is able to transport needed items), pick up Items (no logic involved, player is responsible for that), go to B and unload what's needed (also player is responsible).

This is good for:
- Construction-trains.
Want to create a new outpost and now need 500 electric furnace? Create request station, place first roboports, some bots and then place blueprints. If you have enough construction-trains they will all come.
- Supply-trains.
Bad biters beat boring boilers in your outpost? Well: One requester station sees request of missing boiler and/or repair packs and request is generated to fill that up.
- Material-trains:
Think of specialized trains, that are able to transport any kind of ore and much more of it than normal wagons. They can pick up ore from the stations and bring it to a sorter-station, where the different ores are sorted into the different directions.

And finally:
The distances in Factorio are just too small compared to the waiting times, that this is really relevant. I playtested such things really many hundred hours: It is much faster and many times easier handling, to have two trains, to transport item Z from B to A and Y from A to B, then X from C to D and W from D to C, or make circles A->B->C->D...), instead of doing nested transport... that will make things really complex, needless complex.
You can do such things with the already existing train system. This suggestion is to make tedious work like supply of outposts easier. Or to create automated ore transport.

I like the idea of logistics trains. The only thing I'd like to add is the idea of telling the whole train that it's an iron train, or a copper plate train, or an electric/advanced circuit train. Setting each stack filter in every wagon sounds like it would be very tedious.

Yes, I know, I mentioned this above; there is an old mod. Would also be super-useful, if built into vanilla: viewtopic.php?f=92&t=17199

[Optera]

This concept seems identical with siggboy's Smart dynamic train deliveries with combinator Magick [0.13] to me.
It would be great if this would be a bit simpler to build and doesn't need mods.

[ssilk]

Lot of similarities. But also some differences. But of course, some of the ideas come from there. But all in all I found it too complicated on the long term to be a solution for game. I removed all the complex stuff and the arbitrariness of the trains.

[Optera]

Makes sense. Sigboy's creation, while most impressive, is nothing I'd want to run on a big map.
Biters may chew away some signal lines, it's not as flexible as a simple logistic requester chest.

Rather than setting filters to trains to designate their purpose, I'd use the train name. (all locos on a train should be renamed to one name for this)
When using filters you'd need to know what will be transported. A maintenance train, which should only be loaded with whatever was destroyed and requested from an outpost wouldn't work without reserving space for stuff not requested.

[mrvn]

I mentioned the robots because that is what the logistic robots do. They are your train idea without the rails. And there I'm sitting right next to a distant roboport waiting for some iron ore, of which I have 30k in the system available for minutes with 5000 logistic robots idle. Then when I give up and walk to where the iron ore is suddenly 200 logistic robots come out of the roboport next to the iron plates, pick them up, fly 2 tiles and give them to me. And so on.

Not relevant here, cause you obviously use it wrong. That is a different thing; I would like to help - if I can - but here it is off-topic...

Tell me more (private message?). I don't see how else they could be used any other way.

On the other hand: The comparison itself (Trains are the new bots) is right:
- Trains wait in the port for orders.
- A train is picked for order, if it is waiting at a station [or "on the way" back to the port (and still able to change his direction)]

In your example you say the train goes to A, picks up the iron and then goes to B to deliver. But hey, between A and B there is C where it can pick up some copper plates and drop them of at D along the way.

Yes, I know. But I tell you a reason, why this should not be implemented yet: Because it is a mathematical problem of a class, that is not easy to solve; while the suggested idea is really easy to solve (and already solved).

If that works, you can make it more complex. That is how good software is developed.

trains carry a lot of items and fullfilling orders in parallel with the same train will be crucial and basically impossible to solve by the game engine. Not so by the human mind and then you can encode that solution into combinators.

You can do that, when you program your trains, yes.

This suggestion is:
Go to A (because train is able to transport needed items), pick up Items (no logic involved, player is responsible for that), go to B and unload what's needed (also player is responsible).

This is good for:
- Construction-trains.
Want to create a new outpost and now need 500 electric furnace? Create request station, place first roboports, some bots and then place blueprints. If you have enough construction-trains they will all come.
- Supply-trains.
Bad biters beat boring boilers in your outpost? Well: One requester station sees request of missing boiler and/or repair packs and request is generated to fill that up.
- Material-trains:
Think of specialized trains, that are able to transport any kind of ore and much more of it than normal wagons. They can pick up ore from the stations and bring it to a sorter-station, where the different ores are sorted into the different directions.

And finally:
The distances in Factorio are just too small compared to the waiting times, that this is really relevant. I playtested such things really many hundred hours: It is much faster and many times easier handling, to have two trains, to transport item Z from B to A and Y from A to B, then X from C to D and W from D to C, or make circles A->B->C->D...), instead of doing nested transport... that will make things really complex, needless complex.
You can do such things with the already existing train system. This suggestion is to make tedious work like supply of outposts easier. Or to create automated ore transport.

It will be horribly bad for constructing new outpost because you need:
1) belts
2) undergound belts
3) splitters
4) power poles
5) miners
6) assemblers
7) 7 kinds of inserters
8) combnators and wires

And for each and every type of item your train would have to drive back and forth once. Distances in factorio might be small but if it has to go 30 times back and forth instead of going straight once you will notice painfully.

Same with the circle. Your automatic trains will go once around the circle per item type while any sane person would have it load and uload on every station while going around. As both of us said doing this automatically is a mathematical problem to hard to solve algorithmically. You want to be able to program the solution you come up with in your head into the network. So since we both agree the code can't solve the problem algorithmically why should we even go in that direction?

Material-trains? That exactly would not work with your idea. The train you build to carry iron ore and just iron ore would reach the train station, see that someone requested 1 assembler and go drive a 100000 tile journey to pick one up and deliver it. Meanwhile you have no iron ore. As I mentioned before you didn't include priorities in your idea. So you can't say that iron requests take precedence or must have at least one train fullfilling it at any time.

[ssilk]

A maintenance train, which should only be loaded with whatever was destroyed and requested from an outpost wouldn't work without reserving space for stuff not requested.

Exactly, you need some different trains.
What do you need, if you want to construct a new outpost: Belts, pipes, assemblies, inserters of all types... many things. In my experience it is useful to have different trains, for example a train only for all the types of inserters, two or more trains just for belts, poles, solar panels, accumulator...
I found two extremes:
- one multipurpose-train": Each train can transport for example 24 different items-types, but only some stacks of each type. Useful for supply of any kind.
- specialized trains: Each train transports only one item-type. Useful for ore-transport for example.

That needs to be set up by the player and that is also some kind of interesting puzzle/decision the player needs to make and your gameplay is totally influenced by that.

Rather than setting filters to trains to designate their purpose, I'd use the train name.

This is a good idea. On the other hand it was the reason why I had choose the filters, cause you won't have train names like
"Electric-circuits, iron-wheels, ... list of 20 more items .... "

When using filters you'd need to know what will be transported.

Yes. I see and know, that this is a bit complex complex. Simple mechanism: for each type of train you need to configure a train-port. That could be also the other way around: You crate first a port-station and then copy the setting of that train-port to trains. This will set the filters in the wagons to the items, that the train-port is configured (you can adjust the number of stacks afterwards).

A maintenance train, which should only be loaded with whatever was destroyed and requested from an outpost wouldn't work without reserving space for stuff not requested.

Good point, that is a situation I was some times in my playtesting and this is ugly. But with the solution above this would be simple: Just create a new train, copy from train-port, paste into train, finished.


-------

It will be horribly bad for constructing new outpost because you need:
1) belts
2) undergound belts
3) splitters
4) power poles
5) miners
6) assemblers
7) 7 kinds of inserters
8) combnators and wires
And for each and every type of item your train would have to drive back and forth once.

No!
You can define a train or some trains with all that needed items (see above!). For example: One train which transports belts, one with inserters and poles, one with miners, assemblies etc.
Again: This is done by setting the filters in the wagons: A train transports only those items you have defined!

Now if you need belts in your outpost, the train logistic orders all trains, that are able to transport belts (of that type), until you have enough in that outpost.

This guarantees quite fast supply, and yes, many trains need to bring the stuff, but this is also the fun with this: Your complete train logistic gets stressed to it's limits and you will begin to build better rails, faster station load/unload, optimize filter-combinations etc.

Your setup of a new outpost is just this: Place a requester-station, connect a constant-combinator and request stuff like poles, rails, roboports etc. Then connect to the rest of your train-network and supply with power: In that moment the first trains will be ordered.
Of course they cannot leave the station in that moment, but they will come and wait and you can pick out the items you need. The rest is up to the player. Many possibilities to continue from here.

Same with the circle. Your automatic trains will go once around the circle per item type while any sane person would have it load and uload on every station while going around.

You cannot define a circle with train-logistics as described here. It's always a two-way-connection. I mentioned that just as an example.

So since we both agree the code can't solve the problem algorithmically why should we even go in that direction?

I didn't. I mentioned several times, this is not, the way this suggestions goes to. This suggestion keeps simple and I mentioned the mathematical difficulties to explain the reason for that.

Material-trains? That exactly would not work with your idea. The train you build to carry iron ore and just iron ore would reach the train station, see that someone requested 1 assembler and go drive a 100000 tile journey to pick one up and deliver it. Meanwhile you have no iron ore. As I mentioned before you didn't include priorities in your idea. So you can't say that iron requests take precedence or must have at least one train fullfilling it at any time.

Just: No.

... I see, this needs some more explanation. I'll try to make some pics this week from a working map, that does similar stuff.

[Optera]

A maintenance train, which should only be loaded with whatever was destroyed and requested from an outpost wouldn't work without reserving space for stuff not requested.

Exactly, you need some different trains.
What do you need, if you want to construct a new outpost: Belts, pipes, assemblies, inserters of all types... many things. In my experience it is useful to have different trains, for example a train only for all the types of inserters, two or more trains just for belts, poles, solar panels, accumulator...
I found two extremes:
- one multipurpose-train": Each train can transport for example 24 different items-types, but only some stacks of each type. Useful for supply of any kind.
- specialized trains: Each train transports only one item-type. Useful for ore-transport for example.

That needs to be set up by the player and that is also some kind of interesting puzzle/decision the player needs to make and your gameplay is totally influenced by that.

Basically your idea boils down to having trains designated to ship only predetermined cargo?
Using static filters will make something as simple as a train transporting oil barrels to an outpost and full barrels back only 50% efficient.
I think that idea is too restrictive. It should offer the option to use multi purpose trains.

Rather than setting filters to trains to designate their purpose, I'd use the train name.

This is a good idea. On the other hand it was the reason why I had choose the filters, cause you won't have train names like
"Electric-circuits, iron-wheels, ... list of 20 more items .... "

Except for ore and oil trains, I wouldn't name trains by their cargo but their purpose.
In my current game with a centralized base I have named specialized construction/supply trains. FARL, Solar, Mining Outpost, Oil Outpost, Supply (for bots, repair packs, turrets, ammo, walls, ...).

With a decentralized base where most things have to be shipped all over the place, dedicated trains become less efficient the more cargo types there are to ship around.

[ssilk]

Using static filters will make something as simple as a train transporting oil barrels to an outpost and full barrels back only 50% efficient.

Yes. But you can run much more trains, if they are a little bit more "automated" than yet.

I think that idea is too restrictive. It should offer the option to use multi purpose trains.

I tested similar setups and found them - hmmm - quite complex. The reason are
- Inserters: you will have a problem with loading/unloading, that gets really complex, if a train can transport anything.
- if not all items in the wagons could be unloaded at the target: That problem is similar to logistic bots and already explained in OP. For the bots the items are then moveed into storage chests. With trains now we would need a fourth type of train-stop (a storage-stop), where the non-empty trains would be completely unloaded if needed. I've tested similar setups, and that is really not useful, cause it makes things useless complex.

But on the other hand: Multipurpose-trains works for the ores for example: You can run trains, that transport all kinds of ores to a sorter station (request-stop is the sorter, provider are the ore-outposts). It doesn't work, if you could load any item-type, cause of the missing storage-stop.

Maybe, with improved loading/unloading mechanisms this is eventually much easier. But this suggestion doesn't introduce train-logistics AND new load/unload-mechanism! It just suggests only train-logistics and with that I can say from testing, that the items-filters make thinks much easier. (I think it enables also to implement this suggestion as mod.)

[Optera]

Using static filters will make something as simple as a train transporting oil barrels to an outpost and full barrels back only 50% efficient.

Yes. But you can run much more trains, if they are a little bit more "automated" than yet.

I think that idea is too restrictive. It should offer the option to use multi purpose trains.

I tested similar setups and found them - hmmm - quite complex. The reason are
- Inserters: you will have a problem with loading/unloading, that gets really complex, if a train can transport anything.
- if not all items in the wagons could be unloaded at the target: That problem is similar to logistic bots and already explained in OP. For the bots the items are then moveed into storage chests. With trains now we would need a fourth type of train-stop (a storage-stop), where the non-empty trains would be completely unloaded if needed. I've tested similar setups, and that is really not useful, cause it makes things useless complex.

But on the other hand: Multipurpose-trains works for the ores for example: You can run trains, that transport all kinds of ores to a sorter station (request-stop is the sorter, provider are the ore-outposts). It doesn't work, if you could load any item-type, cause of the missing storage-stop.

Maybe, with improved loading/unloading mechanisms this is eventually much easier. But this suggestion doesn't introduce train-logistics AND new load/unload-mechanism! It just suggests only train-logistics and with that I can say from testing, that the items-filters make thinks much easier. (I think it enables also to implement this suggestion as mod.)

Running trains mostly empty goes against my TTD OCD.
As suggested for a while now, smart/filter inserter should move only the set number of items. Send iron plate 4 to them and they will only move 4 plates from chest to wagon regardless of stack bonus.
Together with another requested feature reporting back how many items currently are inside each wagon that easily makes it a no problem to ship only what's requested.

Even with the current vanilla game it's possible to create smart loaders that put only x items inside a wagon without filters. Sadly they have to clean out the wagon of all items about to be loaded first unless you use a mod like my inventory sensor.

[ssilk]

Running trains mostly empty goes against my TTD OCD.

Let's explain it so: If you have more than 50 trains, it is quite difficult to keep (more or less) organized. I found for that setup no better way, than to let your trains run more or less empty. Otherwise, if you intermix the trains with the different stations, so that they are take optimized routes, you become soon a complete chaos.

What I want to say: Yes, it is possible and much more useful to implement trains, that are not fixed to items. But that would be a suggestion, that could not be implemented in one step; this suggestion explains, how to add a simple way of implementing train-logistics and it enables also to add all the features, that you (and me) would like later.

And - what I think I forgot to say - this suggestion is not thought to run less than 20 or 30 trains. It makes no sense to use train-logistics with just 10 trains. Same problem as with logistic network with only 10 bots.
This is also, because the setup/design for train-stations is a bit different to the current railways.

As suggested for a while now, smart/filter inserter should move only the set number of items. Send iron plate 4 to them and they will only move 4 plates from chest to wagon regardless of stack bonus.
Together with another requested feature reporting back how many items currently are inside each wagon that easily makes it a no problem to ship only what's requested.

Hm. The number of items is not the problem. The problem is, that you need a much more useful mechanism (I don't know if improving inserters is the right way) to
a) fill in requested items-types into a wagon without blocking and
b) take out requested items-types from the wagons without blocking
and this as fast as possible. Currently to make this simple and reliable if you want 12 different item-types filled into the wagon, then you need 12 inserters. There are workarounds, but they are really complex.



Off-topic:
I have some ideas into that direction: viewtopic.php?f=80&t=19343 Boxing / Packaging / Container / Cargobox : Pre-Filling
So: Instead of filling the wagons with the right stuff you fill boxes with the needed item-combinations. And that would close the gap, cause then you have
- trains, that can handle only defined sets of item-types
- ports, where only those trains can wait, that are of the same set of item-types and then
- boxes, that contain only the item-types, that a train (and port) can handle.

If we can define such "sets of item-types" somewhere and have that definition always available we can define perhaps 4 or 5 of such sets and a new trains just needs to be assigned to one of that sets.

EDIT: In that case we can remove the need for the filters and indeed define "multipurpose trains" and "multipurpose train-ports". But we need to take care to "clean" the wagons from time to time, but that kind of action could be done also at any provider station then, cause all you need to do then is to unpack and repack the left item-boxes in the wagons.

[MeduSalem]

That sounds like an interesting topic for once...

I really like the basic idea ssilk...

... that said there are some obvious flaws in it that would need to be ironed out, some of which have been mentioned already.


Having to set filters in ALL the train wagons slots to make it work is just really, really, REALLY ugly. No average player would dare to do that, even less care to understand why it has to be like that. What they want is convenience. So you need to find a better way around that problem, but I don't see a way how to do it.

I mean the problem we are facing here is... Macromanagement vs Micromanagement. You are basically trying to implement a very global/general system with the goal of solving a lot of dedicated special cases. That's like trying to seperate flyshit from pepper while wearing boxing gloves... If you manage to achieve that you deserve a medal.

Trains carrying only one item type is obviously not a real choice for each situation (especially in case of repair/construction trains etc).

My next idea was... what if a wagon can only be filled by one item type, that would require the player to set only one filter per train wagon and for multipurpose trains have a wagon dedicated wagon for each item you want... which would make things easier already, but I already know what a lot of people are going to say about that: "HELL NO! YOU ARE NOT TAKING AWAY MY MULTIPURPOSE WAGONS!" ... and they are right because it would be quite inefficient to drive around with a lot of empty train wagons or ones that are filled to the brink with Inserters when in reality you only need 10 or something. So basically I don't think it can be done this way either.

So then we have multiple different items per wagon again... and that's where the shit hits the fan. We can't control that in a decent way currently, except using mods and siggboy's Smart Train System, which is pretty much overkill for average players.

Your approach of setting filter slots is not really any easier than that... a lot of tedious clicking work for something that should be straight forward.


Another thing that hasn't been mentioned here yet is... what about fluids? When the tanker wagons become available it would become an even more spectacular mess because I assume in a tanker wagon you won't even be able to specify a filter in the first place.


It should be as simple as a train going from a Provider station to a Requester station and if it is not needed then back to a depot. You set the amount of items available in the provider station and you set the amount requested in the requester station. You shouldn't even have to touch the train itself other than to put it on the track and maybe give it a name.


Maybe an alternative inspired by Optera's suggestion of using names would be... you set up the train for a purpose and give it a name... like "Construction Train"... and in Provider Trainstops you add "Construction Train" to the list... and in Requester Trainstops you do the same. Then if both a Provider Trainstop AND a Requester Trainstop are being marked as active (for example Requester Station is lacking 100 Walls it is marked as active, Provider Station has >100 walls available so it is marked as active too) at the same time a train from the depot with the name "Construction Train" will come to pick up items from the provider trainstop and deliver it to the requester trainstop. Most of the time the requester trainstop will be inactive because the demand at the station will be met, so the Construction Train will head back to the depot.

In that case it wouldn't matter if the train isn't empty when returning to the depot, but it might cause problems when loading the train at the provider station... which then would require some kind of sensor to determine the actual contents of the train before starting to load (like the Trainstop outputting the current contents of the train at the station) to prevent inserters from getting stuck with the wrong items in their hands. That or just deal with the fact that you can only savely have 12 different items in each wagon due to how you can only place 12 individual inserters around the wagon so you don't have to give a damn about if a inserter is stuck with a particular item because it's dedicated to move that particular item anyways. The later of which is how I'm doing things because it is reliable for god's sake because it doesn't need any combinator contraptions at all.

But that's basically identical to having a train with a Route "Provider Station"->"Requester Station"->"Depot" ... and deactivating both the Provider and Requester stations to force the train to stay at the depot until both are active again and then choose the first idle train from the namelist and assign the job while the other idle trains with the same name stay idle at the depot. (It's basically siggboys implementation just without the nasty circuit network wire running across the entire map because the game would do the job queue and handling of active/idle trains for you).

The next logical step would be... Deactivating trainstops via circuit network? That should actually be enough to deal with the entire problem in the first place... because then trains will wait at the Provider stations until a requester station becomes available... if done right then only one train will going to the station at a time.

[ssilk]

It should be as simple as a train going from a Provider station to a Requester station and if it is not needed then back to a depot. You set the amount of items available in the provider station and you set the amount requested in the requester station. You shouldn't even have to touch the train itself other than to put it on the track and maybe give it a name.

Yeah, exactly. That would be also my dream.

And you showed me, that my thoughts till now are all correct.

Well, your post inspired me a lot and I got a new idea:

What if a requester station takes all, no matter if it needs it or not. The train does not leave from the requester, until it is empty!!

This is possible, cause - unlike the robots - the train does not need power, when waiting, and you have not only one chest, but many for unloading.

The point of this is: That would clear the wagons at the requesting stop. Which would enable multipurpose trains, cause of the need to have always empty trains (cause otherwise the math becomes too complex). It works in the same way as adding storage-stops, that clears the wagons.

It makes everything much easier:
- no complicated logic at requester-stop needed: All inserters just take everything out as fast as possible.
- no cleaning (at storage-stops or at the train-ports) needed.
- Just create train, no setup for trains.
- Just create requester-stations, no special setup needed, just make sure you take out everything.
- Still simple setup for provider-stations.
- No more setup of wagon filter, no need to setup items in ports. You just need to make sure, that all trains in that system have the same layout.

But.... what is with the over-supplied items at the requesting station?
Simple: They can be sorted out into a new provider station, if needed. Or you bring them "home" otherwise. Or you live with the overflow, cause you will need it later...
Basic problem fixed.

Eventually we need then "Active Provider", "Passive Provider", "Active Requester" and "Passive Requester"!
Force trains to load from Active Provider stops first (instead Passive Provider) and bring items to a Passive Requester only, if they are in an Active Providers and not needed by an Active Requester.
That would enable to clear that kind of "overflow" efficiently.

[Optera]

It should be as simple as a train going from a Provider station to a Requester station and if it is not needed then back to a depot. You set the amount of items available in the provider station and you set the amount requested in the requester station. You shouldn't even have to touch the train itself other than to put it on the track and maybe give it a name.

Yeah, exactly. That would be also my dream.

And you showed me, that my thoughts till now are all correct.

Well, your post inspired me a lot and I got a new idea:

What if a requester station takes all, no matter if it needs it or not. The train does not leave from the requester, until it is empty!!

This is possible, cause - unlike the robots - the train does not need power, when waiting, and you have not only one chest, but many for unloading.

The point of this is: That would enable multipurpose trains in the same way as adding storage-stops. It makes everything much easier:
- no complicated logic at requester-stop needed: All inserters just take everything out.
- no cleaning at some kind of storage-stop or at the train-ports needed.

And what is with the over-supplied items at the requesting station? Simple: They can be sorted out into a new provider station, if needed.

Basic problem fixed.

Eventually we need then "Active Provider", "Passive Provider", "Active Requester" and "Passive Requester"!
Force trains to load from Active Provider stops first (instead Passive Provider) and bring items to a Passive Requester only, if they are in an Active Providers and not needed by an Active Requester.
That would enable to clear that kind of "overflow" efficiently.

No more setup of wagon filter, no need to setup items in ports. You just need to make sure, that all trains in that system have the same layout.

I like that a lot more. It's easier to set up, more flexible and introduces a whole lot of managment issues as it grows more complex.

A requester taking all of a requested type is also how bot networks work. Requester chest requests 4 items, bot cargo size is 5 so 5 will be delivered. Only when the requester can't hold the excess item will bots carry them back to storage chests.
I still don't see a problem in filling trains with an exact number of items though. Perhaps I've spent too many hours constructing smart loader and smart furnaces by now.

Making it too similar to logistic network with active/passive provider might be a bad idea. Bots are great for delivering tiny amounts to infinite close locations, trains are great at delivering large amounts to few locations over great distances.
Imagine a station filtering out 5 items and immediately requesting pickup instead of waiting for the provider to fill up to make a train shipment somewhat reasonable.
Active Providers should only call a train when a configurable threshold is reached, while passive providers should be checked if any single one holds enough for the request so it can be done in one shipment. I'm now going to test if bots do this check.

For trains a combined requester/provider stops would make sense. Simple example again request 1k empty barrels, provide 1k filled barrels. It wouldn't make much sense for 2 trains doing the round trip.

[MeduSalem]

Well you will have to make another of that "pretty" drawings of yours to explain that to me, ssilk...


By the way if a train waits at the requester until it is empty... that's going to be problematic if another requester station needs also resources. If all trains are waiting somewhere then a trainstation might starve to death... else you need exactly as many trains as there are requester stations. If you just have one to many it causes traffic jam because the one that's too much will end up in queue behind a train that is waiting to unload at a requester station. If you have one too less then somewhere a station starves. Also it wouldn't guarantee that 2 or more trains aren't heading for the same requester... so eventually they might all end up hogging one requester station, while all others are starving.

So bottomline... that doesn't work reliable. A requester station that doesn't need any resources should deactivate itself and be taken out of the list of available target stations to prevent above from happening. Meaning... your trains can't wait there... because once the train station is offline the train will head for the next station in its list.

Which then obviously is the provider station if you don't have a depot. But then all the trains that aren't needed anymore will start hogging the provider stations again which is with multiple outposts providing resources a problem because all the trains might want to go for the same provider and not equally distributed among all outposts... it's a vicious cycle... that can only be broken if there's a depot scheduled after leaving a requester and making trains wait there until BOTH a requester station and a free provider station is available and dispatch only one train for each request.

siggboy basically demonstrated that problem in his Smart Trains thread... and hence why his smart train thingy is the way it is to prevent all that mess.

[ssilk]

Making it too similar to logistic network with active/passive provider might be a bad idea.

Good point. It should look similar to robot-logistics, but not too similar.
Let's rename "active" to "pritority" and "passive" to nothing. So we would have "Priority Provider Train-Stop", "Provider Train-Stop", "Priority Requester Train-Stop" and "Requester Train-Stop"...
Ok, that's still too similar.

Imagine a station filtering out 5 items and immediately requesting pickup instead of waiting for the provider to fill up to make a train shipment somewhat reasonable.
Active Providers should only call a train when a configurable threshold is reached, while passive providers should be checked if any single one holds enough for the request so it can be done in one shipment. I'm now going to test if bots do this check.

I think most of that can be handled with circuits. I think it is a good idea, to keep as much hidden logic as possible outside.
Threshold for example: Item-count is compared with a value, signal goes only through if item-count is larger.
Check: Hm. That might be too difficult after a 10 hour working-day.

For trains a combined requester/provider stops would make sense. Simple example again request 1k empty barrels, provide 1k filled barrels. It wouldn't make much sense for 2 trains doing the round trip.

Hmmm. I need to think this through, cause I think, this could change everything. A simple "pickup" mechanism is really useful, but it complicates things in this first step. I see such clever routing as step 2.