Modpack: Behavior originally identified in FTB Skies Expert 1.8.1 but reproduced using a separate instance running only the mods listed above.
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
Place a 1x1 drawer.
Place an IntegratedDynamics Item Interface on the drawer using shift+rightclick on any face
Attach an I.D. Logic Cable to the interface; they occupy the same block.
Attach an I.D. Storage Terminal to the logic cable; it also shares space within that same block.
Right click the storage terminal, left click on either tab (top left, a chest / crafting table), and observe the inventory available: 2048, as expected.
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.
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 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).
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.
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
Item Interfaceon the drawer using shift+rightclick on any faceLogic Cableto the interface; they occupy the same block.Storage Terminalto the logic cable; it also shares space within that same block.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, https://github.com/Buuz135/FunctionalStorage/issues/27#issuecomment-1152987229
and probably this code, https://github.com/Buuz135/FunctionalStorage/blob/35b717be9878bc548e5e0c11d8fc73c959cc5c03/src/main/java/com/buuz135/functionalstorage/inventory/BigInventoryHandler.java#L96-L106
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).