[1.1.53] "Output Full" calculations break with result amounts > item stacksize

[Samuel2507]

Hello,

the logic determining whether the output of an assembling machine is full or not seems to break with result amounts that are greater than the stacksize of that item.

This results in the assembling machine stopping until the output slot is emptied completely. At the same time the machine state is on "Output full" and inserters can not load anything.

To reproduce this:
- Create a recipe which outputs an item with amount > stacksize
- Let the assembler craft it 2 times (until it stops)
- Partially clear the output slot
-> The assembler is not loaded and wont continue until the output slot is completely cleared

Test mod & save are attached.

[Samuel2507]

Another behaviour i noiticed with furnaces is that the input inserters go on "Waiting for space in destination" while the furnace is on "No ingredients". This happens about every 3-4 crafting cycles with recipes that have a result amount >= item stacksize.

Not sure if this is related to the issue above, but this can be reproduced with https://mods.factorio.com/mod/omnimatter_compression for example.

Context on the recipe:
1 compressed stone in, 1 stack of stone (200) out

[Rseding91]

Thanks for the report. Looking into this I don't think there's anything broken here. When the count in the output slot + the amount the recipe produces exceeds the stack size of the item it's counted as "output is full". In this case you simply need to remove the items from the output slot with an inserter.

[Samuel2507]

That partially makes sense.

The point where it gets problematic is that the input is not loded when the output slot gets cleared.
Input inserters stop until the output is cleared completely.

This results in a downtime of the assembler between unloading the last item and loading the empty input slot with new items and the crafting time of the recipe.

The result of this is kind of sad if you have entities that are designed to fill exactly a (proportion of a) belt. Even worse with mods like omnimatter compression or Deadlocks stacking where items can be compressed to versions of their previous stacksize which means all decompressing recipes are problematic.

[Samuel2507]

This can be seen pretty well on recipes that could potentially fill a belt:

Recipe in screenshot 1 has a crafting time of 10s and outputs 300 items. With a T3 assembler (1.25 speed) this should output 37.5 items / second and therefor easily fill a red belt with fast enough inserters.

Due to it not loading up any ingredients until the intial stack of ingredient items (3x recipe ingredients)have been cleared out AND the output is COMPLETELY empty, this results in a downtime of the assembler for the crafting time of the recipe if inserter speed is ignored.

Considering 3 crafts result in a downtime for the time of 1 craft, this means my assemblers are Not working 25% of the time (which is a lot).

[lyvgbfh]

This behavior is undesirable, especially if you have items with a low stack size. It essentially creates a cap on how active a given assembler can be, in the cases where this is applicable.

[netmand]

How is this an assembler issue it seems more like a recipe issue to me.

[FuryoftheStars]

That partially makes sense.
...
Input inserters stop until the output is cleared completely.

Well, yes. As you've stated:

with result amounts that are greater than the stacksize of that item.

And as Rseding91 said:

When the count in the output slot + the amount the recipe produces exceeds the stack size of the item it's counted as "output is full".

If your recipe output is > than stack size, then it's going to have to wait until the output is completely cleared. Probably lucky that they've even added a check of if output slot count = 0 (or similar) in order to keep it from deadlocking on recipes that produce more than the stack size. :/

How is this an assembler issue it seems more like a recipe issue to me.

If I remember the logic correctly, the assembler goes to sleep when output is considered full, and when the assembler is asleep, input inserters will not insert ingredients. Or something like that. The fix to this (aside from not modding recipes in this fashion) would be to allow sleeping assemblers to still accept input ingredients, but I'm not sure the reasoning behind disallowing it in the first place, so I don't know if this could potentially cause other issues by changing that.

[Samuel2507]

The fix to this (aside from not modding recipes in this fashion) would be to allow sleeping assemblers to still accept input ingredients, but I'm not sure the reasoning behind disallowing it in the first place, so I don't know if this could potentially cause other issues by changing that.

That would not help since you still have it blocked while the output gets cleared out completely down to 0.


There are 2 possible fixes in my opinion:

1: This is how i would most likely expect it to work like:
Output slot gets blocked when exceeding item stacksize (fine until now) --> Inserters clear the output
-->The assembler is no longer blocked once the amount in the output slot drops below stacksize again.

2: Ignore stacksize completely:
For recipes with result amounts way below item stacksize, the output gets declared as full after a certain amount of crafts. Since output slots are not limited to a stacksize, this would work just fine with ignoring the items stacksize completely for the output full calculation.

[FuryoftheStars]

1: This is how i would most likely expect it to work like:
Output slot gets blocked when exceeding item stacksize (fine until now) --> Inserters clear the output
-->The assembler is no longer blocked once the amount in the output slot drops below stacksize again.

Ok, so that sounds like a suggestion vs a bug report, but what happens if recipe result is close enough to int overflow that remainder output + recipe result causes an overflow? Gonna have to put a limit somewhere.

2: Ignore stacksize completely:
For recipes with result amounts way below item stacksize, the output gets declared as full after a certain amount of crafts. Since output slots are not limited to a stacksize, this would work just fine with ignoring the items stacksize completely for the output full calculation.

Too risky for int overflow, I would think.

[Wiwiweb]

Just stumbled on this behaviour too.

Thanks for the report. Looking into this I don't think there's anything broken here. When the count in the output slot + the amount the recipe produces exceeds the stack size of the item it's counted as "output is full". In this case you simply need to remove the items from the output slot with an inserter.

The inserters weird behaviour is interesting, but my main question is *why* does the machine's "output full" behaviour depend on the item's stack size? The output slot can already handle amounts greater than the stack size just fine when the recipe allows for it:

Screenshot 2022-05-08 135438.png (50.89 KiB) Viewed 1379 times

My suggestion is that the number of items in the output slot before the machine is considered "output full" should be `max(<current formula>, 2 * recipe_output)`

[Samuel2507]

Just stumbled on this behaviour too.

Thanks for the report. Looking into this I don't think there's anything broken here. When the count in the output slot + the amount the recipe produces exceeds the stack size of the item it's counted as "output is full". In this case you simply need to remove the items from the output slot with an inserter.

The inserters weird behaviour is interesting, but my main question is *why* does the machine's "output full" behaviour depend on the item's stack size? The output slot can already handle amounts greater than the stack size just fine when the recipe allows for it:

Screenshot 2022-05-08 135438.png

My suggestion is that the number of items in the output slot before the machine is considered "output full" should be `max(<current formula>, 2 * recipe_output)`

Is there even a difference between that and just 2* output_amount since the current formula is kind of based on 2* output_amount but limits on stacksize?

[Xorimuth]

Just stumbled on this behaviour too.

Thanks for the report. Looking into this I don't think there's anything broken here. When the count in the output slot + the amount the recipe produces exceeds the stack size of the item it's counted as "output is full". In this case you simply need to remove the items from the output slot with an inserter.

The inserters weird behaviour is interesting, but my main question is *why* does the machine's "output full" behaviour depend on the item's stack size? The output slot can already handle amounts greater than the stack size just fine when the recipe allows for it:

Screenshot 2022-05-08 135438.png

My suggestion is that the number of items in the output slot before the machine is considered "output full" should be `max(<current formula>, 2 * recipe_output)`

Yes I’ve run into this with X-Logistics. As you say, why does it need to involve the stack size at all? It should just be based on the current recipe output size.

[FuryoftheStars]

why does it need to involve the stack size at all? It should just be based on the current recipe output size.

Off-hand, it saves it a calculation step.

Stack size:

1. Stack size you already know is <= max uint, so you only need to check against that to determine if current output + recipe output will exceed overflow
   - If good, then proceed
   - If not, then hold

Recipe output size:

1. Recipe output size (let's say *2), you first need to check to see if recipe output * 2 is <= max uint
   - If good, continue to the next step
   - If not, then the next step needs to use max unit instead of recipe output size * 2
2. Use the result from the previous step to determine if current output + recipe output will exceed overflow
   - If good, then proceed
   - If not, then hold

Now I know what you're thinking: "Big deal. That's 1 extra calculation." And you'd be (sort of) correct (technically it's a calculation, followed by a comparison, and if it fails the comparison, an assignment of a different value). But that's an extra calculation over how many entities that you have running throughout your factory that would all now be affected by this? Especially when they start getting beaconed so they're finishing multiple times per second?

I'm not saying they won't or shouldn't do this, but I mean, they've already said no to (essentially) implementing an if check on entities if they have a defined energy source so that we can power previously unpowered entities without using composite entities because of the extra processing time that'd put on the vanilla game, so....

[robot256]

There may be other reasons, but computation time shouldn't be it. Recipe size doesn't change at runtime, so it can be computed and cached after the data phase. It would simply add some bytes to each recipe prototype, and change where the assembler logic looks for it.