[2.0.17] [SA] Stack inserter behaves wierdly with hand size overrides

[Hares]

Context: I am designing clocking-safe rail system for delivering fruits on Gleba with minimized raw fruit spoilage. This is the crane cell design I came up with:

11-14-2024, 16-43-55.png (599.48 KiB) Viewed 666 times

The settings on the stack inserter are:

• Hand size: 10
• Circuit network: Set filters
• Filtering mode: Whitelist
• Spoilage priority: Not set

Circuit network provides either fruit+spoilage signals, or nothing. The signal is sent when specific conditions are met, most notably -- the number of fruit items on belts. To prevent inserters having items in their hand, I set the hand size to be a factor of fruit stack size -- 10, which means, that if the crane started with full stacks of fruits (which it does), stack inserters will be always able to grab a full hand of things.

However, I noticed that sometimes stack inserters are left with items in hand in quantities other than 10. Furthermore, the sum of number of items in hand AND number of items in the crane is also not divisible by 10 -- in the video attached it's 4 in one hand, 0 in other hand, and 0 in crane. Which means that either fruits disappear (which they don't), or cranes created a non-full stack of items (which isn't possible at least because these cranes are deployed outside of plantation field), or inserter made a non-full-hand item pickup.

Click here to expand the video

Blueprint:

0eNrtXEtv3DgM/iuGgQVawJNasvwKtpc9Lfawh+0xDQYejybR1mO5kpw0G+S/L2WPMy/PRJLT5pJTObbMj6RImhbZPPqLqqWNYLXyLx/9JZWlYI1ivPYv/VulGnn56dOKi3YtL1ZFqbhg/KLk608II4Kjr/XX+m+uqKduC+XBOiCY9CRVbeMp7gnaVKwsugXUW9Db4o5xEXiRx1ce8UpR1FR6H4qq8hatgieaWUVX6qN3TwX1Kl4s6dK7Z+rWw96qhVVSFeU3qZ/+l1bVQ92qC+8fkJ8v2xKWrttKsaYCOLamMugfBWhJPfoDxPfqdr2gQmrBhmdQGP6mGRZK0XWj5MXX2g98VvJa+pdXj75kN3VRaevUxZqCWVQrFnymQHbZcKFmC1op/wkeqZf0h3+JnoKRh4obwUqQrhVFNVMc9Nt5BD9dBz6tFVOM9qDdj4d5Ly7wDAY+sl2ADboNCvyGS9bv1aOvkUNY9+BfznD2pIU4YIKfmQj6vaVSUTErwTZqjFN4EW94JRcxSArmUIJX82EP9cKSibJlar7mSzrnqzlvqOhF01jDXXhy2fGe07pYVHTpX66KSlJgupFjvmIVCCM1T0lLvba3wmDRwH9esXd1o87gCjNJgXvgf2+LChSHOzUXa9gGLf66KUA4Lbj/ubvQapePteVvBG8buH7FwAM+73G79v6Cny389L7AT+nr9bD18nZeczUfDAk6KdHSHY0EX88X7WrVCa3vje1I9KzCqpBqxmpJBag5urMH+7FkorcU3MTnt+fZ7L2IR/ui166YAKmPvHbfsr0bgPt1ljsw6u8+aPja+6St3Uq6dZDOkseGJMGZOBuxZvRszfSkdwtaLLWRFGCd2cPYeA9R/r6HZ/YwMctxKD+X41KLHIey9xz383NcZheaGL1eaOZbjwILVbOqWDfns0EMkCOMULjlpAuQs5ka73E771VQKB3GxXGsBD6/o0IwcMAOHUL8P6qRxiTdesxomXJWe3KYlbIxBGxhC/KmtojM9n/H5U7tP7G16g5PM6vG5lbF4ZtaNbGQ9G1jIZ0QC/hw18gYQnaAIOFzR72YF4gB53yC7JGJx+HQGiE+bZ1RBPtcROzsj7GF/ckp+yM8xjqyFj45Lfw4hHVWCVNbiNgaIrOFSKwhclsI60BGoS1EZg2BbCGsQxphS4jIOqZRZAthHdQotoXA1hDEFsI6upFt6EXW0Y1sE0hkHd3INvQi6+hGtgkkSicUV4YQ1tGNbRNIlE/QwuiFTULzl92O+AbFBkEWnLHVa5TgCVUGMjJLNAEhNEIg7gg64AwQ4gkImRFCMgHh6LSKnK/ku8/z26I+/EbfOy/prvdL9dmKPgQfkzudIHd6ZJlfJ3fmXj6O2HsMIXevHs0Q4tC9eDREQO61oyECdq/rDBEi9+LUEIG4V3WGCLF7aWqIkLiXjYYIqXvVaIiQuVd0hgj5hGz38gnLK+a3ZMLpgbb7KM9tNhhaFLOSrxes7s60z6YbYtpQ2Z69TzuHtzuC73rCQ7N3e37WcFYVN9SW18nj/P4kX1PebSHuqFSsvvE+9C0h+dHfl+Ksnq6yjel5z/nSnc/OKa7i9QSBds7GmeD1bFGUoD8rJnDE+xy5mCJetO9kEyy/G0hNQ8UrqLpz1LbhOUlZfbymHpq+UVeyRrPasH9o18U3PmsEL6mU4MCTw0P737X35zYiWA15BDj+13XydgIk8MFQ7I4O7bvrp9FEtdsCobQ63WF8OedFpqzIi6y2ZcKirc6ey6P9t8YYs9icGXmRWWKqZPKikqm5XMmLcm1f6IIvuH57HfPJ00Eii2audpwRvCmvdzyuQzrlRRyd4LnNH0sIzqXuoZ99D28/LIjRB9eG67Zt3lly99fVi+MM+5MMKAx13PNWNa06nNvaJJo7JlTb5Y7BGbsVM3pHxYO61ZkGeNZU3XPxTfZ95qGRr1MKpfXQax7PCyl2L2CiX13AOAwSaLe+1lNrcq4l7FPkmB0mHMnoz69RnlMOYcITPGOH+avsfXTn2JCJ02hh9j5187OmbtLUbmIUhaNcMte5unzq7E464V2ZjYd7NuFVmZ9giRym/94zyIghsdPg3nsG+Xlze5HdPOZ4BsmI6/jf5AySxe4jNIlJTyVLXKYC018/CJWltoOQ6Yl0l7ln0OQEywl5/oSUeegyofgG+5Ij956xkYfm2HYC8pRJI5fxxLcwKXGZTnwLQSdkJ2LSS8gTd4DYyLlSl+HHxEDyCVnmxLFRPiHLnJwJD93HG412sCvO7ccbE4OxDNgQ9/40MRqIAXdyb1CbQhD3DrUpROzeojaFSNw7yKYQqXsb3BQic+8hm0Lk7o1wQwgUuvepTSGQe6PaFAK7jzeaQkTuzXBTCOI+3mgKEbuPN5pCJO5FnilE6j7eaAqRuWthVE2go//xYDTeaFBOIBy6jDcev0bh6/oeLugP/SsUoCAJ0HXQUWm6ITFcxBsKUslAwv2ejOF+vKHgoiYjeJ50j8dAZR2VaCrakMAp7h7XJFztyViTHatQr8A9QKzpXgSil5N0S8d5R+t/ghT1bNAOjbVKG9CO7vXTl/QaTada1I0yqRY37eXV+g8C69uDmD2dDPSzzJk2WtZrrZcGeb9eLw3y3m55d50ADXbXhx+65ff8twoCvyrA8eDaH+3NrP9jBJfeF111e0PJL72a17P+zwbc931kKM9lt51xgnOS5zGJo5jo/0r6PyAEneY=

Copy blueprint

Note that for this setup to replicate the behavior, 3 of 4 cranes (all but top-left) were loaded with 2 full stacks of jellynut. Reproduced multiple times, with these exact numbers reproduced 100% of attempts.

[robot256]

Another potentially related report of a stack inserter getting stuck when items are available: 118138

[Hares]

Another potentially related report of a stack inserter getting stuck when items are available: 118138

I checked that topic before posting this and it's not related.

[robot256]

I know it's not a duplicate, but when they mess with the code to fix one they will probably find what is causing the other as well.

[Hares]

Bugfixes:

• Fixed stack inserter would start dropping partial held stack when waking up by control behavior. (122439)

Similar issue reported in 2.0.20 & fixed in 2.0.22.
The issue mentioned in this topic, however, reproduces on a newer version. Same steps-to-reproduce.

[boskid]

The only suspicious thing that i may need to investigate is that i see inserter not dumping hand content onto belt when filters are cleared but the bug report seems to be focusing on something different: specifically on the hand size override and full hands. Stack inserters when dropping onto a belt were specifically made to grab less to match belt stack size, which is achieved by a prototype flag set on inserters, a InserterPrototype::grab_less_to_match_belt_stack (i tried to come up with a self explanatory name here). That means that even if you have those stack inserters set with stack size override of 10, it only grabs up to 8 items since that is a largest multiple of belt stack size that can be dropped without leaving a partial stacks on the belt.

[boskid]

Ok, for 2.0.23 i did one change: when filters are set causing held item to become incompatible, inserter will enter drop mode to get rid of the held items. This was the only bug i was able to identify in this bug report. Hand size override behavior seen here i am considering to be correct.

[Valeskas]

That means that even if you have those stack inserters set with stack size override of 10, it only grabs up to 8 items since that is a largest multiple of belt stack size that can be dropped without leaving a partial stacks on the belt.

If its not a technical limitation, then its really weird.
Player can easily enter a multiple of belt stack if so desired.
The only scenario where I used stack size override, is to move biter eggs from platform hub, to make batch size divisible by stack size.
And it may unexpectedly spawn biters, as this behavior not at all communicated by the game, might leave some eggs in the stack inserter hand.

[Hares]

Ok, for 2.0.23 i did one change: when filters are set causing held item to become incompatible, inserter will enter drop mode to get rid of the held items. This was the only bug i was able to identify in this bug report. Hand size override behavior seen here i am considering to be correct.

If stack inserter has a filter for a spoiling item, and picks up incomplete stack, and that item spoils while within the hand -- does that mean the inserter will enter drop mode as the spoilage does not pass its filters, or is that event triggering only on circuit network/configuration update?

[boskid]

If you set stack size override to 10, items that cannot stack that high are still getting transferred at a lower stack size, would you also consider that a bug because inserter does not obey its stack size setting? My understanding of the inserter's stack size override was that it is to ignore bonuses above certain amount so it behaves as an inserter with smaller stack size bonus, in which case a stack inserter with lower stack size would behave exactly the same way: it would grab less to match belt stack.

[Hares]

If you set stack size override to 10, items that cannot stack that high are still getting transferred at a lower stack size, would you also consider that a bug because inserter does not obey its stack size setting? My understanding of the inserter's stack size override was that it is to ignore bonuses above certain amount so it behaves as an inserter with smaller stack size bonus, in which case a stack inserter with lower stack size would behave exactly the same way: it would grab less to match belt stack.

If I intentionally set the hand size override to 10, I assume SI dropping items in batches of 4,4,2; not 4,4,4 because that's the exact amount I want it to grab. Also, does that feature/behaviour/limitation occur only when dropping onto a belt, or when dropping into a chest/container/machine too? If the latter is correct, then that's double weird.

[boskid]

If stack inserter has a filter for a spoiling item, and picks up incomplete stack, and that item spoils while within the hand -- does that mean the inserter will enter drop mode as the spoilage does not pass its filters, or is that event triggering only on circuit network/configuration update?

Item spoiling in stack inserter's hand will make inserter to drop whatever it has without waiting for more (this behavior is enabled by InserterPrototype::enter_drop_mode_if_held_stack_spoiled. If you manually insert incompatible item into inserter's hand and it does not match current filters it will unconditionally try to get rid of it as inserter has nothing to do with it, would not be able to grab more of it due to filters. Bug that was fixed for 2.0.23 was that this logic was not guarding filter changes: before it was only triggering when incompatible item was detected due to held stack changes, with the fix it will also be detected due to filter changes.

[boskid]

If I intentionally set the hand size override to 10, I assume SI dropping items in batches of 4,4,2; not 4,4,4 because that's the exact amount I want it to grab.

I see, in that case i am moving this topic out of Resolved for the next release (+removing link from the changelog to avoid confusion) and moving it to Not a bug because this is what this topic is about and right now it is working exactly as it was designed to work. Stack size override was never meant to force inserter to grab exactly that much or do nothing, it can grab less if item does not stack to that amount. There are also corner cases where you have an inserter from a blueprint and stack size override is above the currently researched stack size bonus in which case inserter will use the lower value of the two in which case using a proposed logic inserter would be forced to drop partial stacks until proper stack size is unlocked just because inserter is told to obey the stack size while not being able to reach it. If you do not agree with current behavior then i suggest opening a suggestion topic where this can be discussed in a slightly more open atmosfere that does not suggest this behavior as being a bug.

[Valeskas]

If you set stack size override to 10, items that cannot stack that high are still getting transferred at a lower stack size, would you also consider that a bug because inserter does not obey its stack size setting?

No, it is something of a common sense, that if unstackable items like promethium chunks are too big to be stacked, then they are too big for stack inserter.
A bit obscure, but not weird.

What reason is there for stack inserter to not obey the engineer in case of conveyor belt stacks?
I cant think of in-universe reason and/or game balancing reason.

It was not obvious to me that it was designed that way, thanks for clarifying.

[Hares]

Also, does that feature/behaviour/limitation occur only when dropping onto a belt, or when dropping into a chest/container/machine too? If the latter is correct, then that's double weird.

I tested it, and when dropping items to chest, it uses the exact override value.