LTN and multi-item supply trains

[zOldBulldog]

Example scenario:

- I load and deliver exact quantities of 20 different items, using a 1-2 train.
- Conditions on the inserters ensure that precise quantities get loaded onto the train and precise quantities are unloaded onto the requester chests.
- That precise set of supplies remains in the chests ready to be used, near my nuclear power plants.
- When - through the map - I place a blueprint for a nuclear power plant modules, bots retrieve the supplies from the chests.
- Once *all* of the chests are empty, a signal is generated to call a train to deliver supplies.

Current implementation (working, but not ideal):

- I separated this route into its own NetworkID=2. It contains a single train.
- I use one decider combinator at the requester station that outputs NuclearReactor=1 as long as at least one chest contains an item. The constant combinator at the LTN station is set for NuclearReactor=-1, thus a request gets generated when all the chests are empty.
- Assuming that there is always enough time for the provider chests to fill between requests (constructions of a new nuclear power plant module), I cheated and added NuclearReactor=1 to the provider constant combinator... in other words, the provider believes that it always has the needed items. Which is not technically true, but it is true by the time a request comes.
- All of the inserters are fast inserters set to stack size = 1. As the quantities are low, this does not matter. One exception is concrete (2800 items), which would take a very long time to load one by one, so I use a stack inserter and wagon filters to ensure that no more than 2800 items are loaded.

QUESTION:

Clearly this implementation works but is less than ideal. I would like advice on how to address some of the following obvious flaws:

1) Ideally, I would like to request the exact quantities of each item instead of the false NuclearReactor signal. For safety, I will still keep the inserter conditions at the receiver... but the train needs to arrive with exactly the desired items so that none remains on the train and the LTN Tracker does not raise an alert. Is this as simple as replacing NuclearReactor=-1 with 20 conditions of <item>=-<quantityDesired> and then feeding all of the chest contents to the LTN stop, on the assumption that once *all* of the items become needed then and only then will the request be made? Or will that totally confuse LTN? Or worse, will that cause a lot of independent requests as each item runs out?

2) Similarly, I would like the provider to report to LTN how many of each of the 20 items it has available instead of the false NuclearReactor=1 signal, so that the provider is more accurately set to ready to load based on the accurate 20-item request from (1). For safety, I will still read the train contents and keep the inserter conditions to ensure I don't overfill the train. I assume that this is as simple as feeding the chest contents to the provider stop... if (1) is correctly handled, right?

3) I would like to stop using a dedicated network. I think that once I achieve (1) and (2) I should be able to do so, correct?

4) I would also like to avoid using the wagon filters, but I can't think of any other way to load exactly 2800 items quickly. Is there any way to do that?

[eduran]

As a general rule: each item signal is its own request. If you wire 20 negative item signals into the input, LTN will treat that as 20 different requests. If possible (i.e. a single provider provides all of the items) LTN will merge them into one delivery. If that is not possible, they will be delivered in parts, whenever they become available somewhere.

1) Ideally, I would like to request the exact quantities of each item instead of the false NuclearReactor signal. For safety, I will still keep the inserter conditions at the receiver... but the train needs to arrive with exactly the desired items so that none remains on the train and the LTN Tracker does not raise an alert. Is this as simple as replacing NuclearReactor=-1 with 20 conditions of <item>=-<quantityDesired> and then feeding all of the chest contents to the LTN stop, on the assumption that once *all* of the items become needed then and only then will the request be made? Or will that totally confuse LTN? Or worse, will that cause a lot of independent requests as each item runs out?

You can replace your nuclear reactor signal with 20 conditions of <item>=-<quantityDesired>, but LTN will try to fulfill requests as soon as they show up. So if your bots take 5 heat pipes out of their chests, 5 heat pipes will be delivered by a train. If you want to avoid having multiple partial deliveries, you have to use some form of circuit logic. Block the negative item signals as long as there is at least one item left in the chests. Turn them on when everything is empty.

I assume that this is as simple as feeding the chest contents to the provider stop... if (1) is correctly handled, right?

In principle, yes. But for your setup, this would rely on production always being faster than consumption. If a full request of all 20 items is signaled at the requester, but your provider only offers half of them, LTN will take what it can get and deliver the available items. You would have to use the same logic as for the requester and only show items as provided as soon as all of them are available.

3) I would like to stop using a dedicated network. I think that once I achieve (1) and (2) I should be able to do so, correct?

Keeping it on a separate network should not be necessary. Make sure to properly set train length limits.

4) I would also like to avoid using the wagon filters, but I can't think of any other way to load exactly 2800 items quickly. Is there any way to do that?

Fill your train up with as many stack inserters as you like and set them to stop at item count >= 2800. Set up a single fast inserter taking items OUT of the train, stack size override of 1, and only active for >2800 items. Only works with a single wagon or inventory sensor. But I have to ask: why is it important to get the exact count of concrete tiles right? I get that you don't want to deliver 5 extra reactors, but what would be so bad about 50 extra tiles?

I think that what you describe is best handled by a single vanilla train. The strength of LTN is to deal with multiple provider to multiple requester situations with as few constraints as possible. Since LTN only takes control of trains parked at a depot, it is perfectly fine to run some vanilla trains in parallel.

[zOldBulldog]

@eduran,

Excellent feedback.

Answers:

- The reason for having an exact count (of concrete as well as the rest) is to minimize traffic on the train network:
--- Bots will remove things from the requester's chests at their own pace, so it is very likely that some items will run out before others. That might not result in 20 trains being called, but it would definitely be quite a few more than 1.
--- An exact count lets me trigger a single train request when *all* items = 0.

Conclusions:

- It seems like although I could request the actual items, the approach of using a false item (NuclearReactor=1) request might be the right one for my use case.
- I love your idea of fast loading with stack inserters up to 2800, then unloading with a fast inserter when count > 2800. And leave all the others at stack size = 1. That should let me get the precise number of items with a vanilla and empty 1-2 train.
- Once I am using the vanilla 1-2 train I no longer need a dedicated network, so I can get the empty 1-2 trains from the default depot.

Thank you very much!!!

EDIT: Worked like a charm. A couple tweaks I added:
(1) Used 20 combinators at the provider to turn on the NuclearReactor signal to indicate the provider is ready when it really is.
(2) Had to add DisableWarningMessages to the Provider combinator, so that it would stop complaining about having loaded the wrong stuff.

BTW, I am not sure if this would be useful to anyone else, but if there is any interest I would be happy to provide screenshots and blueprints after I apply these changes. Here, or in the design thread.