Functional Storage

Functional Storage

Mods
24M Downloads

[1.19.2] Void drawers report wrong capacity

tofof opened this issue ยท 0 comments

commented

Functional Storage Version: functionalstorage-1.19.2-1.1.10

Titanium Version: titanium-1.19.2-3.7.4-30

Integrated Dynamics versions: IntegratedDynamics-1.19.2-1.22.0, IntegratedTunnels-1.19.2-1.8.27, IntegratedTerminals-1.19.2-1.4.13.jar, CyclopsCore-1.19.2-1.19.1.jar, CommonCapabilities-1.19.2-2.9.1.jar

Forge version: 43.3.13

JEI version: jei-1.19.2-forge-11.6.0.1019.jar

Modpack: Behavior originally identified in FTB Skies Expert 1.8.1 but reproduced using a separate instance running only the mods listed above.
image

Observed behavior

Drawers with voiding upgrades report their capacity as the sum true capacity + maxint (2.147e9) which breaks displays (of other mods, tested with Integrated Terminals) of storage capacity available.

Steps to reproduce

  1. Place a 1x1 drawer.
  2. Place an IntegratedDynamics Item Interface on the drawer using shift+rightclick on any face
  3. Attach an I.D. Logic Cable to the interface; they occupy the same block.
  4. Attach an I.D. Storage Terminal to the logic cable; it also shares space within that same block.
  5. Right click the storage terminal, left click on either tab (top left, a chest / crafting table), and observe the inventory available: 2048, as expected.
  6. Install a void upgrade in the drawer, then check again: 2,147,485,695, which is 2^31-1 + 2048.

Expected behavior

The storage controller displays a storage of 2048 (or whatever value is accurate depending on both installed item (e.g. bows vs planks vs ender pearls vs clay balls) and capacity upgrades or downgrades.

Discussion

I understand this is probably an artifact of this behavior, #27 (comment)

Just as a heads up, some mods check if the inventory is full before sending items which is good and bad at the same time, and I need to work around it to make them believe it can hold more.

and probably this code,

FunctionalStorage/src/main/java/com/buuz135/functionalstorage/inventory/BigInventoryHandler.java

Lines 96 to 106 in 35b717b

public int getSlotLimit(int slot) {
if (isCreative()) return Integer.MAX_VALUE;
if (type.getSlots() == slot) return Integer.MAX_VALUE;
double stackSize = 1;
if (!getStoredStacks().get(slot).getStack().isEmpty()) {
stackSize = getStoredStacks().get(slot).getStack().getMaxStackSize() / 64D;
}
var slotAmount = type.getSlotAmount();
if (hasDowngrade()) slotAmount = 64;
return (int) Math.floor(Math.min(Integer.MAX_VALUE, slotAmount * (long) getMultiplier()) * stackSize);
}

and that you probably don't wish to implement specific compatibility patches for the various cable mods (mek, ae2, id, etc). Unfortunately this has the effect of rendering two high-value features (voiding drawers and seeing inventory capacity) incompatible.

One possible workaround: a config variable that controls how much to pad the reported storage by to ensure that modded pipes continue to see it as a valid target to send items to. The value could continue to default to maxint.

In my case, nothing I have progression through would support more than moving a normal stack (64) at a time, so padding the true value by something like 640 would ensure that even if ten sources try to send a full stack of the same item to the drawer on the same tick, it would still report adequate capacity (I don't know enough of the per-tick flow to understand whether the extra factor of 10 would even be required). My display of available capacity would still be inaccurate, but would at least still be on the order of the true value. Right now, every single voiding drawer I use adds an additional 2B which drowns the true value (<10M) in noise. I could easily live with overstated capacity on the order of hundreds or thousands -- using drawers at all already introduces this sort of uncertainty since the actual total capacity depends on what type of item I want to insert (whether I have empty drawer space for it specifically, for example).