Stations & other LTN based designs

[eduran]

I am an LTN novice. I got my initial stations going, and I am happily receiving my trains empty at the depot thanks to a simple design to load only as much as was requested.

For safety, my initial design only made the provider available when its chests were at least half full, and the requests where only made when there as at least space for half a chest. But... it bugs me that the trains don't travel full, increasing rail network congestion.

So I am toying with the idea of using two sets of chests, with a balancer between them, and to only request when the chests next to the train are empty. That would ensure a full chest set of buffer, while making all trains to travel fill and ensures space to fully unload.

QUESTION: Other than being a bit wasteful of space, are there any negatives to this approach?

It sounds like you are not using provide and request thresholds. Set the "provide stack threshold" on the provider to the size of the largest train you would like to use (number of wagons * 40 for vanilla trains). Do the same for requester stations and "request stack threshold". Now LTN will only dispatch trains if (a) the provider has enough items to fill a train and (b) the requester has enough space to unload a full train.

[phi1010]

Known Bugs: A cable is missing, see

this post for a patch

for the blueprint below.

----

A provider station allowing all items from a logistic network being requested over long distances via LTN.

0eNrtXWuO2zYQvkqhn4WVkhSfCzQnaNKi6b8iMLQ2d1eoLbmSvO0i8AF6kF6sJylpef2gRImkHxvX/ZOFbOsTOd/McDjDUb5E97OlXJRZXkd3X6JsUuRVdPfrl6jKHvN0pj+rXxYyuouyWs6jUZSnc31VptksWo2iLJ/KP6M7uBoN31LcF4uirPduQ6vPo0jmdVZnsnns+uJlnC/n97JUuO27R9GiqNQNRa6fpEBiOope9B+Fq4Zfl8VsfC+f0uesKPVPJlk5WWb1eF5M5bh4GBcLWabN/aC5JZcTfV3pX0P9Tymn+6PJ1BUTq8+rlZ6mMUS0HWJaZvXTXNbZJJ4U8/ssT2s1gvZ4UTNe/I6ox0+zsnn6Gqlr/DvYsfp6mm2H+pCVVT1uSf05K+ul+mQ7ruYXsUwnT1r2ldQwGquqU017rKS8J5ToW3VrsawXS2/wlUWej6WUuSlRnoy23OhrpQzqdmSRf+vHo4Ov8eHX0EJWsh33VE6yqSydmEocmdpgnoamHT9AX8wXabke5V30PpgfDbR4UeNb5vX4oSzm4yxXMNHdQzqr5MrdGiBvy9vOHWoT3UUO9iMHvCMbQzokB986OcjHrpCNDbId5ax4zKq1V3uSVR2nagTPMl6UxbMWaJsZ+EqMtpsOZHo8Mu5GZjvJ1unktzjLK1nWXUhof4yHtt2By/1xsQuucMbFVlzagQuBP3DiBLxbkOWfi1JWVVyXaV7plTm+l7OO5TkZ4AyicEiLgsEkWMPI0Gjx8dC2URM//ycaNNji7QL+bxNDON/3oXFve37yn7/+Pr2nrMul1ypG+4MKyAaCDq9V0Py1icYdYxhIvSNO1qgKclSVs0ec4DDg/PHnk0ecXWwLn3VRW6MTGyyUDXhhNj6FGO5HfdM+V98FUPXBj6cBOyHoLDxyP+9L3tD7njb6/HjC0DMxhT3qNUE4QG2/QzXds5Va4W2i5H+H6bvJMxdTGxtoF5vO5TRbzmM5U4MpFSWLYiY7yNiGe7A7cELQiHYfspmKdXuC3hi+s9kv7k8ibekNYfdZli/1U5Y/9hvx9+uv7Vkr6LEVNJ0nojZakLcQ0a0IEfYnm2w7aBS+DdkpKLLofPg+ZMebDZv4qgK4FU2ghiYkwMY99TYncKvmhIhNiCxYycGQjvNw+xnEFr7c34onVeZi2E9iS9QDXxnezJJOTPOxVaYSGKzjQ0tEgo7P4dqgE1/m8a0wL0zr4TbmcSunuswVG4+l2uFNh7Kqza5nM/9mlxF1PYR4BvJDcXwSXhjAQ0rFfJWK3opL5mZwawtnE+4rQ3IrMkxMw2Q2GYpgFacDKo7B8ZUJG7T3BpvfCPO4VRKwxbLYe3/NbsV6mClDW+oIh2+o+ZCKh++n2RC093Za3Ir1WImmnqEFBAOxBQ7fSoohfrl3enlTugUXTi9/ONvxL88KD/FKLBPH40PCN7G81RrQzSwB3szyLd5XcbRPH644tnrnXTcgsL/KwxMf+k20VjnQltEm0K+iR72ou53jZNoKPOgCbtZKUFC9FVx/vfXTCQ+w8AFL4ycpoJLE+TjZtnBhc6nYHQoNQFlPKJby96X6219YaTTJ88C4R3BDzFoBtdUKCA2ZCLrYRMyEo7OJux/HHFqI3Q9gxkNQIkDY4FKypmaCnGKLcCkIURrwdkpjy1JT6H241kItRc5IA16KJgHCvZhBKp0wlMSWbqI4YB6X85BmPpvaqkGUHJHPBvvp7Gad7XoE9T4ybVMeFiB0fDHlMXOVzLbqU3enSwck4n7OnfQjsRCvRy8lW2bGX8yWDWQwYB7kYjpiZuSYLXRh7i6XDzDrHmOyAaQQp8cvpiPmwshszpuFxLfsYvMwIxVmi1SYu2cVA8yGeFZxMYlYBcAP2mbVkNMsjzf7xY4dyusCjFxaiFhHPFuX6wfUxSJu1rue1BcclMoxSeU0d0kpv9dfLyupHjUrymqzDXbfBVvkzkGvaDaV7R7ZuB7/bRL6lr7plmh++OVjPCuUAAqdeG4ks9RiEQPt1J1Ik7R8LOI/0kc1vh0U3WuxHu7Mzsoij4tyfyyIALDFSNZZBEc2uGO3J4d97HTS0pDiREkp02mTWVljNiqlokB9MdYPWEiPLohfolW4ANbqOdK+b5OE7Qo/uX8b+euShVb/2b7xLun2px85cEg2d6qjZ2s425P+mzUfw0s01fnmi9sOYHREPpm3a0Wj7vcJIEeicUhZ4I37fL5KorsKc15EdvNDQvhBb1u2QV+lIeKBhlOvF3BwWwKP09CGHvQaezrNxvp85t1Avq0CQEe1eRWTzNP7mRxPs0r/3VCyk+I66nhKm1WyVuOsXgOPvWB6/XnzU73h8NpjcPO0nrCGV9xfKuhapcIc+gg7hSSCm57QmXeT3CwfcdJvzQI0ceb+ZuR1O9ER6X/ueh0FCG6kO7s4zFyxSI6frv/LLMCVWohoaYvt1ITwfx1HDP4rfkPYHIVIgtu5zm0ZwtzxCHy8ZeDQDsCzz9YsXwh2/GyJt8pf60opzFVF2KIqQb2Fcq1BlTDLNsJWthEstCvt7HZh1oQFP94ueGgf49lnazpuCEDrE3S8AIS3DWCbDdCv3AZIS362YjwEIPiNXeetNgQdYTclfyjWLsEb3BwreW6VMwxssLMcVFcmEdpaeXaD5i31I0ebr1Jhb0Ul12q/oiVAbNUr7C0WeqVi0V7MlAuzyoWENjie2zz0YmZOg57APmhoV+z5J9xej8QJJuyfKmRXq/m4JUH7SuOfLORXK5dW7AitLw4DIrRp8/wGQlvTOD4BCCEI7fQ9/4RbKxxMTjBh/xyguFrNt9r/3jt4PfstbaEmTEKbXs+uSCexk/0EWZlmj091vP4vEToy5E2BEg8f5YKQuKNid1TqjorcUZk7KnBH5c6o3B1UOIO6c4WAM6g7VQdvMuwHdWfq4M1+vaDuPKHEFdNjnM425SFQZ4vyYN7ZntxVFDlbk4cxIWdj8rB75GxMHi5q721f6xOyw2djidPb6hMY3BJObK+WR6GnHayISWCaxwqIQ1fzNeLnUXM89G7vvwYaRbNURUP6zOnmrOY3P21emPDNp83BxlH0rJbTNSpLAGQEYYTwavUvtvXUYw==

Copy blueprint

2019-06-10 22_44_44-Clipboard.png (819.45 KiB) Viewed 9550 times

Why so complicated?
* Requester chests need to be cleaned out to avoid residual items clogging the station.
* While still cleaning residuals, they must not be loaded into an arriving train.
* Disabling the station (e.g. via red signal) while cleaning residuals would reduce efficiency.
* Stack Inserters only allow one type of item as a filter, this should always be an item that is still missing in the train, and already present at the station.
* Requester chests do not allow to read their contents when setting the filter.

Mechanisms:
* 4 Active Provider Chests: Removes everything that has been requested too much or cannot be loaded efficiently at the moment.
* 12 Active Provider Chests: Removes everything that has been requested too much.
* 12 Filter Stack Inserters: Clean out everything that is present and not needed anymore.
* 12 Requester Chests: Request items via bots.
* 12 Stack Inserters: Unpack the requester chests to allow the circuit to see what's currently inside.
* 12 Belts: Return their contents, allows to decide what should be loaded right now.
* 1 Belt in the middle: Allows the belts to empty while the majority of their contents is not to be loaded into the train (residuals or oversupply) -- or when there is no train
* 12 Filter Stack Inserters: Make sure nothing unintended get's into the train.

Combinators:
* 1x (*) at bottom left: Calculates what's missing in the train
* 3x (>=) at bottom right: Decides what to load right now -- it needs to be missing in the train, and it should be one of the items that are present on the belt the most
* 1x (/), 1x (>) at left: Divides the request by the number of chests, but makes sure at least one item per chest instead of none at all are requested, to avoid inability to load small amounts.
* 2x (|), 2x (>), 1x (/), 1x (>=), 1x (*) at left top: Returns only items on the belt whose quantity is above the average quantity per item. OR-Diodes are required for timing.
* 1x (*), 2x (>) at the top: Sets a filter to all items present on the belt, that are not allowed to be loaded, to clean them out of the boxes fast and keep them away from the belt (especially while loading). May do nothing while the majority of the belt is okay, and the bad items are only residuals on the belt -- with a second above average filter we could only improve our guess of the requester chests contents, but it will still be only a guess.
* Roboport: Tells the station which items can be provided. You might want to add a constant combinator and specify a lower request size minimum, if you want to load costly items (e.g. less than a thousand roboports)

EDIT: Blueprint was cropped, should be functional now.

PS:

Video

[mrvn]

Unless you're doing some serious magic with sending partially loaded wagons (why?) just enable the pumps that are associated with the fluid that the train wants.
Don't bother messing with how much is already on the train, and the pumps don't need to know how much is available. That is, connect the pumps to the station combinator, and set the CO2 pump to CO2>0.

I guess I was trying to make it foolproof, in others words there is no action to take after placing a blueprint, just start pumping in liquid

If you only ever want to deal with full/empty fluid wagons then the foolproof wiring is simple: Connect the yellow constant combinator of the LTN stop with all pumps and program them to <fluid> != 0. For unloading you don't even need the wire if the tanks are connected to a consumer or producer (show the fluid type even when empty). != works for both loading and unloading and also with sending trains manually (for unloading or partially fill trains, no way to guess the right liquid for loading an empty and manually send train).

You only need combinators when you want to support requesting/providing less than full fluid wagons. Most people don't bother with less than 25k for fluids. But with modules and complex production chains shipping less for rare fluids could be useful.

[slippycheeze]

Unless you're doing some serious magic with sending partially loaded wagons (why?) just enable the pumps that are associated with the fluid that the train wants.
Don't bother messing with how much is already on the train, and the pumps don't need to know how much is available. That is, connect the pumps to the station combinator, and set the CO2 pump to CO2>0.

I guess I was trying to make it foolproof, in others words there is no action to take after placing a blueprint, just start pumping in liquid

If you only ever want to deal with full/empty fluid wagons then the foolproof wiring is simple: Connect the yellow constant combinator of the LTN stop with all pumps and program them to <fluid> != 0. For unloading you don't even need the wire if the tanks are connected to a consumer or producer (show the fluid type even when empty). != works for both loading and unloading and also with sending trains manually (for unloading or partially fill trains, no way to guess the right liquid for loading an empty and manually send train).

Doesn't than suffer the annoyance that fluid level is a float, haha, and the circuit network is integer - but they will round down in some cases so that a fluid level of 0.1 is equal to a fluid level of 0 in a combinator?

[mrvn]

Unless you're doing some serious magic with sending partially loaded wagons (why?) just enable the pumps that are associated with the fluid that the train wants.
Don't bother messing with how much is already on the train, and the pumps don't need to know how much is available. That is, connect the pumps to the station combinator, and set the CO2 pump to CO2>0.

I guess I was trying to make it foolproof, in others words there is no action to take after placing a blueprint, just start pumping in liquid

If you only ever want to deal with full/empty fluid wagons then the foolproof wiring is simple: Connect the yellow constant combinator of the LTN stop with all pumps and program them to <fluid> != 0. For unloading you don't even need the wire if the tanks are connected to a consumer or producer (show the fluid type even when empty). != works for both loading and unloading and also with sending trains manually (for unloading or partially fill trains, no way to guess the right liquid for loading an empty and manually send train).

Doesn't than suffer the annoyance that fluid level is a float, haha, and the circuit network is integer - but they will round down in some cases so that a fluid level of 0.1 is equal to a fluid level of 0 in a combinator?

No fluid level involved here. The yellow constant combinator shows the amount LTN wants in the fluid wagons. Not the amount that is actually in them. For loading it will show 25000 and for unloading it shows -1 (because a 0 wouldn't show up).

[dorthak]

A provider station allowing all items from a logistic network being requested over long distances via LTN.

Does this work with mixed-cargo trains? Say a wall-maintenance train that needs to bring a little bit of a bunch of things?

[slippycheeze]

A provider station allowing all items from a logistic network being requested over long distances via LTN.

Does this work with mixed-cargo trains? Say a wall-maintenance train that needs to bring a little bit of a bunch of things?

Based on past experience, probably not exactly the way you imagine it will, because nobody seems to ask that question and also imagine the behaviour. That said, yes, absolutely it will work, and will supply whatever your wall stations request from the logistic inventory. You can put one of these attached to your mall, if you want, to cover "everything else", and honestly, that works pretty great.

Just don't expect it to 100 percent fill all the things to the level you expect at one time, or only ever use one train for them all, or to use the same train for them, or to keep a train pre-filled and in flight, or to visit more than one destination per run.

[mrvn]

A provider station allowing all items from a logistic network being requested over long distances via LTN.

Does this work with mixed-cargo trains? Say a wall-maintenance train that needs to bring a little bit of a bunch of things?

You need 2 things for this:

1) a provider station that provides all the goods you want in a single train.
2) some circuit logic so you request items in groups.

Normally your station will have enough of all goods. Then a bot takes out a wall item to replace a broken wall and the remaining walls are below the request limit. So LTN will send a train for walls. 5 seconds later a second bot takes out a repair pack and that falls below the request limit. So LTN sends a second train to bring repair packs.

What you need to do is build logic so it monitors the available items. When the sum of them falls below some limit (or one of them gets too low) you request something from the LTN stop. Then LTN will send a mixed train. The important part is that the demand for multiple items passes the requester limit at the same time. Otherwise LTN will send a train per item.

[dorthak]

What you need to do is build logic so it monitors the available items. When the sum of them falls below some limit (or one of them gets too low) you request something from the LTN stop. Then LTN will send a mixed train. The important part is that the demand for multiple items passes the requester limit at the same time. Otherwise LTN will send a train per item.

Interesting. Will have to poke at that. LTN has the threshold mechanic, but that's not enough, need a hysteresis mechanism of some sort.

[steinio]

What you need to do is build logic so it monitors the available items. When the sum of them falls below some limit (or one of them gets too low) you request something from the LTN stop. Then LTN will send a mixed train. The important part is that the demand for multiple items passes the requester limit at the same time. Otherwise LTN will send a train per item.

Interesting. Will have to poke at that. LTN has the threshold mechanic, but that's not enough, need a hysteresis mechanism of some sort.

Try out the new stack request amount. This sounds like it's what you need.

[mrvn]

What you need to do is build logic so it monitors the available items. When the sum of them falls below some limit (or one of them gets too low) you request something from the LTN stop. Then LTN will send a mixed train. The important part is that the demand for multiple items passes the requester limit at the same time. Otherwise LTN will send a train per item.

Interesting. Will have to poke at that. LTN has the threshold mechanic, but that's not enough, need a hysteresis mechanism of some sort.

Try out the new stack request amount. This sounds like it's what you need.

Nothing to do with that. The stack amount simply multiplies the value by the stack size of the item and only applies to items (not fluids). The problem of different items crossing the threshold at different times remains.

What you want is a threshold for the sum of items it may request. 1000 iron plates are fine, 1000 copper plates are fine, 500 iron plate and 500 copper plates are fine too. In the sum it would still be 1000 items / 10 stacks. But there is no such setting in LTN.

[steinio]

What you need to do is build logic so it monitors the available items. When the sum of them falls below some limit (or one of them gets too low) you request something from the LTN stop. Then LTN will send a mixed train. The important part is that the demand for multiple items passes the requester limit at the same time. Otherwise LTN will send a train per item.

Interesting. Will have to poke at that. LTN has the threshold mechanic, but that's not enough, need a hysteresis mechanism of some sort.

Try out the new stack request amount. This sounds like it's what you need.

Nothing to do with that. The stack amount simply multiplies the value by the stack size of the item and only applies to items (not fluids). The problem of different items crossing the threshold at different times remains.

What you want is a threshold for the sum of items it may request. 1000 iron plates are fine, 1000 copper plates are fine, 500 iron plate and 500 copper plates are fine too. In the sum it would still be 1000 items / 10 stacks. But there is no such setting in LTN.

Yeah sure whatever. Looks like you can read brains or just want to propagate your combinator contraption.

Stack requests are made for maintenance trains as you can request one stack of repair packs one stack of walls etc..

[mrvn]

What you need to do is build logic so it monitors the available items. When the sum of them falls below some limit (or one of them gets too low) you request something from the LTN stop. Then LTN will send a mixed train. The important part is that the demand for multiple items passes the requester limit at the same time. Otherwise LTN will send a train per item.

Interesting. Will have to poke at that. LTN has the threshold mechanic, but that's not enough, need a hysteresis mechanism of some sort.

Try out the new stack request amount. This sounds like it's what you need.

Nothing to do with that. The stack amount simply multiplies the value by the stack size of the item and only applies to items (not fluids). The problem of different items crossing the threshold at different times remains.

What you want is a threshold for the sum of items it may request. 1000 iron plates are fine, 1000 copper plates are fine, 500 iron plate and 500 copper plates are fine too. In the sum it would still be 1000 items / 10 stacks. But there is no such setting in LTN.

Yeah sure whatever. Looks like you can read brains or just want to propagate your combinator contraption.

Stack requests are made for maintenance trains as you can request one stack of repair packs one stack of walls etc..

The question was about getting LTN to request a mixed train containing both repair packs and walls. To request ONE train to fetch a stack of repair packs and a stack of walls for example. But not have it send a train with just one stack of repair packs. It should wait till it needs walls too (or repair packs are dangerously low). And setting the stack limit to 1 will fetch just one stack or repair packs. It might fetch one stack each but it's unlikely to happen. And if you set the limit to 2 then it will fetch 2 stacks of repair packs or 2 stacks of walls or unlikely 4 stacks (2 repair packs and 2 walls).

LTN will only request a mixed train if multiple items exceed the request limit each, not their sum.

[slippycheeze]

edit: I said "you" in what follows, and I mean "you" as in "any random person who wants this stuff", not "you" as in one specific person or anything.

If you want that degree of detailed control, I think you almost certainly want the Train Supply Manager mod instead of LTN.

A key difference in the model is that TSM gives you full control over filling the train, and only handles the "queue filled trains until needed" and "dispatch to the station in need" parts for you. So, if you want a mixed train you ... have a mixed train. Fill it, request it when you meet your desires -- whatever they are -- and it'll come to your station, efficiently, and without you needing to, eg, route trains through ten dozen wall stations before you get where you need.

Compared to constantly fighting LTN over what should go in the train, or what fill should be used when dispatching to a station in need of resources, or when the dispatching is done, you will find this ... somewhat less trouble, I should think.

I'm not claiming TSM to be perfect, or LTN to be bad. I believe they represent two different mental models for how a large scale train network should be handled. Both are valid, reasonable, and "correct" in as far as anything can be correct.

By using the mod that best fits with how you think about managing trains, well, you make sure you spend as little time as possible frustrated, and as much time as possible with the mod helping achieve your goals. You *can* make both mods work more or less like the other, but it isn't a fun exercise.

[mrvn]

I don't see the problem you seem to see.

There is no fight with LTN. Just circuit logic to set the request amounts based on circuit logic instead of using a constant provider.

[Optera]

I don't see the problem you seem to see.

There is no fight with LTN. Just circuit logic to set the request amounts based on circuit logic instead of using a constant provider.

I'd call it expanded use of mechanics. Something I do a lot even in base factorio whenever circuit logic is involved like abusing integer overflow to cycle filters for filter stack inserters.

If it works for you that's great. However please don't give the impression some circuitry monstrosity is required to run LTN. Some users struggle setting the single constant combinator and arithmetic combinator required for static thresholds and filtered un/loading.

[mrvn]

I don't see the problem you seem to see.

There is no fight with LTN. Just circuit logic to set the request amounts based on circuit logic instead of using a constant provider.

I'd call it expanded use of mechanics. Something I do a lot even in base factorio whenever circuit logic is involved like abusing integer overflow to cycle filters for filter stack inserters.

If it works for you that's great. However please don't give the impression some circuitry monstrosity is required to run LTN. Some users struggle setting the single constant combinator and arithmetic combinator required for static thresholds and filtered un/loading.

It's totally not required to use LTN. Normal stations I recommend simply place a LTN combinator next to them and use that.

But it is required if you want to ensure LTN orders trains with mixed goods instead of ordering a sequence of single good trains. If you don't care if LTN orders items in separate trains or combined you don't need it. As explained above.

PS: Not sure what circuit montrosity you mean. Mine uses 3 combinators.

[Optera]

Not sure what circuit montrosity you mean. Mine uses 3 combinators.

Combinators tend to add up quickly for me: 3 to generate requests, 2 for extra safe unloading control, 1 for position decoding with another 1 per wagon position...

Once everything is set up and running, use picker dollies to move them in a tight arrangement, save it as blueprint only to stumble across it months later no longer remembering what the hell this thing actually does

[slippycheeze]

I don't see the problem you seem to see.

There is no fight with LTN. Just circuit logic to set the request amounts based on circuit logic instead of using a constant provider.

I'd call it expanded use of mechanics. Something I do a lot even in base factorio whenever circuit logic is involved like abusing integer overflow to cycle filters for filter stack inserters.

If it works for you that's great. However please don't give the impression some circuitry monstrosity is required to run LTN. Some users struggle setting the single constant combinator and arithmetic combinator required for static thresholds and filtered un/loading.

I couldn't agree with this more. I pretty much just use the one-combinator method for LTN, and it works just fine. I have a backstop, cleaning junk at the depot, for when something goes wrong ... but that something is uniformly "me" one way or another, and I could totally not have that even. I'd just need to manually clean up the mess, like, once a month or whatever.

LTN is very, very simple to use. Like a lot of tools it scales really well into super-complex stuff, but easy things are very easy. Which is a heck of an achievement, and I hope you are justly proud of it Optera.

There is no fight with LTN. Just circuit logic to set the request amounts based on circuit logic instead of using a constant provider.

There isn't any single, specific part of the strategy that is "the fight", but rather, it is in the overall goal. This is clearly opinion, but pretty much every time people describe a complex combinator system used to carefully control LTN so that it only delivers a very specific combination of things in a single train trip ... I think of how the TSM implementation would look:

1. Station(s) fill the train with the desired stuff for this line.
2. Train goes to dedicated supply stacker and waits.
3. Train goes to station requesting the supplies -- a boolean flag.
4. Go back to one.

Total number of combinators, zero to "one per item" at most, and they are trivial combinators, and they stay trivial.

This isn't free, of course: the reason the combinators are trivial is because the train line is a single, fixed purpose tool. It can't supply anything except what is filled, and can't borrow trains from elsewhere.

LTN can, and does, do that. It is great for all sorts of reasons, and can do a number of things that TSM can't. ...but that isn't free either: in return, trying to minimize, for example, the number of trains used to deliver for mixed supply by ensuring you only get multiple items in the volume desired is ... hard.

Not impossible, because LTN is super-flexible, but hard. You have to really work to make it happen, and you have even stricter rules than TSM for how things work in terms of, eg, how you fill the train. TSM is fine with three stations each giving one part of the load, LTN ... not so much.


So, sure, you absolutely can make LTN use one train run rather than two if you request walls and repair kits at different times.

I just don't think, as a rule of thumb, that you ever should. If you care about the fact that two train trips were spent, TSM is likely a better fit for your desired train management strategy.

That isn't LTN being bad, just ... people want to handle trains different ways, and all those ways are valid. Pick the right tool for the job and you will find it vastly easier -- trivial, in fact -- to have it do what you want.

[mrvn]

All good points. But every player plays different and wants things to work different. Luckily LTN allows it all using as few as 1 constant/ltn combinator or as many combinators as one likes.

But trains for multiple goods could also be something LTN could support better natively. Currently you set a request/provider limit and it applies for each good separately. If the requester limit is reached the good is requested. But what if the requester limit instead would be for the sum of goods or a second limit for the sum?

You set -1000 iron plates, -1000 copper plates, -1000 steel plates, -500 coal. Combined/Multi Stack limit 40. In the sum that is 40 stacks so the request is processed. You might still not get a train with all 4 goods because no station provides them all in sufficient quantity or not all at the same place. But that's always a possibility.

I think the idea of the limit is to prevent trains moving for trivial amounts. Which is a) wasteful on fuel, b) causes congestion and c) uses up all the trains so they will have to come from far off depots. For that purpose a combined stack limit would make a lot of sense. As icon it could have the stack limit icon but with 2 stacks, one iron plates, one copper plates.