"Locked slots per wagon" breaks down with merged delivery requests

[doktorstick]

This is a toss-up between working as designed (and so becomes a suggestion) or an unintentional behavior problem. Feel free to mark it as you see fit.

The main (only?) purpose of locked slots per wagon is to prevent inserters from holding on to items (n.b. https://forums.factorio.com/viewtopic.php?p=306857#p306857). Unfortunately, with stations that can supply many items, the stated goal of locked slots breaks down as each item type will possibly overflow into the "next" slot leaving the stations with two possible outcomes--1) inserters are left holding items; or 2) the pickup order fails because it cannot add all the item quantities due to previous items' overflow.

If the number of items is fixed, then it's simple enough for the user to manually increase the locked slots count to match the maximum number of items that can be in a wagon (e.g., supply coal, iron, and copper, designate three locked slots). Although, this does "waste" slots if all three items aren't in the merged request.

On the other hand, when the number of items in is the double digits, it becomes infeasible. And with stack sizes ranging from 1 to mod-dependent, it can't be mitigated with request thresholds unless they are high enough to guarantee only a few items can be in a wagon.

What I'd like to see fixed is when a merged delivery request is created, the number of locked slots scales with the number of items requested in the order. I'd be satisfied if this was an LTN setting.

As an aside, I don't know of other use-cases of locked slots. If my proposed fix was the default behavior, would you even need to specify the number of locked slots anymore, or would it just become a boolean signal?

[0ptera]

would you even need to specify the number of locked slots anymore, or would it just become a boolean signal?

Building stations overloading several stacks in one tick is fairly simple. Especially with items with a stack size below or close to inserter stack size.

Even knowing how many inserters and what stack size they are set to a station has wouldn't be enough.
Inserters could be filtered to different items, stack size different between inserters, items trickling in below stack size and so on.....

On top of all that, merged deliveries are rare.
Unless no trains are available, requests need to be made within the same tick to be merged.
That's hardly ever happening in normal factory use. I don't recommend copying what I did on the demo maps merged requester, throughput is terrible.

[doktorstick]

On top of all that, merged deliveries are rare.
Unless no trains are available, requests need to be made within the same tick to be merged.

Indeed. For the core of the factory I agree. There are three ancillary uses with which I run into the problem, and in each case the number of trains are below the number to serve maximum throughput. The first two are commonplace for me; the last is a niche use.

1. Military supply trains. These supply my wall outposts. Since attack waves consume many resources at once (fluid, bullets, repair packs, mines, and bot death), it is a very frequent occurrence that a merged delivery is required. Usually I run with two military supply trains while I might have a dozens of drop-off points.

2. Builder supply trains. I usually only have one of these and use ghost combinator to request items to a temporary construction outpost.

3. Transfer station. This happens when I have an old factory still producing a reduced amount or a lot of buffers that need to be eventually transferred. Usually one station for 15-20 items until the old factory retires, which can be on the order of tens of hours. Despite the number of items supported, to speak to your point, usually a low number are needed at once to level off the main factory. I'll configure it for four items (four locked slots) and it can last a while before locking.

[KaidenP]

Wait Is it possible to schedule a single delivery with multiple types of items?

Aside from a hacky way of loading a train with unrequested types of items?

[doktorstick]

Yes, @KaidenP. This is easily supported. In fact, LTN is implemented to actively support this use case.

[KaidenP]

@doktorstick So you just create a requester that requests say iron plates and copper, and a provider providing both of the same, and it'll create a single delivery with both copper and iron, both in the same train? If you set the request/provide stack threshold to be exactly your wagon(s) size(s), does it still work this way?

I've never considered trying this deliberately.

[0ptera]

So you just create a requester that requests say iron plates and copper, and a provider providing both of the same, and it'll create a single delivery with both copper and iron, both in the same train?

If request threshold for both items is surpassed in the same cycle.
See LTN Demo Map: https://forums.factorio.com/viewtopic.php?f=214&t=51072

If you set the request/provide stack threshold to be exactly your wagon(s) size(s), does it still work this way?

Thresholds work best when set to multiples of total train capacity.

[doktorstick]

Yes, what @Yousei9 said. This is getting afield from the enhancement request, but I tend to set my request thresholds in a ratio that is used in the production block. When it needs one resource, it needs the other. Sometimes (and this isn't the normal case; I won't pretend it is), I'll setup a multi-provider on purpose (and sometimes by happenstance) that serves those same items. Unless another provider snipes one of the items, or the multi-provider isn't keeping up for some reason, it does a pretty decent job at maintaining one train for two or more items delivered. And if a single provider does snipe, it eventually gets back to steady state since the requests are ratio-based.

The cases I outlined earlier are my more "normal" cases of merged deliveries; I usually don't have multiple items being produced at one station.

[xayahxxx]

Until this has a more elegant solution, could a setting be added to just disable the creation of merged deliveries?

I have a working local implementation, but the license does not allow me to create a public PR without prior permission, as that would constitute a modified distribution.

[0ptera]

Until this has a more elegant solution, could a setting be added to just disable the creation of merged deliveries?

Don't provide and request multiple items.

I have a working local implementation, but the license does not allow me to create a public PR without prior permission, as that would constitute a modified distribution.

PR are allowed unless they are are made with the intent of distributing modified versions.
However I don't need a PR to implement something as basic as a feature switch.

[0ptera]

Automatic scaling of locked slots has a circular dependency:

1. (merged) deliveries are reduced to fit train capacity using locked slots
2. locked slots should be set according to reduced (merged) delivery

If you have a robust and fast algorithm that can do this please open a PR.

[mutability]

Would you consider a PR that adds a provider-station control signal that limits the maximum number of merged deliveries that will be attempted from that station? Then you can, at least, limit the number of required locked slots for stations that provide many item types.

[0ptera]

I don't plan on adding such a signal.

[mutability]

Sorry, I worded that poorly. What I meant was: I'll probably implement that signal for my own use. Should I clean up my changes and submit a PR, or is this approach not something you'd want to merge?