[2.0.43] Inconsistent item count limit in assembler input slots

Bugs that are actually features.
Quintuple5
Burner Inserter
Burner Inserter
Posts: 5
Joined: Fri Nov 12, 2021 4:43 pm
Contact:

[2.0.43] Inconsistent item count limit in assembler input slots

Post by Quintuple5 »

Description

I have two saves with the same mods and mod configurations that both have an assembler trying to make the same recipe. Inserters are inputting the same item into the assemblers. This item has an automated insert limit of 400. In one save, the inserter gets stuck at 400 items. You cannot manually add more items to this slot either. In the other save, the inserter manages to insert an extra item so there are now 401 items in the assembler input slot. In this second save, you are able to add more items to this assembler input slot, for a maximum of 440.

I have no idea what the difference is between these two save files. Both were made from scratch in editor mode. Several people on the Py discord have confirmed they can load both save files without needing to sync mods or mod configuration, and they confirm the behavior above.

Step by step reproduction

Save file where the limit of 400 is respected:
- load messedupwtf.zip, syncing mods and mod settings
- observe that one inserter is stuck trying to insert 1 soil into the assembler
- observe that there are 400 items in the item slot in the assembler
- pick up a stack of soil from the bottom left chest, attempt to insert it into the assembler, and observe that this is not possible
- also see the limitrespected.png image

Save file where we can get more than 400 items in a slot:
- load limittest2.zip, observe that no syncing is needed after syncing the previous save
- leave editor mode (or play time)
- observe that the inserter adds 3 more items into the assembler
- observe that the assembler now has 401 items in the item slot
- pick up a stack of soil from the infinity chest, attempt to insert it into the assembler, and observe that the total number of items in the slot goes to 440.
- also see the limitignored.png image

Desired behavior

I would prefer the behavior in limittest2.zip, where the limit of 400 is exceeded. We found this issue because someone on the Py discord reported that their mall assembler inserter got stuck, because it tried to insert 400 of this item with two inserters, and it overfilled as per messedupwtf.zip. We can't see a good way to work around this behavior either if the limit were to be respected: as soon as you have multiple inserters and the automated inserter limit exceeds the stack size, your inserters are liable to get stuck. Even a single inserter can get stuck if the hand stack size is not a multiple of the automated inserter limit (or there's a temporary input gap leading to a swing with less than the hand stack size).

We conjecture that this change may be the cause of this behavior change, because we would have expected more people to have reported it otherwise: 116644
Attachments
limitignored.JPG
limitignored.JPG (37.98 KiB) Viewed 302 times
limitrespected.png
limitrespected.png (103.08 KiB) Viewed 302 times
limittest2.zip
(1.79 MiB) Downloaded 7 times
messedupwtf.zip
(1.84 MiB) Downloaded 9 times
Quintuple5
Burner Inserter
Burner Inserter
Posts: 5
Joined: Fri Nov 12, 2021 4:43 pm
Contact:

Re: [2.0.43] Inconsistent item count limit in assembler input slots

Post by Quintuple5 »

Someone on the Py discord just noticed that running /c game.player.force.technologies["inserter-capacity-bonus-1"].researched = true causes the first save to behave like the second save. Looks like the automated limit is no longer respected as soon as you research inserter capacity bonusses?
Rseding91
Factorio Staff
Factorio Staff
Posts: 15279
Joined: Wed Jun 11, 2014 5:23 am
Contact:

Re: [2.0.43] Inconsistent item count limit in assembler input slots

Post by Rseding91 »

The insertion limit also accounts for inserter stack size bonuses - in an attempt to keep inserters from getting stuck holding something.

In any case, there is no bug here. This is all working as intended.
If you want to get ahold of me I'm almost always on Discord.
Krydax
Burner Inserter
Burner Inserter
Posts: 9
Joined: Fri Jul 09, 2021 6:18 pm
Contact:

Re: [2.0.43] Inconsistent item count limit in assembler input slots

Post by Krydax »

Rseding91 wrote: Sun Mar 30, 2025 3:20 am The insertion limit also accounts for inserter stack size bonuses - in an attempt to keep inserters from getting stuck holding something.

In any case, there is no bug here. This is all working as intended.
There is a bug when you have *not* upgraded inserter stack size.

If you load the saves you can see that the issue is that the insertion limit is a hard limit at 400 (rather than 404) when the inserter stack size is 1 and no upgrades have been done.

It seems if you do inserter stack size upgrades, then it updates the hard limit to be [inserter hand size x 4], so that you could theoretically have 3 or 4 inserters swinging stuff towards an assembler and they wouldn't get stuck. This is great. This is the desired behavior

The problem is that this is NOT the case at the beginning of the game with no stack size upgrades. It seems the hard limit is locked at 400 and therefore inserters are getting stuck if they grab items at the same time (say from a warehouse) to insert into buildings that have an automated-limit that is larger than a stack of something.

So basically the request here is to make sure the behavior that happens once you start doing stack size upgrades applies to the entire game experience (not just after researching upgrades). As in a modded experience like pY, you are running into this bug prior to being able to research inserter hand size upgrades.

So I respectfully argue this is indeed a bug, as the behavior to prevent inserters from being stuck isn't applying at the beginning of the game when they are just stack size 1.

in the attached picture you can see an inserter hand being stuck. In vanilla factorio (not even modded).
03-29-2025, 23-59-28.png
03-29-2025, 23-59-28.png (955.25 KiB) Viewed 211 times
Locked

Return to “Not a bug”