Parameterise locked chest slot count

[ilikegoodfood]

TL;DR

If a chest has locked slots please allow the number of locked slots to be parameterized when a blueprint including the chest is made.

What?

Additionally, the parameterisation of multiple chests with locked slots can be differentiated or grouped based on the number of locked slots at the time of blueprint parameterisation.

Why?

When bulding assemblers it can be useful to lock a number of slots on the output chest to control the amount produced and stored.
Currently, the recipes of assemblers can be parameterised, and the outputs of those recipes can have different stack sizes. Furthermore the player may wish to store different amounts of the output each time the blueprint is placed, even when for a duplicate recipe.
Using parameterisation, it is possible to control the output quantity of an assembly machine into a chest using an inserter and the circuit network, but not using the locked slots feature of chests.

[dmikalova]

Do you have an example of a recipe/situation that this would benefit from? My current parameterized blueprint I set the inserter to fill to 10 stacks since the parameters have a stack variable. For recipes I want to limit like personal fission reactor I just manually set those to 1 stack after placing the PBP.

If the PBP could parameterize locking stacks, how would that work? Would you want to set a number every time you place the blueprint? If you wanted by number of stacks you can already do that with the stack variable and inserter limit. If you wanted it dynamic by recipe you would need something like setting a constant combinator with the recipe amounts and have that set the limit, which is not what is being asked.

[ilikegoodfood]

Using a fixed lock count, as you mentioned, is possible, and is perfectly viable once you have very large amounts of resources available, or for things that you will always want available in bulk.

The reason for my request is two fold.
When you do not yet have large amounts of resources available, but have started using bots extensively, somewhere around the late starter base, there are recipes that are very expensive and that you need very little of, but are also best built using bots, such as rocket silos, personal reactors, personal battery mark 2s, or power armour itself.
For those recipes, and especially at that stage of the game, making ten stacks of them can be a large resource investment that you're not yet wanting to make.

Technically, limiting the output to a fixed amount, or stack count, with an inserter is trivially easy, however, it adds a non-zero performance hit that can be noticable for very large bases or multiplayer games. Using locked slots is better in this case, but does not have feature parity with the circuit condition. The prior can be automated as part of parameterisation, while the latter cannot.

As for how I forsee it working, let's use a simple two chest bot assembler setup as an example, such as the one in this image:

Capture.PNG (614.31 KiB) Viewed 341 times

Instead of linking the inserter to the output chest and having it disable itself when the desired output amount is reached, you would lock 1 slot in the output chest.
When setting up the parameters, assuming that the recipe is parameter 0, and the number you wish to store is a variable called Count, you could use a formaula to calculate automatically how many slots need to be locked. That would be `48 - (Count / p0_s)`, rounded up.
Alternatively, if your blueprint requests the stack count rather than the specific number, it would just be `48 - StackCount`.
Whichever way you run the calculation, the result is a number of slots to lock that leaves the chest with a number of unlocked slots equal to number of slots required to hold that number of item stacks.

if your blueprint contained multiple chests with 1 locked slot, the parameter would effect both chest. If it also had two chests with two locked slot each, then those chests' locked slot counts would be a single parameter between eachother, but would be distinct from the parameter for the chests with a single locked slot.
Visually, each chest with a unique number of locked slots would show up as new line in the parameterization window with an intial value of 1, or 2, or whatever.

Alternatively to the value being the number of locked slots, it could be flipped so that it is the number of unlocked slots that is counted and modified, making it robust against chests of different sizes being effected by the same parameter. That would also simplify the equations to just `Count / p0_s`, or `stackCount` respectively.

I Hope that I've managed to answer your question somewhere in there.