Is it possible to request from multiple providers in a single schedule?

[igorhgf]

I want to know if it is possible to make LTN to generate schedules that are more than "Depot -> Provider -> Requester -> Depot" style. I want a "Depot -> Provider A -> Provider B -> ... -> Requester A -> Requester B -> ... -> Depot"



Example 1:

I want to setup a requester that requests 1k iron and 500 copper.

If both of those resources are in a single provider, then it is all ok. But, if they're in different providers, LTN will send 2 trains, 1 for the iron and 1 for the copper.

I want a schedule that goes first to iron THEN goes to the copper THEN it goes back to whoever requested.

And if this is possible, is there a way to control the request based on individual conditions? (don't generate a schedule if there is less than 800 iron AND less than 300 copper, for example).



Example 2:

I want to request 1k iron.

I have 2 providers with 800 each.

I want a schedule that goes to the first station, pick the 800 iron, then goes to the second station and get the remainder 200 iron from the second station before returning to the requesters.

[DaleStan]

tl;dr: No.

Why not? I've are some of the questions and problems that system would raise.

How does LTN know which station to go to first?
How does LTN know that it's advisable (or even possible) to travel from one provider to the other? It has to be possible to get from either provider to the requester to the depot, but if your depots are line-end stations, it could be that the only route from one provider to the other requires going through a requester and then making a U-turn in the depot.
LTN schedules a delivery as soon as the provide and request values exceed the thresholds. Both provider stations would have to switch from "below limit" to "above limit" on the same tick. (Or you'd have to make sure the requester doesn't request until both providers are above the limit, but that's even harder.)

For the first two, the obvious answer is "ask the rail pathfinder", but mods don't have access to that, so those are hard stops. Also, defining "advisable" in a meaningful way would be ... difficult.
LTN could probably handle the third by waiting e.g. 30-60 ticks to see if any more requests appear before supplying the request, but that introduces even more latency into a system that's already not as responsive as a system where trains are always waiting at the loading stations.

Pretending all of these problems go away, what are the logical consequences of this system? I'd end up with one train that picks up green chips, iron plates, and copper plates, delivers some iron to the steel mill, goes back to the green chip factory to drop off the rest of the iron and some copper, and finally delivers the rest of the copper and the green chips to the red chip factory. While it would be fun to watch, this doesn't seem like an efficient way to schedule my deliveries.

[ApocNL]

Fun to see this here aswell xD

I guess the awnser was already given on Reddit xD

How does LTN know which station to go to first?
How does LTN know that it's advisable (or even possible) to travel from one provider to the other? It has to be possible to get from either provider to the requester to the depot, but if your depots are line-end stations, it could be that the only route from one provider to the other requires going through a requester and then making a U-turn in the depot.
LTN schedules a delivery as soon as the provide and request values exceed the thresholds. Both provider stations would have to switch from "below limit" to "above limit" on the same tick. (Or you'd have to make sure the requester doesn't request until both providers are above the limit, but that's even harder.)

Nice explanation

[mrvn]

I'm assuming stations are all reachable. Obviously you can build a train system where you have to go depot -> provider -> requester -> depot with no way to turn around but I find that pretty uncommon. For those cases there should be a config option to disable multi-stop schedules (if we ever get them) or API access to the path finder.

So on to the other point of having provides/requests happen on the same tick. For the second example this isn't a problem. Both stations would provide already when the request is made. But why send a train to both stations when you can send two trains? What exactly is you aim there? Unless the two stations are in sequence sending two trains will be faster. Similar for the first example. If you want efficient then why even send a train to get a partial load of iron plates? Why not add some buffer chests and only deal with full wagons of iron plates?

If you truly want small mixed trains you can also add transfer / mix stations. Make a station that requests full cars of iron plates and copper plates and put it in Network ID 1. Then provide both iron plates + copper plates with Network ID 2 so small trains can pick up a mix. You can use circuit logic to provide only when iron and copper are available. Also request only when you need iron plates + copper plates > 1500 or something.


As for more complex schedules I would rather see trains send on a new errant when they finish unloading without going through the depot (unless fuel runs low). Preferably even pick up stuff at the station they are at. For that the new request must only come in while the train is on the way. But it's hard to estimate time till a train finishes it's schedule vs. when a new train would arrive. LTN can't really know when extending a schedule would be better than sending a fresh train. Except when running short on trains or replacing a train heading to the same station. Both very rare. Worth the coding effort? Probably not.

[steinio]

Fun to see this here aswell xD

I guess the awnser was already given on Reddit xD

How does LTN know which station to go to first?
How does LTN know that it's advisable (or even possible) to travel from one provider to the other? It has to be possible to get from either provider to the requester to the depot, but if your depots are line-end stations, it could be that the only route from one provider to the other requires going through a requester and then making a U-turn in the depot.
LTN schedules a delivery as soon as the provide and request values exceed the thresholds. Both provider stations would have to switch from "below limit" to "above limit" on the same tick. (Or you'd have to make sure the requester doesn't request until both providers are above the limit, but that's even harder.)

Nice explanation

Haha yeah maybe my answer there was not clearly enough :/

[igorhgf]

How does LTN know which station to go to first?

Perhaps a signal to specifies the order, if the order is important in the first place.

How does LTN know that it's advisable (or even possible) to travel from one provider to the other?

A signal that limits schedules to that delivery. If set to 1, then a single train should gather all the requested itens (up to it's cargo limit). You already have control of how many trains are send to each station at the same time, this way you can enchance this control by making less trains gather more stuff.

LTN schedules a delivery as soon as the provide and request values exceed the thresholds.

Is it so hard to add an "AND" while checking thresholds?

Pretending all of these problems go away, what are the logical consequences of this system?

But why send a train to both stations when you can send two trains? What exactly is you aim there?

Fewer trains in transit. I'm giving up parallel deliveries to reduce traffic jam.

[mrvn]

I noticed another bad thing that kind of goes into the same direction (avoiding too many trains):

When I request 400 transport belts from the factory outlet for the player (no limit on train numbers) then I get one train with 200 belts. The factory then produces more belts. Since it also allows ordering 1 nuclear reactor the provider limit is 1. So the next train holds 2 transport belts. Then 2 again and so on till all trains are scheduled.

Or I order 200 iron plates, 200 copper plates, 200 steel plates. As I enter the requests each gets a train assigned all going to factory outlet to the player. If I turn off the constant combinator, enter the numbers and only then enable the constant combinator I get a single train with 3 stacks.

Maybe when it tries to schedule the next train it could check if there already is a train going that way, if that train hasn't loaded yet and if it still has space. If so modify the existing train instead. That would also help with mixed deliveries where the request doesn't happen at exactly the same tick. The later request would potentially be merged with the first.

[Optera]

I noticed another bad thing that kind of goes into the same direction (avoiding too many trains):

When I request 400 transport belts from the factory outlet for the player (no limit on train numbers) then I get one train with 200 belts. The factory then produces more belts. Since it also allows ordering 1 nuclear reactor the provider limit is 1. So the next train holds 2 transport belts. Then 2 again and so on till all trains are scheduled.

Stack Thresholds should prevent exactly this.

Maybe when it tries to schedule the next train it could check if there already is a train going that way, if that train hasn't loaded yet and if it still has space. If so modify the existing train instead. That would also help with mixed deliveries where the request doesn't happen at exactly the same tick. The later request would potentially be merged with the first.

While I kinda like the idea, iterating all deliveries of trains currently en route to provider is too situational and has too much overhead to be practical.

[mrvn]

I noticed another bad thing that kind of goes into the same direction (avoiding too many trains):

When I request 400 transport belts from the factory outlet for the player (no limit on train numbers) then I get one train with 200 belts. The factory then produces more belts. Since it also allows ordering 1 nuclear reactor the provider limit is 1. So the next train holds 2 transport belts. Then 2 again and so on till all trains are scheduled.

Stack Thresholds should prevent exactly this.

But then I would also have to buffer a stack of nuclear reactors, which is 10, and they are expensive.

Maybe when it tries to schedule the next train it could check if there already is a train going that way, if that train hasn't loaded yet and if it still has space. If so modify the existing train instead. That would also help with mixed deliveries where the request doesn't happen at exactly the same tick. The later request would potentially be merged with the first.

While I kinda like the idea, iterating all deliveries of trains currently en route to provider is too situational and has too much overhead to be practical.

There is no need to check all deliveries, only those en route to one specific provider. Those in the active deliveries table. Most stations have a train limit so the number of trains to compare against should be small. For me the limit is mostly 2 with some very few stations going as high as 8. I try not to buffer more than 2 trains so LTN never sends more trains if full cargo wagons are requested anyway.

[Optera]

But then I would also have to buffer a stack of nuclear reactors, which is 10, and they are expensive.

Expensive? This is Factorio just build more and let products pile up.
Satisfying the just in time delivery itch is not what LTN is supposed to do out of the box, it'd be too mcuh overhead. If you want that get creative with circuitry.

There is no need to check all deliveries, only those en route to one specific provider. Those in the active deliveries table. Most stations have a train limit so the number of trains to compare against should be small. For me the limit is mostly 2 with some very few stations going as high as 8. I try not to buffer more than 2 trains so LTN never sends more trains if full cargo wagons are requested anyway.

How should LTN know this one stops needs to be checked and not the other 99 stops currently recieving deliveries?

[mrvn]

But then I would also have to buffer a stack of nuclear reactors, which is 10, and they are expensive.

Expensive? This is Factorio just build more and let products pile up.
Satisfying the just in time delivery itch is not what LTN is supposed to do out of the box, it'd be too mcuh overhead. If you want that get creative with circuitry.

There is no need to check all deliveries, only those en route to one specific provider. Those in the active deliveries table. Most stations have a train limit so the number of trains to compare against should be small. For me the limit is mostly 2 with some very few stations going as high as 8. I try not to buffer more than 2 trains so LTN never sends more trains if full cargo wagons are requested anyway.

How should LTN know this one stops needs to be checked and not the other 99 stops currently recieving deliveries?

LTN prepares a new delivery of 5 transport belts from A to B. The pending requests and provided items makes that decision, right? Then instead of looking for a new train first check A.active_deliveries for trains not yet loaded and going to B that have space. Add 5 transport belts to the schedule.

[igorhgf]

So... to the original question, is it possible?

But then I would also have to buffer a stack of nuclear reactors, which is 10, and they are expensive.

Expensive? This is Factorio just build more and let products pile up.

The factory grows.

[Optera]

So... to the original question, is it possible?

No.
Calculating milk runs in lua will have terrible performance.

[zOldBulldog]

My railworld is fairly widely distributed. I have an item (air filters from Schorty's mod) that is consumed in small quantities at many locations.

Sending a train with few items from depot to provider to requester to depot in this scenario is so inefficient (puts huge numbers of trains on the network for very little benefit) as to not be worth doing. Sending a full train to each location and letting it be a long term cache is better but requires producing 10 to 100 times more items than what gets consumed... again not worth doing, at least early on.

The ideal routing would be to have a train leave the depot, stop at the provider where it picks up a full train of product, then go to multiple requester and unload until their needs are satisfied, continuing on to other requesters that have an active request... until the train is empty, and only then return empty to the depot. The opposite problem (multiple pickups, one delivery) is also desirable. As a matter of fact, this is probably quite close to how such distribution is done in real life (for a simple analogy think of a Coca-Cola delivery truck).

Is such a method of routing possible with LTN? If yes, how?

If no, there a supplemental mod that enables it already? And if not yet... do the APIs make it at least theoretically possible?

[mrvn]

My railworld is fairly widely distributed. I have an item (air filters from Schorty's mod) that is consumed in small quantities at many locations.

Sending a train with few items from depot to provider to requester to depot in this scenario is so inefficient (puts huge numbers of trains on the network for very little benefit) as to not be worth doing. Sending a full train to each location and letting it be a long term cache is better but requires producing 10 to 100 times more items than what gets consumed... again not worth doing, at least early on.

The ideal routing would be to have a train leave the depot, stop at the provider where it picks up a full train of product, then go to multiple requester and unload until their needs are satisfied, continuing on to other requesters that have an active request... until the train is empty, and only then return empty to the depot. The opposite problem (multiple pickups, one delivery) is also desirable. As a matter of fact, this is probably quite close to how such distribution is done in real life (for a simple analogy think of a Coca-Cola delivery truck).

Is such a method of routing possible with LTN? If yes, how?

If no, there a supplemental mod that enables it already? And if not yet... do the APIs make it at least theoretically possible?

Not possible.

For such a setup use a normal train and name all the stations needing air filters the same. Set the train to load air filters until full and then add the unloading stations N times with circuit condition "air filters > M" or "empty". Then program the unloading stations to enable when "air filters < X". The train will then go to N stations and unload somewhat more than M - X air filters. So one train should hold N * (M - X) air filters and then some.

As your factory grows it might also make sense to set up caches for air filters every now and then. Fill the caches with LTN trains and then use the above to distribute them to a bunch of stations. At that point you could use LTN trains again for the local delivery as building a few more air filters to fill the buffers shouldn't be such a problem.

For the opposite problem you can do the same.

[zOldBulldog]

For such a setup use a normal train and name all the stations needing air filters the same. Set the train to load air filters until full and then add the unloading stations N times with circuit condition "air filters > M" or "empty". Then program the unloading stations to enable when "air filters < X". The train will then go to N stations and unload somewhat more than M - X air filters. So one train should hold N * (M - X) air filters and then some.

Bummer that LTN can't do it.

The vanilla approach you describe is what I have been using (even though I use LTN for normal trains), but it resulted in a lot of train traffic.

The biggest issue is that the demand of the stations depends on the pollution being created at each location. So, when I use a low value of N the trains often return to the provider without having emptied, and when I use a higher value of N they often go to stops while being empty. The result is far too much Air Filter traffic on my train network.

Very frustrating and that is why I was hoping LTN or somebody else's "works with LTN" mod would do the trick. This question was a last ditch attempt to salvage my use of air filters to play in an ecologically friendly way... I am now considering saying "to h*** with it", wiping out a much wider area of nests, and letting pollution run rampant but without reaching those far nests.

[slippycheeze]

Very frustrating and that is why I was hoping LTN or somebody else's "works with LTN" mod would do the trick. This question was a last ditch attempt to salvage my use of air filters to play in an ecologically friendly way... I am now considering saying "to h*** with it", wiping out a much wider area of nests, and letting pollution run rampant but without reaching those far nests.

I know this doesn't tell you how to make LTN do multi-stop deliveries or whatever, but....

I think you are over-valuing making and shipping air filters. Instead of worrying about small numbers, request in batches of three to five stacks of them. It'll mean you make a whole lot less supply runs to those outposts, cutting down the traffic by a factor of ... whatever multiplier it is on the size of them. Heck, ship ten or twenty.

You might never get through those stacks in a small enough outpost, but you avoid the unnecessary train traffic in return. That lets LTN do the dynamic scheduling of deliveries, if you don't want to just run one dedicated train for the purpose. I imagine that it isn't 100 percent of a train worth of time even with tiny stacks of them being sent around.

[zOldBulldog]

Very frustrating and that is why I was hoping LTN or somebody else's "works with LTN" mod would do the trick. This question was a last ditch attempt to salvage my use of air filters to play in an ecologically friendly way... I am now considering saying "to h*** with it", wiping out a much wider area of nests, and letting pollution run rampant but without reaching those far nests.

I know this doesn't tell you how to make LTN do multi-stop deliveries or whatever, but....

I think you are over-valuing making and shipping air filters. Instead of worrying about small numbers, request in batches of three to five stacks of them. It'll mean you make a whole lot less supply runs to those outposts, cutting down the traffic by a factor of ... whatever multiplier it is on the size of them. Heck, ship ten or twenty.

You might never get through those stacks in a small enough outpost, but you avoid the unnecessary train traffic in return. That lets LTN do the dynamic scheduling of deliveries, if you don't want to just run one dedicated train for the purpose. I imagine that it isn't 100 percent of a train worth of time even with tiny stacks of them being sent around.

Thank you. I had already thought of that option, I am already shipping 6 stacks per delivery and later on it will be viable to deliver a trainful which will definely take care of the issue.

But as I am refining my "overall approach" it has to work early in the game as well and unfortunately it would take too large a filter facility too soon to do it early in the game. So it is not really an option.

And to be honest, although it would be nice for LTN to have multiple pickups/one delivery or one pickup/mutiple deliveries (as in real life)... I think the real problem is the Air Filters mod for consuming air filters so fast as to be unpleasant in very distributed maps, not LTN's.

[mrvn]

Very frustrating and that is why I was hoping LTN or somebody else's "works with LTN" mod would do the trick. This question was a last ditch attempt to salvage my use of air filters to play in an ecologically friendly way... I am now considering saying "to h*** with it", wiping out a much wider area of nests, and letting pollution run rampant but without reaching those far nests.

I know this doesn't tell you how to make LTN do multi-stop deliveries or whatever, but....

I think you are over-valuing making and shipping air filters. Instead of worrying about small numbers, request in batches of three to five stacks of them. It'll mean you make a whole lot less supply runs to those outposts, cutting down the traffic by a factor of ... whatever multiplier it is on the size of them. Heck, ship ten or twenty.

You might never get through those stacks in a small enough outpost, but you avoid the unnecessary train traffic in return. That lets LTN do the dynamic scheduling of deliveries, if you don't want to just run one dedicated train for the purpose. I imagine that it isn't 100 percent of a train worth of time even with tiny stacks of them being sent around.

Thank you. I had already thought of that option, I am already shipping 6 stacks per delivery and later on it will be viable to deliver a trainful which will definely take care of the issue.

But as I am refining my "overall approach" it has to work early in the game as well and unfortunately it would take too large a filter facility too soon to do it early in the game. So it is not really an option.

And to be honest, although it would be nice for LTN to have multiple pickups/one delivery or one pickup/mutiple deliveries (as in real life)... I think the real problem is the Air Filters mod for consuming air filters so fast as to be unpleasant in very distributed maps, not LTN's.

Set up all air filter requesters to request a full train (and a bit) with a requester limit of one train. Then set the provider of air filters to have a provider limit of 1 stack at the start. This will make trains pick up air filters as soon as one stack is produced and spread them all over the map with lots of trains. Then as you ramp up production of air filters increase the provider limit and each train will carry more and more filters.

It still means you have to produce a lot of air filters in advance before trains stop delivering them but it will fix the problem of not having enough air filters at the start.