CraftingMachinePrototype.drops_full_belt_stacks

[protocol_1903]

Similarly to this thread, I would like for a way to force crafting machines (both furnaces and assembling machines) to drop full stacks of items onto belts. This feature has already existed for inserters and mining drills, and was recently added to loaders. I would like to use this feature on crafting machines, in some cases where mining drills are emulated, in others where high throughput is desired and mismatched stacks can create bottlenecks. Particularly the recycler, where creating high throughput stacked belts requires the careful management of stack inserters and containers depending on the designed layout.

Of course, this flag would only be applied when the crafting machine has vector_to_place_result, and require the correct feature flag to be enabled.

I can see this getting denied due to how crafting machines with multiple output slots, particularly variable outputs (looking at you, recycler) could complicate and slow down the relevant logic, introducing potentially disastrous performance impacts if added. If that is so, then confirmation of such would be appreciated so we at least know why this request was denied.

[MrSmoothieHuman]

+1, I plan to use vector place results a lot in my mod(s), and the fact they cant drop stacks is annoying - especially considering in my context, they are high-powered machines designed for bulk throughput

[boskid]

There is a significant difference between inserters, loaders and crafters in terms of how this could be implemented. Inserters have a held stack which means they can accumulate items to be dropped in the held stack. Loaders do not have a held stack so i had to do some trickery around their logic to make it possible to drop full stacks which consists of 2 separate features: not dropping an item if the total in the inventory is below a stack size, and second part being inserting item from first available stack onto a transport line, and if the insertion was successful, inserting more items into an item stack on the belt from other source inventory stacks. This is slightly easier to be done with loaders since they are inserting at the transport line back, having the same work with crafters dropping in the middle of a belt would require some extra code refactoring just so item insertions would report stack on transport line that was created. Doable but adds extra overhead in the logic. Also there is a significant problem if mods would enable this on base game entities, for example inside of recyclers: if they would be fed with different items that recycle to different products, then since recipe products are locked to specific result inventory slots, it could happen that drop waits because of the stack not being full, and crafter waits because there are still items in the products inventory that are colliding. I do not want this to be happening.

[protocol_1903]

+1, I plan to use vector place results a lot in my mod(s), and the fact they cant drop stacks is annoying - especially considering in my context, they are high-powered machines designed for bulk throughput

They can drop stacks, however they can't be forced to only drop full stacks, which was the point of this request. If there are enough items in the crafting machine output it will drop full stacks, but it cannot be garunteed. pY ensures this by forcing the recipes of relevant machines to craft multiple items at a slower speed, resulting in full stacks in most applications, I'd recommend doing the same.

There is a significant difference between inserters, loaders and crafters in terms of how this could be implemented. Inserters have a held stack which means they can accumulate items to be dropped in the held stack. Loaders do not have a held stack so i had to do some trickery around their logic to make it possible to drop full stacks which consists of 2 separate features: not dropping an item if the total in the inventory is below a stack size, and second part being inserting item from first available stack onto a transport line, and if the insertion was successful, inserting more items into an item stack on the belt from other source inventory stacks. This is slightly easier to be done with loaders since they are inserting at the transport line back, having the same work with crafters dropping in the middle of a belt would require some extra code refactoring just so item insertions would report stack on transport line that was created. Doable but adds extra overhead in the logic. Also there is a significant problem if mods would enable this on base game entities, for example inside of recyclers: if they would be fed with different items that recycle to different products, then since recipe products are locked to specific result inventory slots, it could happen that drop waits because of the stack not being full, and crafter waits because there are still items in the products inventory that are colliding. I do not want this to be happening.

The reasonings given make sense and the concern is fair. Thanks for the quick reply!

[Eulenberg]

+1

[protocol_1903]

Thinking about it some more... Since all of the issues come from furnace interactions, would it be possible to just add for assembling machines?

[boskid]

Thinking about it some more... Since all of the issues come from furnace interactions, would it be possible to just add for assembling machines?

Ignoring implementation details that the dropping logic is on the crafter class (parent of both furnace and assembler), it would have to be implemented on the crafter but it could be restricted to be possible to enable only by the assembler. I am still not willing to implement this because this will be inherently error prone due to feedback loop that may cause crafter to stop crafting if the items are present in the crafter output inventory and this logic by design asking for output inventory not being emptied until there is certain amount of items. If a mod would set a recipe to have a really small overload_multiplier, then it could happen there is an item in the crafter output with a count of 3, crafter would stop crafting because it is output full but drop target would not drop the item because it is less than a possible belt stack.

I simply do not want to be implementing this because it has bugs in it by design that will get discovered and then reported, and the only way to handle those edge cases would be with more cpu power to compute what is the overload threshold for current recipe at current crafting speed to decide when to drop at a smaller stack which will also get reported as a bug, or to make crafter intentionally dump everything when not crafting to unstuck itself, that is also likely to get reported as a bug. Current state of this modding request is lacking resolution around this corner case and i do not want to be guessing because there is a high chance i will guess incorrectly and bug reports will come from it.