Buildinggadgets: Crash with Building Gadget

[Fortist]

Forge 2815, Gadgets 2.6.8.

I was about to start using the gadget in water when scrolling over to the item threw this crash.

---- Minecraft Crash Report ----
// My bad.

Time: 2019-03-31 20:03:23 EDT
Description: Unexpected error

java.lang.ArrayIndexOutOfBoundsException: 45
    at cofh.core.gui.container.InventoryContainerItemWrapper.getStackInSlot(InventoryContainerItemWrapper.java:142)
    at net.minecraftforge.items.wrapper.InvWrapper.getStackInSlot(InvWrapper.java:68)
    at com.direwolf20.buildinggadgets.common.tools.InventoryManipulation.countInContainer(InventoryManipulation.java:304)
    at com.direwolf20.buildinggadgets.common.tools.InventoryManipulation.countItem(InventoryManipulation.java:174)
    at com.direwolf20.buildinggadgets.common.tools.ToolRenders.renderBuilderOverlay(ToolRenders.java:132)
    at com.direwolf20.buildinggadgets.client.proxy.ClientProxy.renderWorldLastEvent(ClientProxy.java:92)
    at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_269_ClientProxy_renderWorldLastEvent_RenderWorldLastEvent.invoke(.dynamic)
    at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90)
    at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:182)
    at net.minecraftforge.client.ForgeHooksClient.dispatchRenderLast(ForgeHooksClient.java:196)
    at net.minecraft.client.renderer.EntityRenderer.renderWorldPass(EntityRenderer.java:1432)
    at net.minecraft.client.renderer.EntityRenderer.renderWorld(EntityRenderer.java:1259)
    at net.minecraft.client.renderer.EntityRenderer.updateCameraAndRender(EntityRenderer.java:1062)
    at net.minecraft.client.Minecraft.runGameLoop(Minecraft.java:1119)
    at net.minecraft.client.Minecraft.run(Minecraft.java:3942)
    at net.minecraft.client.main.Main.main(SourceFile:123)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
    at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:196)
    at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:231)
    at org.multimc.EntryPoint.listen(EntryPoint.java:143)
    at org.multimc.EntryPoint.main(EntryPoint.java:34)

I had a Tech Reborn block as the build block at the time, but I was able to reload in and delete the gadget and get a new one, where I then copied a Flat Colored Block and got the same exact crash. I have no idea whats wrong when parsing over this crash report.

[MajorTuvok]

Could you please submit the full log, (latest.log and debug.log)...
Seems like a very weird thing...

[hnOsmium0001]

I think this is Thermal Expansion's problem...?
Do you have a Resonant Satchel on you? A Resonant Satchel has 45 slots, and the index of the last slot is 44.

[NillerMedDild]

I reported it here: https://github.com/CoFH/Feedback/issues/1493

[Tora-B]

I think that makes it more likely that it's Building Gadget's problem than Thermal Expansion's, if Building Gadgets is attempting to access a slot that doesn't exist. CoFHCore could guard against the crash, but what should it do in this case? Give a null stack?

[MichaelHillcox]

Having a quick look at the code, it's likely an issue with CoFH as we rely on their IInventory handing us back the correct slot count (seen here https://github.com/Direwolf20-MC/BuildingGadgets/blob/master/src/main/java/com/direwolf20/buildinggadgets/common/tools/InventoryManipulation.java#L303 ) thus, I'm not sure we can fix this without adding a special case for CoFH. Like I said, just a quick observation.

[McJty]

The code in BuildingGadgets seems perfectly fine. If that crashes then CoFH is not following the IItemHandler contract correctly and then it is their bug

[KingLemming]

We follow IItemHandler when it's implemented; hell we invented it essentially. Here's the thing though - Satchels DO NOT HAVE IT.

So the question is why are you treating them as if they do?

[MichaelHillcox]

Because it holds items? (No really does it? I've never used it) Is there a specific reason you guys aren't using IItemHandler on your end? I guess this does fall on us because that should be the first thing we are checking for before treating something as an IItemHandler.

To be clear, I wan't blaming your mod, I just wasn't sure on who it fell. Like I said, I had only looked at our code at that point and not yours. I'm looking at yours now and I can see it does not implement IItemHandler.

[KingLemming]

There is a specific reason - Satchels can be made private and the "accessible" capability would change. And while some mods will get that right, the vast majority of them will not. It's a defensive measure.

The way that the IItemHandler cap works is slow and not ideal for items. I wrote up a skeleton for it in 1.7.10 essentially as an interface, and RWTema took it and put it in Forge. Believe me, I wish it had been done differently.

[MichaelHillcox]

It would seem that the issue on our end is that the satchels are still showing they have the default ITEM_HANDLER_CAPABILITY capability even though they 'logically' aren't using that capability in a standard / conventional way.

[KingLemming]

I feel like there may be another mod involved here then. Part of the issue with capabilities is that you can force them unwillingly on other people's items at runtime.

That may be happening here.

[MichaelHillcox]

I wouldn't have thought of that. I'll await to see a full crashlog from the user. Thanks @KingLemming for your input 👍

[NillerMedDild]

Full crashlog: https://pastebin.com/ZkssnPas :)
Edit: From one of my users, not the original poster.

[MichaelHillcox]

Well, GL to anyone who can track the offending mod down :P

[MajorTuvok]

I went through it and the Satchel must be reporting an IItemHandler, as we do not wrap anything at all... If it does not have an IItemHandler, then it's completly ignored by us. Also it isn't cached (And even queried every Render [which is throwing the error]!!! (why Dire, why?)) so I don't think there'd be a cache Problem...

[MichaelHillcox]

@MajorTuvok please be sure to have read what KingLemming has put about the idea of another mod "Part of the issue with capabilities is that you can force them unwillingly on other people's items at runtime."

[MajorTuvok]

I know... Just wanted to put out there, that this must be the Problem... (Sorry I'm tired <=> I don't say things directly)

[MichaelHillcox]

Yup, it's something telling something that the item is an IItemHandler when it's not

[MichaelHillcox]

Closing due to an unknown origin causing the incompatibility. If this comes up again we'll re-evaluate the issue.

[Ruukas97]

Based on my trying to dig into this issue and the comment by KingLemming:

I feel like there may be another mod involved here then. Part of the issue with capabilities is that you can force them unwillingly on other people's items at runtime.

I think I have found the culprit.
https://minecraft.curseforge.com/projects/common-capabilities

From the feature list:

Item Handler: Making more blocks, items and entities expose their item inventories.
Thermal Expansion: Satchel, Caches and Strongboxes in item-form.
Vanilla: Shulker Boxes in item-form.

[Ruukas97]

Additionally it seems to be fixed in the latest release:

Fixes:

• Fix invalid item capabilities on (upgraded) TE Satchels, Closes #20

https://minecraft.curseforge.com/projects/common-capabilities/files/2705122

[MichaelHillcox]

You're a mad man and a saint! that's got to be the cause. ❤️

[choekstr]

Yup, I have common capabilities as well and a resonant satchel. However it stopped crashing when I took off Holding IV enchant. No more crashes as long as I keep it unenchanted. Must all tie together.

Now I just keep getting duplicate building gadgets periodically (3 exchangers, 2 building, 2 destruction, 2 copy-paste so far). I can't pin it down so not really anything to report as it can't be replicated.

[MajorTuvok]

That's funny - we don't modify the ItemStacks containing the Gadgets (in ulcoming 2.7.0 there'll be a cap which will be modified... But definitly not the count variable!)