Add Train-Logistics

[ssilk]

Sorry for doublepost.

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

Yes, indeed I think about rewriting this at weekend and also make new drawing.

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.

Well, see it so: If the system would be perfect it would not make much fun playing it. Really!
A player that tries this system the first time will come into that situation and he will find solutions of course, cause he is not silly (prove: you already explained some).

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.

It doesn't have a list. No Schedule. The schedule is dynamically created when a train get's it's order. Order is created, when a provider has the items, that a requester needs. The rest (filling with the right amounts, emptying...) is the players task.

Again: Provider provides an amount of item X, Requester requests amount of item X. Then order is created: Transport item X from Provider to Requester. A free train is assigned and gets this Schedule:
* Go To Provider, wait until minimum of either requested or provided items in.
* Go To Requester, wait until empty.
* Go To TrainPort and delete schedule.

You see: That logic is pretty simple.

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.

Well, that's the reason, why the train needs to wait until unloaded. It's the best of all compromises, cause the player will get time to solve the problems one after the other. I'm sure, this works much better as expected.

[MeduSalem]

It doesn't have a list. No Schedule. The schedule is dynamically created when a train get's it's order. Order is created, when a provider has the items, that a requester needs. The rest (filling with the right amounts, emptying...) is the players task.

Again: Provider provides an amount of item X, Requester requests amount of item X. Then order is created: Transport item X from Provider to Requester. A free train is assigned and gets this Schedule:
* Go To Provider, wait until minimum of either requested or provided items in.
* Go To Requester, wait until empty.
* Go To TrainPort and delete schedule.

You see: That logic is pretty simple. .

Ah I think that I get it now and why it might work out with a train waiting until empty (wasn't all that clear to me the first time around)...

So since the train would only pick up the amount that has been requested the train is pretty much almost guaranteed to be able to unload everything at the requester station... and with enough buffer space in the requester station you can guarantee that the train won't be stuck forever waiting to unload... and if a train would get stuck waiting then it was your own fault for requesting too much the station can't handle. So the train will basically always return empty to the depot.

To make majority of trains move around when they are filled to the brink instead of half empty you'd just set the request high enough to fill up the train wagons.
The only trains moving half empty etc are things like Repair/Construction trains... where only a small amount of items may be requested... but since that doesn't happen very often it's not really much of a problem if they move around half empty every once in a while.

That covers basically the transport and unloading.

But we also need to think about HOW to fill a train at the provider with the exact amount of items requested... that's actually not that easy to accomplish given that inserters themselves don't care about exact numbers. Or is where you would always be willing to abuse the Requester station's "me not care" attitude of taking everything, so that you don't have to put exact numbers into the trains at the provider? At requests with small quantities that might actually result in a nasty item scattering all around the map... like at every outpost there are abundance stacks of items that will never be needed because you dumped too many there, so you'd have to implement something like a "garbage collector" to get all the stuff that's lying around unnecessarily in outposts just because you couldn't deliver exact amounts in the first place.

A possible solution to the exact amount would be that inserters can't input more than what is actually requested no matter what, much like a hard cap, even if there'd be still space available in the train wagon to free the inserter hands... and then just depart the station. But that has the nasty side effect of leaving inserters stuck with residual items in their hands because they couldn't go beyond the cap.

A further thought I had on this is what if the train wagons were changed in a way that you can only put 12 different items into the wagon at a time... like having 12 stack groups with each stack group consisting of four stacks with the same items... and each of the 12 possible inserters placed around the wagon corresponds to one of these 12 stack groups. (Probably I'd need to make picture of that to describe better what I mean).



One thing the system has to take in consideration is the train configuration in terms of train length, how many locomotives, how many item/tanker wagons and in which order they are (especially if item/tanker wagons are mixed into the same train). But that imposes a little dilemma on how to decide that... because obviously the scheduler won't know how the train stations actually look like in terms of length and loading/unloading positions without explicitely telling it. The player will have to help there... and that's where I say that train names would still be necessary to differentiate between the trains and their capabilities. So you would have to give each train a name describing its configuration and you will have to tell each and every station which train configurations are actually able to approach it.



Also a suggestion about the priority... It could be a slider/number field in each station... with low numbers being low priority and the higher the number gets the higher the priority. So if there's a schedule created the algorithm will try to take from a provider with high priority first if possible rather than ones with low priority. Trainstops with equal numbers have an equal chance to be picked when creating a schedule. That way you can basically direct the priority in a very fine-grained fashion without having a lot of additional items.

You could also make an abstraction instead of numbers using "Ultra Low", "Very Low", "Low", "Medium", "High", "Very High", "Ultra High". But that's already implementation details.

[Optera]

But we also need to think about HOW to fill a train at the provider with the exact amount of items requested... that's actually not that easy to accomplish given that inserters themselves don't care about exact numbers. Or is where you would always be willing to abuse the Requester station's "me not care" attitude of taking everything, so that you don't have to put exact numbers into the trains at the provider? At requests with small quantities that might actually result in a nasty item scattering all around the map... like at every outpost there are abundance stacks of items that will never be needed because you dumped too many there, so you'd have to implement something like a "garbage collector" to get all the stuff that's lying around unnecessarily in outposts just because you couldn't deliver exact amounts in the first place.

A possible solution to the exact amount would be that inserters can't input more than what is actually requested no matter what, much like a hard cap, even if there'd be still space available in the train wagon to free the inserter hands... and then just depart the station. But that has the nasty side effect of leaving inserters stuck with residual items in their hands because they couldn't go beyond the cap.

That's why I, and from what i recall you too, urge for inserters to have controllable stack limits. It would make loading an exact number of items even without knowing how much is inside a wagon almost trivial. all you'd need is count the already picked up items, subtract that from the items requested and send that to the loading inserters.

A further thought I had on this is what if the train wagons were changed in a way that you can only put 12 different items into the wagon at a time... like having 12 stack groups with each stack group consisting of four stacks with the same items... and each of the 12 possible inserters placed around the wagon corresponds to one of these 12 stack groups. (Probably I'd need to make picture of that to describe better what I mean).

Maybe you should make a picture. It sounds like filters that span 4 slots instead of one to me.

One thing the system has to take in consideration is the train configuration in terms of train length, how many locomotives, how many item/tanker wagons and in which order they are (especially if item/tanker wagons are mixed into the same train). But that imposes a little dilemma on how to decide that... because obviously the scheduler won't know how the train stations actually look like in terms of length and loading/unloading positions without explicitely telling it. The player will have to help there... and that's where I say that train names would still be necessary to differentiate between the trains and their capabilities. So you would have to give each train a name describing its configuration and you will have to tell each and every station which train configurations are actually able to approach it.

The community seems to have settled on L - locomotive, C - cargo wagon. Perhaps expanded by F for fluid wagons.
A LCCCCL train is 1 locomotive at front, 4 cargo wagons, 1 locomotive at the end.

Also a suggestion about the priority... It could be a slider/number field in each station... with low numbers being low priority and the higher the number gets the higher the priority. So if there's a schedule created the algorithm will try to take from a provider with high priority first if possible rather than ones with low priority. Trainstops with equal numbers have an equal chance to be picked when creating a schedule. That way you can basically direct the priority in a very fine-grained fashion without having a lot of additional items.

You could also make an abstraction instead of numbers using "Ultra Low", "Very Low", "Low", "Medium", "High", "Very High", "Ultra High". But that's already implementation details.

I prefer numbers as priority over abstract names. You can assign the value to a virtual signal at the station. Lower numbers should have higher priority, so 1 will be served before 2.

[MeduSalem]

That's why I, and from what i recall you too, urge for inserters to have controllable stack limits. It would make loading an exact number of items even without knowing how much is inside a wagon almost trivial. all you'd need is count the already picked up items, subtract that from the items requested and send that to the loading inserters.

Yupp, I'm all for configurable stack sizes using the filter signals from the circuit network. With them the loading would be somewhat easier... though there is something I expect to cause some problems:

How would you get the signal with the requested items into the circuit network so that you can use it for the inserters?

Shall the provider station output a circuit network signal with the currently requested item and its quantity?

If so, then we can't hook up the contents of the trainstation chests to the provider station which would be necessary to indicate that there are actually items available for pick up since the signals would interfere.

Maybe you should make a picture. It sounds like filters that span 4 slots instead of one to me.

Yeah basically that would be it. Pretty much a filter that spans 4 slots, and there are 12 of these filtered slot groups. And each of the 12 possible Inserters around a cargo wagon would be dedicated to load/unload one of these groups.

Inserter 1 could only load/unload Group 1, Inserter 2 only load/unload Group 2, and so on...

Diagram1.png (27.46 KiB) Viewed 6855 times

Though there might be an upcry by people who want to put more than 12 different items into a cargo wagon, and also it makes the orientation of a trainstation a lot more important because an inserter wouldn't be able to grab an item from a group on the opposite site and vice versa. So you would have to remember where in the cargo wagon an item actually resides when loading/unloading. So I would understand if people wouldn't like that, but at least I thought about the possibility as a way to solve the problem with inserters getting stuck with a certain item.

The community seems to have settled on L - locomotive, C - cargo wagon. Perhaps expanded by F for fluid wagons.
A LCCCCL train is 1 locomotive at front, 4 cargo wagons, 1 locomotive at the end.

Seems reasonable...

I prefer numbers as priority over abstract names. You can assign the value to a virtual signal at the station. Lower numbers should have higher priority, so 1 will be served before 2.

Yeah why not, I would also prefer numbers because of the scalability... and I didn't even think about the possibility of dynamically changing the priority number with a virtual signal of the circuit network applied to the trainstation... that's actually quite an interesting idea.

If lower numbers have higher priority than higher ones or the other way around is a matter of taste and I have no real opinion on that. Also I'd expect people to be like "can't it be an option to reverse it?"

[Optera]

How would you get the signal with the requested items into the circuit network so that you can use it for the inserters?

Shall the provider station output a circuit network signal with the currently requested item and its quantity?

From what i gathered the simplification of ssilks idea is we don't need to run circuit network between each station and poll all requests and provided items like siggboy's complex version does.

Requests should be feed into the station and all stations in that network (we could use numeric a network id to have more than one) should get the request. the highest priority station with requested items would start calling a train to ship the request. Should it not complete the request the next station would call for a train.
Items inside a train would need to be subtracted from the request immediately when a station is calling for a train, or we'd end with a ton of excess shipments.

Yeah basically that would be it. Pretty much a filter that spans 4 slots, and there are 12 of these filtered slot groups. And each of the 12 possible Inserters around a cargo wagon would be dedicated to load/unload one of these groups.

Inserter 1 could only load/unload Group 1, Inserter 2 only load/unload Group 2, and so on...

Diagram1.png

Though there might be an upcry by people who want to put more than 12 different items into a cargo wagon, and also it makes the orientation of a trainstation a lot more important because an inserter wouldn't be able to grab an item from a group on the opposite site and vice versa. So you would have to remember where in the cargo wagon an item actually resides when loading/unloading. So I would understand if people wouldn't like that, but at least I thought about the possibility as a way to solve the problem with inserters getting stuck with a certain item.

For your idea to work train cars would need to be broken down from 1 big box to 12 boxes with 4 slots each.
What's the gain of complicating train car mechanics that much? You can do the same by manually setting filters and have the added benefit of stations being orientation independent.

[MeduSalem]

From what i gathered the simplification of ssilks idea is we don't need to run circuit network between each station and poll all requests and provided items like siggboy's complex version does.

Requests should be feed into the station and all stations in that network (we could use numeric a network id to have more than one) should get the request. the highest priority station with requested items would start calling a train to ship the request. Should it not complete the request the next station would call for a train.
Items inside a train would need to be subtracted from the request immediately when a station is calling for a train, or we'd end with a ton of excess shipments.

Well that's not what I meant... I know we don't have a circuit network running across the map, because that's one of the ugly downsides of siggboy's approach.

What I mean is... how do you control the inserters loading the items into the train? We established that the train would leave on its own when it has the amount of items that have been requested... but that wouldn't prevent the inserters from inserting MORE than what has been requested... and that's when you would also deliver more items than have been requested to the Requester Station.


Example:

Imagine a train as Construction train and you request let's say 20 Turrets because you build a defense for one of your outposts...

A train will go to a Provider station where there are Turrets available... and then a bunch of Stack inserters will insert AT LEAST 2x13 Turrets into the cargo wagon before the train would leave, but probably even more if you have multiple parallel Stack inserters feeding into the same cargo wagon. So you will deliver at least 26 Turrets to the outpost even it only requested 20 Turrets, just because the inserter stack size didn't match up with the actual request.


Well that doesn't matter much if the Requester Station has the buffer space available to take the excess... but still it would result in overcommitment. Do that again for several outposts and a lot of different items and you have a whole lot of items scattered all over the outposts you'll probably never really need there, just because you didn't load the correct amount of items in the train in the first place. It's something I would absolutely dismay because it means I have to do garbage collection eventually.

So we talked about that we could prevent that if we would adjust the inserter stacksize bonus dynamically to actually match what has been requested by calculating the difference between what has been requested and what's already inside the train... but how would you calculate this difference if you don't have a circuit network signal with the requested items?

As we established we don't want to run a circuit network wire all over the map... but we DO need the requested amount of items as a signal at the Provider station or otherwise the Inserters will behave nasty. So how do we get it without a wire running across the map?

For your idea to work train cars would need to be broken down from 1 big box to 12 boxes with 4 slots each.
What's the gain of complicating train car mechanics that much? You can do the same by manually setting filters and have the added benefit of stations being orientation independent.

The problem when loading a cargo wagon with multiple items from multiple inserters is that it might leave inserters stuck with an residual item in their hand once there is no more room left to drop the item to in the cargo wagon. The inserter can't drop it back to the chest/belt... and that's bad because it means the inserter can't be used for an other item type until it has freed its hand, which just doesn't happen until another train arrives that accepts these residual items.

siggboy's Smart Train approach has exactly that problem that he can't top off a train car because otherwise it would render the inserter stuck with wrong items in their hands, preventing a train from ever leaving the station because it might not be able to fill it with the requested items if all inserters are stuck with items they can't drop. So he had to implement an overly complicated procedure to make the inserters unstuck again by removing some items from the cargo wagon again so that each inserter is able to drop its residuals into the cargo wagon.

This problem is very prominent when using more than 12 different items in a cargo wagon... because you can only place 12 inserters around a parked cargo wagon, it means that when all 12 are stuck with an item they can't drop then you can't insert the 13th or 14th item type of your request anymore = train stuck forever.

So the point of my suggestion of dividing a train car into 12 boxes was that with my suggestion it wouldn't be a problem if an inserter gets stuck with an item they can't drop because each inserter is dedicated to one of the 12 boxes. If one box is full and the corresponding inserter stuck it doesn't interfere with whatever the other 11 boxes/inserters are doing. You don't have to make it unstuck.

[Optera]

I posted a link to various smart loader designs earlier.
Some work with filters, some work without, some with mods. All have in common that they load either count perfect or one stack size less than requested.
Those prove that even with current fixed stack sizes it's possible to load any number of items in train cars. If we get inventory of train cars and set able stack size it'd become almost a no brainer.

Even without smart loader, delivering a little bit over request is exactly how logistic network currently works. Bots will deliver their stack size to a requester. if you request 1 roboport in a chest bots will deliver 4 (been playing with modded stack size for bots for a while now so i dont know the exact vanilla values).

The way I see it that overcommitment is perfectly in line with the way the game plays.
You can have a simple delivery which just works but has overhead, or go full OCD and combinator crazy, build smart loader to make sure there's not one single item delivered too much.

I don't like changing a game mechanic just as workaround to the real problems of A) not knowing how much is inside a train car and B) not being able to set the amount inserters pick up from chests.
If you touch mechanics anyway, why not add a smart rail able to read inventory of the train car currently on top of it or something that truly solves the problem?

[aober93]

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.

Its a workaround for bad gameplay. The game has no train manager, but only a simple train view where every train looks the same. Anno 1701's ship manager is better than this. Train lines for example would ease managment. So would visual improvements. There can be done so much ,without changing the inner mechanic.

For example ,have trains that are carrying nothing for a while be marked. This easy change would help so much at once. Like show a non working train line ,and empty outposts, and destroyed train lines, nonworking signals, deadlocks.

[ssilk]

That post from aober93 is so negative, that I don't comment it.


@Medusalem & Optera: I really like your input.

Some thoughts about how to control the inserters:

- How to fill the trains? Well, I'm not 100% sure yet, but I think there should be a circuit (from the train-stop?), that contains the requested number of items minus the already loaded. That would enable to control the inserter by circuits: If the signal of that item goes below 1 then stop inserting. You can make it much more complex of course, but I think this isn't needed. See below...

- I think it is useless to persist on exact loading. This is much different than inserters or bots. Train stations are eventually minutes away (I have a map, where a train takes, hm, 6 or 7 minutes with full speed). I mean: When the train leaves the loaded numbers might be correct, but during travel everything changes. That was also the basic idea to say "Well, it doesn't matter if I have 1000 electric circuits or 1001. It even doesn't matter if I have 10 or 20 repair-packs. It's good enough. Problems appear, when you transport expensive items, but that is not useful to transport with trains.

- The second idea was, that it makes sense to have always a requester and a provider in an outpost. That can be used to bring the overcommitment back or bring it to other outposts. This is no must, the player will come himself to this idea.

- I thought also how supermarkets are delivered, so that they don't need to be closed cause of overcommitment with too much articles. The supermarket in my neighborhood gets every Saturday the new bargain advertising articles. During the week the articles are sold. At some supermarkets an article is sold more often than in others. That can never be calculated so exactly, that in each supermarket all articles are sold at Friday evening; so when the next weekend comes, they take the overcommitment (the old articles) from one supermarket to another. What I mean is: The bigger the factory grows, the more it doesn't matter how much exactly you deliver, cause a good infrastructure will balance the things out...

- To fluid tanks: I don't know how to handle that yet. My idea was, that this doesn't matter with the first implementation and can be solved later. But of course liquids needs to be handled completely different. Possible solutions: Reintroduce "filters" again (for fluid wagons) or have different train-networks... I think the train-networks are a good idea.

- To different train-layouts: Nearly the same. I thought with the first implementation we just need to have equal train design for all logistic-trains. Solution: different train-logistic-networks?

- Handling the different train layout in one station is alone the players task: If he wants 5 different types of trains to be loaded at one station, well, nice task, but not a problem for this suggestion.

- Only 12 different items per wagon? I find it quite cumbersome to even think abouthaving more. It takes minutes (!) to configure that. It is not useful to have more articles. In my opinion you need some providers, not only one..

- The idea with the filter slot groups: Worth testing. But I feel this is too "fixed" and we don't know, if something like this is really needed.

- Avoid overcommitment: Will not be avoided, instead my idea is, that each outpost has a also a provider where you can put in the overcommitments. And the trees. Stones, that are in the way. And when we are at that: coal, iron, copper, anything. No must, but why else should you build an outpost: You want to deliver things that you produce in thar outpost. And delivery means production and production means you need also consumption; no production without consumption. So the circle closes: It makes sense to create outposts with request- and provider-train-stops.

- Inserters stuck with items in their hands: Well, that item is then put into the next train, that comes. The item might then be delivered to the wrong target. But as explained: It's not so a problem, if you transport the wrong delivery back. If your creation works perfect, you even wouldn't recognize that.


Did I forgot some point?

[MeduSalem]

I don't like changing a game mechanic just as workaround to the real problems of A) not knowing how much is inside a train car and B) not being able to set the amount inserters pick up from chests.
If you touch mechanics anyway, why not add a smart rail able to read inventory of the train car currently on top of it or something that truly solves the problem?

Well good, that could also be a viable way to deal with the problem... if one would know what's already inside each individual cargo wagon with some kind of sensor then one could use that information to control the inserters in front of that particular cargo wagon better.

If I remember right there exists a mod for that kind of sensor? Maybe it should be included into the concept.

But you would still require a signal with the actual amount of requested items or otherwise you couldn't calculate the difference and when to stop.

But at least I like it better than my own suggestion of changing the cargo wagons themselves.

Some thoughts about how to control the inserters:

- How to fill the trains? Well, I'm not 100% sure yet, but I think there should be a circuit (from the train-stop?), that contains the requested number of items minus the already loaded. That would enable to control the inserter by circuits: If the signal of that item goes below 1 then stop inserting. You can make it much more complex of course, but I think this isn't needed. See below...

Well I thought also about the possibility that the trainstop outputs the difference itself... that would fix the problem entirely as well and is in my opinion the first choice on how to do it.

- I think it is useless to persist on exact loading. This is much different than inserters or bots. Train stations are eventually minutes away (I have a map, where a train takes, hm, 6 or 7 minutes with full speed). I mean: When the train leaves the loaded numbers might be correct, but during travel everything changes. That was also the basic idea to say "Well, it doesn't matter if I have 1000 electric circuits or 1001. It even doesn't matter if I have 10 or 20 repair-packs. It's good enough. Problems appear, when you transport expensive items, but that is not useful to transport with trains.

- Avoid overcommitment: Will not be avoided, instead my idea is, that each outpost has a also a provider where you can put in the overcommitments. And the trees. Stones, that are in the way. And when we are at that: coal, iron, copper, anything. No must, but why else should you build an outpost: You want to deliver things that you produce in thar outpost. And delivery means production and production means you need also consumption; no production without consumption. So the circle closes: It makes sense to create outposts with request- and provider-train-stops.

True, I didn't think about the possibility that the requested amount of items might change before the train actually arrives. If there are excess items they could bridge the gap if the requested amount is rising after the train has already departed. Then no other train would be necessary, though the scheduler would have to keep track on how much of each item the train has loaded currently so that it doesn't issue another train as long as there are enough excess items in the train that's already on the way.

I guess that might be worth considering when thinking about exact item numbers, but it would still be a quality of life improvement to somehow access the requested amount of items... either the way Optera suggested using Sensors underneath each Cargo Wagon (=fine grained solution) or your solution that the trainstop outputs the difference between requested items and items already inside the train (= coarse solution). Both would work well in their own way.

With "expensive items" I guess you mean ones that you can only have 5 per stack and so on?

- The second idea was, that it makes sense to have always a requester and a provider in an outpost. That can be used to bring the overcommitment back or bring it to other outposts. This is no must, the player will come himself to this idea.

Well you convinced me. An outpost will always need both because why do we have outposts... basically to gather resources and they have to be transported back to the base. But Biters don't like mining outposts so they attack it and things need to be repaired or replaced so you will have to request Repairpacks or the items that have been destroyed. So you need both... at least a loading and unloading platform (though it can be combined).

So basically if an outpost has too much or doesn't need certain items anymore then a train could pick it up and bring it back to the main base or to other outposts. That would require some priority management that can be adjusted dynamically like Optera and I suggested... so that the scheduler will consider picking up these excess items from the outposts over the picking up items from the main base... otherwise it would become tricky.

- I thought also how supermarkets are delivered, so that they don't need to be closed cause of overcommitment with too much articles. The supermarket in my neighborhood gets every Saturday the new bargain advertising articles. During the week the articles are sold. At some supermarkets an article is sold more often than in others. That can never be calculated so exactly, that in each supermarket all articles are sold at Friday evening; so when the next weekend comes, they take the overcommitment (the old articles) from one supermarket to another. What I mean is: The bigger the factory grows, the more it doesn't matter how much exactly you deliver, cause a good infrastructure will balance the things out...

... yeah until the infrastructure collapses in itself because the system is trying to balance itself out all the time. Such balancing systems grow exponentially with the amount of nodes and edges involved. xD

- To fluid tanks: I don't know how to handle that yet. My idea was, that this doesn't matter with the first implementation and can be solved later. But of course liquids needs to be handled completely different. Possible solutions: Reintroduce "filters" again (for fluid wagons) or have different train-networks... I think the train-networks are a good idea.

- To different train-layouts: Nearly the same. I thought with the first implementation we just need to have equal train design for all logistic-trains. Solution: different train-logistic-networks?

It needs to be solved right on the spot, ssilk. There are already various problems in the game that would require additional work because it hasn't been considered in advance or because the "can be done later"-attitude won and then they never got to sorting out all that mess because other stuff got in the way. I mean really... tanker wagons couldn't be used in your system at all at the beginning... and that's just half-assed (sorry but I don't know of a better way to say it).

So train networks would basically be an abstraction of Optera's and my idea of having Train Names for various configurations as far as I guess?

So you would create a train network with a name, like for example "Fluids"... and then put a train on the track with locomotives and tanker wagons... then go inside the train menu and you'd assign the train to the "Fluid" train network. And each train station where fluids can be loaded/unloaded you'd assign these stations to the "Fluid" train network?

It's basically the same as Optera and I already wrote.

- Handling the different train layout in one station is alone the players task: If he wants 5 different types of trains to be loaded at one station, well, nice task, but not a problem for this suggestion.

Yeah, if you attached the train station to a particular train network then you obviously know that trains belonging to that train network can be served by the station and you need to prepare the station in such a way.

- Only 12 different items per wagon? I find it quite cumbersome to even think abouthaving more. It takes minutes (!) to configure that. It is not useful to have more articles. In my opinion you need some providers, not only one..

- The idea with the filter slot groups: Worth testing. But I feel this is too "fixed" and we don't know, if something like this is really needed.

Yeah, well forget about that idea. If sensors to measure the cargo wagon contents would be a thing, or if the train station would output the difference between what has been requested and what's already inside the train that would be enough to control the inserters.

- Inserters stuck with items in their hands: Well, that item is then put into the next train, that comes. The item might then be delivered to the wrong target. But as explained: It's not so a problem, if you transport the wrong delivery back. If your creation works perfect, you even wouldn't recognize that.

You know that perfectionist people would never be able to stand the possibility of an item going down the wrong route because it has been inserted into the wrong train because the inserter couldn't get rid of the item from the previous train?

I am one of them... I would notice such things.

But the problem would be solved if the trainstation outputs the difference between what's inside the train already and what has been requested as a circuit network signal. Then you'd use that circuit network signal and stop the inserters from loading too much... It would be nice if the inserter stack size could be set from the circuit network signal for that to work even better.

[Optera]

If I remember right there exists a mod for that kind of sensor? Maybe it should be included into the concept.

Look at my signature
I wrote Inventory Sensor for the very reason of loading my trains with exactly the requested number of items.

- I thought also how supermarkets are delivered, so that they don't need to be closed cause of overcommitment with too much articles. The supermarket in my neighborhood gets every Saturday the new bargain advertising articles. During the week the articles are sold. At some supermarkets an article is sold more often than in others. That can never be calculated so exactly, that in each supermarket all articles are sold at Friday evening; so when the next weekend comes, they take the overcommitment (the old articles) from one supermarket to another. What I mean is: The bigger the factory grows, the more it doesn't matter how much exactly you deliver, cause a good infrastructure will balance the things out...

I just have to correct you on this.
Supermarket delivery, at least in Austria, is a complex data model I do not want in a game.
Every sell with at least time, item, price, eventual discounts for every store is stored in a data warehouse. Using Big data mining you can calculate demand from that very precisely.
Supermarkets also never ship back to the depot, they put close to expired items on sale, give them to charity or simply trash them.

As MeduSalem said, shipping excess items back to depot without precise control over item loading size or other precautions will very likely cause a lockdown circle where tiny amounts of items are constantly delivered back and forth.

[MeduSalem]

If I remember right there exists a mod for that kind of sensor? Maybe it should be included into the concept.

Look at my signature
I wrote Inventory Sensor for the very reason of loading my trains with exactly the requested number of items.

Just embarassing that I didn't look at the signature until now...

Supermarket delivery, at least in Austria, is a complex data model I do not want in a game.

Ahhh... someone else from Austria? Almost thought I was alone here.

[Factoruser]

- There shouldn't be additional types of train stops, *maybe* an engine shed...

A train stop might be set to the modes passive, requesting, providing and parking, where you specify an item type - and trains. Requests are lists of minmum items in the connected networks in combination with a train name. One train name per item, if the item count drops below the minimum, all trains with that name are getting activated. Providing train stops are listing items they provide if the minimum count is reached in the network. In contrast to the requesting mode they are not assigned to trains. The parking mode is to park a train, which can be named or for any train.

Trains will then have 3 radio buttons: schedule, manual and automatic. The new automatic trains are assigned to up to 5 item types and might get an order for one of these item types by the train network. Then they visit the next train stop in providing mode and proceed to the requesting train stop. Perhaps you may specify conditions, perhaps it only stands at the providing station for 10 seconds and waits at the destination until its cargo is empty. After this, the automatic train checks if there is still a request signal, otherwise it's going back to its/a parking spot.

The requesting station may also activate scheduled trains - and disable them. There might be a new condition "until activation" - that's more simple than using ABC-signals... The train will stay then that long at the train stop until the train network sends an activation signal.

[Optera]

I'll try to put together what this idea would need to work.

Trains
add network in station list, no wait condition needed

Train stops
additional fields:

• train network as integer
• priority as integer

from circuit network:

• provided items could be as simplistic as connecting the chests at the station
• requested items would need a new entity that reads requests from the logistic network it's placed in or a 3rd mode for roboports.

to circuit network:

• requested items in train network

I struggle finding sensible ways to send requested and provided item lists to a train station and also output requested items from the train network. It'd need color coded wiring or 3 connections at the station. All options are a big mess of wires.
We probably also need a depot, so trains don't stand at their drop off stations, blocking further shipments there. Priority 0 could indicate the depot(s) in the network.

Logic

• get free train from depot
• send train to pick up items from provider marking items as being delivered
• make the highest priority shipment
• return to depot

Loading/unloading is entirely up to the player to build.

[ssilk]

That list is quite nice, as a software-developer I would say, this is near to be ready for development.

I struggle finding sensible ways to send requested and provided item lists to a train station and also output requested items from the train network. It'd need color coded wiring or 3 connections at the station. All options are a big mess of wires.

Had the same issue here.
We need the number of requested items at the providing train-station (I don't write train-stop) at the moment when an ordered train (see definitions above and below, what that means) comes to that station. [for the requesting side I think we have everything what is really needed available]

If you see that like that, the solution is simple: The order is done, when two stops found (provider and requester) that match with the needed and provided items. [An order is just the two train-stops, no numbers of items are involved here. The order is assigned to a train. Even here no number of items involved. The order can also change (suddenly the requesting station needs also another item for example), or it can be cancelled, if no order needed anymore.]
The point of this thought is: The train is the right entity to "know" the numbers of the requested items for HIS REQUESTING STOP [because the next train that comes could have completely different item-numbers, cause he will deliver on another request-stop] and because of that only it could provide the needed items (minus already shipped) to the provider station (not stop) as a signal.
The rest is simple: Signal is forwarded to the inserters, inserter stop, if signal is lower 1. Or whatever.
What I mean is: Only the train knows this, cause we need an entity, that knows what is the target-train-stop (what is the order)?

We probably also need a depot, so trains don't stand at their drop off stations, blocking further shipments there. Priority 0 could indicate the depot(s) in the network.

Not 100% understanding. We have the train-ports. A logistic-automated train, that has no order should drive automatically to the next port!?

Logic

• get free train from depot
• send train to pick up items from provider marking items as being delivered
• make the highest priority shipment
• return to depot

Ah, the depot is the train-port! Well, it's just how we name it.

[Optera]

Had the same issue here.
We need the number of requested items at the providing train-station (I don't write train-stop) at the moment when an ordered train (see definitions above and below, what that means) comes to that station. [for the requesting side I think we have everything what is really needed available]

Train Stations could be increased to a 2x3 footprint to hold 3 constant combinator like entities for all the connections. Similar to how smarterTrains stacks one constant combinator and a light in the stops.
A red one for provided input, blue for requested from station input, yellow as requested from train network output.
From your post it sounds though as if you have new entities in mind that read/write into the train network? It would need additional checks to link which station is requesting/providing what. Only reading the total requested items per network id could easily be made it's own entity.

If you see that like that, the solution is simple: The order is done, when two stops found (provider and requester) that match with the needed and provided items. [An order is just the two train-stops, no numbers of items are involved here. The order is assigned to a train. Even here no number of items involved. The order can also change (suddenly the requesting station needs also another item for example), or it can be cancelled, if no order needed anymore.]
The point of this thought is: The train is the right entity to "know" the numbers of the requested items for HIS REQUESTING STOP [because the next train that comes could have completely different item-numbers, cause he will deliver on another request-stop] and because of that only it could provide the needed items (minus already shipped) to the provider station (not stop) as a signal.
The rest is simple: Signal is forwarded to the inserters, inserter stop, if signal is lower 1. Or whatever.
What I mean is: Only the train knows this, cause we need an entity, that knows what is the target-train-stop (what is the order)?

To me it made no difference if the train or the network keeps track of what items are currently being delivered.
As the network itself needs to dispatch trains it'd be easier to store items being delivered in that central place.

There may also be not a single station providing the full delivery. In such cases the order would have to be split and 2 or more trains pick up the items from various providers.

Not 100% understanding. We have the train-ports. A logistic-automated train, that has no order should drive automatically to the next port!?

TTD always called them depots.
I'd like to see the next free train nearest to the provider get the order, but it'd be much easier to have orders only dispatched to trains waiting in depot.

[MeduSalem]

I would say that the train stops should have both an Input (Write) and Output (Read) Port that can be used for Circuit Network Logic. (much like Combinators or Power Switches have both an input and output)

The Input Port would be basically used to tell the Train Network either the requested Items (at Requester Station), or the provided Items (at Provider Station)... just by connecting them to the chests or a constant combinator for example.

The Output Port would be used to read the current request for the current train in the station. That means that if the train halts at a Provider Station the output port could ouput the difference between what's already inside the train and the actually requested items for this train... and that signal could be used to stop the inserters from overloading the train.
The signal would also be available at the Requester Station once the train arrives in the station but it's basically redundant if the train unloads everything anyways... but if it outputs the current train's contents it could also be used to unload only certain items... which might be worth some further thought if and how that could be turned into an useful feature. It could allow for a scheduler to create more complex train deliveries... with multiple Provider Stations and multiple Requester stations all served by the same train in one tour, if that's technically feasable and doesn't turn into some nasty optimization problem.


As far as the depots go... I think that there should be basically be a radio button inside the train stop that says "Provider", "Requester", "Depot"... though if it really has to be then they could be seperate items much like the logistic chests.

So there wouldn't be any new items necessary... and a size-change of the trainstop wouldn't be necessary either because it is already 2x2... which is enough to provide an Input and Output port for Circuit Network connections on its sprite.

[Optera]

Setting stations to either request or provide seems needlessly restrictive to me.
What about the oil barrel station? It requests empty barrels and provides filled barrels. Building a dedicated providing and requesting station seems redundant.

Active Requests inside the train network should always be available in case someone wants to make a factory work on demand.
The more i think about it the more I believe it should be a separate constant combinator providing the active requests. We can place it down next to a production line to control a power switch. Similar to what you can do with launch control or robot army status reading combinators.

This would leave only the two inputs (provided at this station/requested at this station) for the train stop, fitting nicely into the 2x2 footprint.

[ssilk]

I try to answer to all points.

- Request signal at the provider-station AND provider signal at the request-station: The first is ok and needed, but why should we need the providing signal at the request-station? What numbers would you like to see at the requester in that moment? Why? The train has taken the items and is now at the requester stop. Why would you need to see the provided items from that stop now? Yes: Another train will come and bring the provided items, but not yet in this train.

- Provider-train-stops send needed signals of request-train-stop (2x3 footprint and similar...): The problem is: WHEN should the stop send this?
Of course, when the train holds at that stop. This sounds simple, but is not logical! Cause when exactly? The player suddenly stops the train and put it in manual mode? And then? Or there is a read signal in front of the train-stop. Does the train-stop send the signal yet or not?
Train-stops are not the right entity to send that signal.

- Why not train-stops? Train-stops (not stations) know nothing about the logistic-order of a train. They don't know, what train comes to them - and much uglier: They even don't know, that a train stopped at them at all.

- The "right way" to send the item-number of request-stop: Only the train knows his destination. He can directly select the target train-stop and read the circuit-input from that stop there and provide that numbers minus the real inventory of the train as "published inventory" of the train.

Well, the truth is, that it's a bit more complex.
- One train: the currently needed items (the number of items that should be delivered) is: requested_items - items_already_loaded_into_the_train.
- Two trains with the same logistic-order: When train one is full then train two needs to pick up: requested_items - items_loaded_in_train_1 - items_already_loaded_into_train_2
- For N trains with the same logistic-order: The current number of items to be loaded is: requested_items - sum(all_items_loaded_into_all_trains_of_same_order)

In other words: Trains of the same logistic-order build some kind of "virtual circuit network" and provide a "pseudo-inventory": the number of requested items minus currently transported items in all trains of this logistic-order. (*)

- And how can I read that "pseudo-inventory" from the train? We need an entity that reads the inventory signal from the train. Uhhhh... Difficult.... Hmmmm.... I remember, there is a mod - It scans the inventory of any device around. I forgot the name of the Author, something like "Opera".
Just kidding... https://mods.factorio.com/mods/Optera/I ... y%20Sensor .... Something like that.
Such a device in-game would be also quite useful for other things. There is a bunch if suggestions about reading inventory from train wagons...
There are some more suggestions around this kind of sensor, cause for some jobs (especially loading) it is really useful to have something like that. (I need to add this to the required items for this suggestion.)

- Another circuit network-color? The current circuits are more or less fixed to red and green wire only. An third color doesn't make anything better.

- Only reading the total requested items per network id could easily be made it's own entity. What should that be useful for?

- A logistic-automated train, that has no order should drive automatically to the next port!?
Nearly. It's the same as with the robots: You can let any bot free at any point and he will fly to the next roboport (if in the network is nothing to do). If the train is under logistic-automation there is the same kind of automatic: You place a train, mode is switched to logistic-automation. Train will send a request for logistic-orders to the train-logstic-system. Train-logistic doesn't find any order, so it gives the train the schedule to drive to train-port (and shut up. )

- Depots? TTD always called them depots. It's just a name, but "depot" is for me a bit different: A depot can be used to automatically create new trains, if needed. Insert locos, wagons and coal in and a "plan" of the train-layout and if triggered somehow it will produce a new train.

- Different entities or GUI-selection for the functionality of train-stop? I would let this question completely open, cause it doesn't change the game-value.

- Oil barrel stations? I thought we will become liquid wagons? And if you want to load and unload at the same station: I think it is too soon to think about this. I think logistic-train is not really useful with this kind of task. And there are too many questiosn´


(*) I know, sending the number of items via "pseudo-inventory" is not 100% clean. But any other solution has more flaws (in my opinion). I can also not be sure, but I think we can let this open: If this will be really implemented, a good solution will be found and finding a better yet goes too deep..

[Optera]

Tonight I couldn't stop thinking about the Dispatcher logic.
First off you are right, only trains know how much they have in inventory and it should be trains providing picking up and delivering lists.
Trains running in logistic mode should dynamically set filters along with stack limit. Not only makes it easier to load items, but also can players see what trains are up to.

For this example we have a Furnace Station and an Electronic Circuit Station.
Our train is a single L-C carrying max of 4k plates.
EC Station requests 5k copper plates and 2010 iron plates.
Furnace Station has 3k plates of each.

dispatcher:

• send order {3k copper plate, 1k iron plate} to train; --We aim to serve the highest demand first
• set train filter to 30 slots copper plate 10 slots iron plate; --read the stack sizes from prototypes
• train is now in status pickup {3k copper plate, 1k iron plate}
• pickup is subtracted from request
• on furnace station it may read the item list from train status and load it accordingly or load with one chest>inserter per provided item
• once inventory >= pickup, status will change to delivering inventory and train will go to EC Station
• on EC Station all is unloaded, train status delivering is cancelled
• once empty the train returns to depot
• in depot train deletes it's filters -- make sure the train doesn't accidentally picks up items from the request station

Here's where we have to start arguing about whether to wait for our furnaces to produce the full next shipment or immediately start picking up the next one. for simplicity's sake I assume our furnaces are fast enough to have another 3k each ready.

• send order {2k copper plate,1010 iron plate}
• set train filter to 20 slots copper plate, 11 slots iron plate, 9 stack limit
• train is now in status pickup {2k copper plate, 1010 iron plate} --EC Station reads pickup being delivered
• pickup is subtracted from request
• on furnace station it may read the item list from train status and load it accordingly or load with one chest>inserter per provided item
• once inventory >= pickup, status will change to delivering inventory and train will go to EC Station --EC Station reads inventory being delivered
  Inventory with a chest>inserter per provided item loading setup will be 2k copper plate 1100 iron plate (rounded up to next full stack)
• on EC Station all is unloaded, train status delivering is cancelled
• once empty the train returns to depot
• in depot train deletes it's filters

Subtracting a train's pickup/delivering status from request, while storing the request in dispatcher until it's complete makes it inherently robust against trains being picked up/destroyed while shipping. The request would simply go back up and the next train would run the shipment.

- Why not train-stops? Train-stops (not stations) know nothing about the logistic-order of a train. They don't know, what train comes to them - and much uglier: They even don't know, that a train stopped at them at all.

I don't know what you try to say by discerning between stop and station.
Train stops would be the logical unit to write request/provided item lists to the train logistik network as well as read what shipments are incoming.
Stops do know when trains are parked, that's why they we can already send circuit network signals to trains through it.

- Request signal at the provider-station AND provider signal at the request-station: The first is ok and needed, but why should we need the providing signal at the request-station? What numbers would you like to see at the requester in that moment? Why? The train has taken the items and is now at the requester stop. Why would you need to see the provided items from that stop now? Yes: Another train will come and bring the provided items, but not yet in this train.

-request signal can be read from parked train, it's useful for more complex smarter loading logic
-being delivered signal sent to the station putting out the request is highly optional for feedback about their delivery status. Some surprisingly smart applications might pop up by providing such information.

- And how can I read that "pseudo-inventory" from the train? We need an entity that reads the inventory signal from the train. Uhhhh... Difficult.... Hmmmm.... I remember, there is a mod - It scans the inventory of any device around. I forgot the name of the Author, something like "Opera".
Just kidding... https://mods.factorio.com/mods/Optera/I ... y%20Sensor .... Something like that.
Such a device in-game would be also quite useful for other things. There is a bunch if suggestions about reading inventory from train wagons...
There are some more suggestions around this kind of sensor, cause for some jobs (especially loading) it is really useful to have something like that. (I need to add this to the required items for this suggestion.)
- Only reading the total requested items per network id could easily be made it's own entity. What should that be useful for?

-Do we need an entity to read the virtual inventory of all logistic network trains? I cant really think of an application where i need to know everything that's inside all trains. What may be useful is what's currently being delivered to a specific station.
-an entity reading total request would make it easy to produce on demand in spread bases. In above example the furnaces would read the 5k copper demand an could start producing before the train picks up the first 3k partial shipment.
-a sensor reading contents of each wagon would be much appreciated, but I think i with dynamic filters it can work without it.