CyclopsMC / IntegratedCrafting

Craft stuff in Integrated Dynamics networks
MIT License
7 stars 6 forks source link

ID Crafting not taking into account that the item stacks are above the normal size (64) #106

Open UnseenFaith opened 1 month ago

UnseenFaith commented 1 month ago

Issue type:


Short description:

I moved all of my items into Sophisticated Barrels with Netherite upgrades which increases their stack sizes past 64 (so you can store more than 64 items in a single item slot.) It seems like ID Crafting is only registering it as a single stack of items up to 64, instead of like how it works in the terminal where you can view all items. Not sure if this is known/intended.

Steps to reproduce the problem:

  1. Have an inventory with an item that stacks above 64
  2. Make a recipe using that item
  3. Crafting Planner errors out saying there are not enough of the item, despite there being enough

Expected behaviour:

The system should recognize that there are in fact more than 64 items in the system when crafting


Versions:

Log file:

Screenshots: image image image

rubensworks commented 1 month ago

Thanks for reporting!

rubensworks commented 1 month ago

Since this problem doesn't seem to occur with other storage systems that have increased stacksizes, I'm suspecting this may be related to how Sophisticated Barrels exposes its items via the IItemHandler interface. Could you open an issue at their issue tracker (with a link back to this issue)? I suspect they are limiting stacksizes in IItemHandler#getStackInSlot to 64, while the interface explicitly allows stacksizes >64.

Ideally though, they would implement the slotless item handler API, which would avoid the difficulties of exposing such storages through a slot-based API.

P3pp3rF1y commented 1 month ago

As I mentioned on my side the stack size is definitely exposed and returned properly, but I am guessing that there's a extractItem call involved and what's displayed in the gui is the result of how much can extracted and because extractItem contract specifies it should return at a max maxStackSize of the item that's what Sophisticated Storage does. It's a relatively new fix (6 months back) for an issue that occured with some other mod so this would have extracted more than max stack size in the past.

rubensworks commented 1 month ago

I see, thanks for the input @P3pp3rF1y!

extractItem requiring returned stacks being capped to 64 is quite annoying from my end, but there's probably a good reason for that. (what problem did it cause on your end? I'm just curious here)

Note to self: as getStackInSlot is not capped to 64, we could detect cases where extractItem returns 64 but we could extract more. In those cases, iterate multiple times over extractItem, which will have to be done in CommonCapabilities's IngredientComponentStorageWrapperHandlerItemStack.

P3pp3rF1y commented 1 month ago

@rubensworks this is what I have for that change in changelog, don't recall specifics but sounds like thermal just counts on item handlers working per contract definition. I am pretty sure that before this fix it caused everything over maxstacksize to just be thrown away.

"Fixed item handler extract methods to extract maximum of max stack size of the given item that's being extracted. Fixes bug where thermal machines would be able to extract more than maxstacksize stacks from storages that had stack upgrades applied to them"