[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 7741 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.

[mjg123]

I'd like to add a note that this is at least a surprising behaviour, and until I found this thread I thought it was a bug (well, I still do but at least I have read the discussion ).

It especially affects mods like Freight Forwarding which have low stack sizes for raw goods, but recipes that can pack and unpack lots of stacks into a container. The end behaviour is that even given an adequate supply of containerized inputs and a machine that can easily run the un-crating recipe fast enough, there are breaks in the output.

It would make sense to be able to insert another input whenever there would be space in the output slot for it, regardless of stack sizes IMO.

[TripleOmega]

It especially affects mods like Freight Forwarding

I am currently experiencing problems with this bug while playing this mod. I setup a battery unpacking system that directly fed a machine that generates power from charged batteries. When the charged batteries in the output were expelled the unpacking restarted, but the unpacking couldn't finish before the power ran out resulting in the unpacking machine stopping and everything grinding to a halt.

This is another great example of continuous item flow being a requirement for proper operation. Not having this creates a lot of undesirable side effects.

[wretlaw120]

I would also like to express a desire for this behavior to be changed. There are some recipes in Space Exploration that can produce more than the stack size of the item in a single recipe cycle, and will stall the machine. I find this behavior very frustrating.

[grandseiken]

I'd also like to see this changed - it ends up getting in the way quite a lot in a mod I'm working on (as well as being pretty confusing for the player).

The current behaviour feels inconsistent to me:
* it's impossible for a machine making a recipe that produces more than the stack size to keep working all the time, since the input inserters can never run at the same time as the output inserters
* there's no such restriction or throughput problems with input stack size - input inserters will happily insert 2X the required amount of an ingredient item, regardless of its stack size
* it breaks the usual "rule" that inserters will insert enough for 2 crafts (or so). Especially if the recipe has multiple ingredients, this feels very strange. Lacking ingredient B, inserters will happily insert ingredient A until enough has been stockpiled for 2 crafts. If the machine then receives a surplus of ingredient B and begins working, the inserters more or less switch off completely until the machine has worked its way through all those stockpiled crafts and been completely drained to empty (of both ingredients and product)

I believe this earlier suggestion would fix my use case at least:

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)`

[briermay]

as a developer myself, the simple fix imo would be to simply remove the "feature" of inserters not putting items in when the output is full, and simply guarantee the machine does not run if output full. if you manually shove items into an assembler it will run to a certain point as is and stop anyhow. if I keep shoving items in it works fine. so why not simply have inserters do the same by putting in whatever inputs it would (totally empty inputs and outputs) regardless of output full same as if shoving them in manually.

this would prevent the int overflow that was tossed out as a reason, while still allowing inserters to put items in, and once the output is cleared, the assembler would kick in, removing the downtime issue.