Fix drawer mods compatibility

[esbraff]

Unpacking logic changes

Items are compressed into bigger stacks (as in, 8 stacks of 64 apples will be compressed into 1 stack of 512) before running check for whether items can be inserted, then it tries to fill target inventory with these stacks, while overwriting the stacks with remainder. By the end, if there's still some items left, consider that package can't be unpacked into target inventory

Some storage show inconsistency between simulate and actual pass, which is largely bug on the storage mod side and can lead to voided items in some cases. Instead of voiding items excess items are stored in the list and then dropped on the ground, so that they're at least not being lost forever

[Doppel-R101]

Am I understanding this correctly that this is about packages being unloaded into storage drawers?

[esbraff]

Yes

[Doppel-R101]

then to keep the behaviour like other packager interactions, the package should not be accepted, if it can't be inserted into the storage, rather than dropping the items.

[esbraff]

It will try to not accept the package if the method returned false with simulate on, but this is not always the case. There are very specific cases when storage can't properly tell if items can be taken, one of which I described in the first message. Those cases are rare, but they still have to be handled. And the reason why I mention it is because original code had comments addressing this issue

[esbraff]

output.mp4

Here's example. The drawer is unable to properly tell what is its slot size until there's something in it, while drawer is empty it considers slot size to be default, which is 64 in this case, because of iron downgrade, but when ender pearl is pushed in slot size gets shrinked, because ender pearls have lower max stack size. And to avoid excess ender pearls getting voided I made it so they drop on the ground. This should happen rarely and not repeatedly

[VoidLeech]

I'd say that for what is supposed to be an automated system, dropping items on the ground is no better than voiding them outright.
Considering the simulate pass works on the slot level, is there not just a bug in there instead that it suggests inserting all that is possible?

[esbraff]

I'd say that for what is supposed to be an automated system, dropping items on the ground is no better than voiding them outright

I agree, but it happens extremely rarely with storages that can return wrong results on simulate pass, for example empty drawers, because of max stack size difference, so should only happen once when setting up logistics, not constantly while automation is running. Also voiding items is unacceptable from player pespective, while having some items dropped on the ground in such case sounds okay

Considering the simulate pass works on the slot level, is there not just a bug in there instead that it suggests inserting all that is possible?

Well there's definitely some issue on storage mod side, Functional Storage doesn't check new stack size with inserted item on simulate pass. But even if they fix it there's still some mods that could have similar issue and I think it would be better to handle small issues on create side, rather than making unpacking into those storages impossible

[esbraff]

Also I'm assuming that for most storages simulate and regular pass won't have much difference outside of very specific cases, like the one I described earlier. If that's not true I would consider that there's major issue on the storage mod side and having items dropped on the ground isn't the worst thing that could happen

[esbraff]

I'd say that for what is supposed to be an automated system, dropping items on the ground is no better than voiding them outright.

One more thing I can add to this - dropping items on the ground will only be caused by the storage not being to properly tell if items can be inserted during simulate pass, so if that happens it's not an issue on create side. As of now drawers are fully incompatible with packagers, create will refuse to insert items whatsoever, because the code for unpacking assumes that there's no slots that can hold more than item's max stack size, so regardless of if items are being dropped or packager is being unable to push items into the storage, player might want to give up on using this storage solution, but in the former case the issue is caused by the storage mod, while in the latter case it's caused by create

[esbraff]

As of my current testing I only know one situation when items will be dropped on the ground - putting items with small max stack size into empty drawer. This happens because during simulate pass FS drawers don't check what is gonna be a new item in the slot and what is its max stack size, so it uses default max stack size and can give wrong results, so it's something that can be fixed on FS side

[Doppel-R101]

I agree, but it happens extremely rarely with storages that can return wrong results on simulate pass,

Then a fix should be applied to storages not returning the correct amount of storage space, rather than bypassing the issue and voiding/dropping the items.
Depending on the scale of a network, this can lead to performance issues too.

[esbraff]

Then a fix should be applied to storages not returning the correct amount of storage space, rather than bypassing the issue and voiding/dropping the items.

It's impossible to do. You will never know how well the storage checks this on simulate pass. And introducing mod specific compatibility for those mods is not feasible

Depending on the scale of a network, this can lead to performance issues too.

No, it can't. As I said, it will not happen constantly. I described earlier that the only case I know is empty drawers with reduced stack size (using iron downgrade), empty as in not even being locked to specific item, this is something you will never see in your actual automation setups

And you're not choosing between working properly or dropping items right now, you're choosing between drawers not working at all, because of original issue with it not handling big slot sizes properly, or having items dropped on the ground in some edge cases that are unlikely to happen in your automation

Should I even say that in both cases you would just give up on this exact storage solution and switch to something else? But while the original issue persists, this is fault on create side and with my suggested solution any items being dropped on the ground would be issue on the storage mod side, since its results on simulate pass are not consistent with actually pushing items in

[esbraff]

output.mp4

As a side note - apparently AE2 does same thing as the solution I suggest, but... it voids the items instead of dropping them

Definitely not an issue on AE2 side. I already reported this on functional storage repo

[esbraff]

Here's AE2 code that handles pushing items into storages during autocrafting. Pretty much same thing, but it uses insertItem instead of insertItemStacked, so that items are filling first slots instead of trying to complete existing stacks, which can be nice for automation purposes

[esbraff]

I found major issue with handling multiple similar stacks in my solution. My bad, will fix it in a moment

[esbraff]

Should be good now. I tested it with vanilla chests, limited barrels, ars nouveau pedestals, ME interfaces and drawers. All worked fine except the issue with drawers I described earlier, but it comes from FS side

@VoidLeech I think dropping items on the ground should stay there. It won't happen during automation in realistic circumstances, but it's there to help with some rare edge cases when storage fails to tell what it can accept, which usually leads to voided items