Mekanism

Mekanism

111M Downloads

[v8] Block models disappearing with Waila

codewarrior0 opened this issue ยท 5 comments

commented

Using branch development with Waila 1.5.9 installed.

Looking at a machine with a complex block model (anything other than a Factory) causes all Mek block models to vanish, and sometimes causes lots of other models and geometry to disappear. Does not happen when not using Waila.

vanishing

commented

Possible relevant info from log file:

[10:34:32] [Client thread/WARN] [Waila]: net.minecraft.client.renderer.entity.RenderItem.func_82406_b:604
[10:34:32] [Client thread/WARN] [Waila]: mcp.mobius.waila.overlay.DisplayUtil.renderStack:76
[10:34:32] [Client thread/WARN] [Waila]: Catched unhandled exception : [renderStack | 1xtile.MachineBlock@8] net.minecraft.util.ReportedException: Rendering item
[10:34:32] [Client thread/ERROR]: ########## GL ERROR ##########
[10:34:32] [Client thread/ERROR]: @ Post render
[10:34:32] [Client thread/ERROR]: 1283: Stack overflow

(last 3 lines repeat as long as the block is under the cursor)

Probably an unmatched glPushMatrix or glPushAttrib somewhere.

I also noted that normally Waila's HUD itself displays a small model of the block, but after looking at a complex model once, the HUD no longer displays any block models.

commented

Looks like a Waila issue to me. Report it on their tracker.

commented

Are you sure? It works in v7.

commented

I reported the traceback issue to Waila. Tinkered with Waila's exception handling and fixed the issue. Here is the full traceback:

[12:37:02] [Client thread/WARN] [Waila]: Caught ReportedException, stack trace follows: 
java.lang.NoClassDefFoundError: net/minecraft/src/FMLRenderAccessLibrary
    at mekanism.client.render.item.ItemRenderingHandler.renderItem(ItemRenderingHandler.java:494)
    at net.minecraftforge.client.ForgeHooksClient.renderInventoryItem(ForgeHooksClient.java:183)
    at net.minecraft.client.renderer.entity.RenderItem.func_82406_b(RenderItem.java:563)
    at mcp.mobius.waila.overlay.DisplayUtil.renderStack(DisplayUtil.java:76)
    at mcp.mobius.waila.overlay.OverlayRenderer.renderOverlay(OverlayRenderer.java:78)
    at mcp.mobius.waila.overlay.OverlayRenderer.renderOverlay(OverlayRenderer.java:40)
    at mcp.mobius.waila.overlay.WailaTickHandler.tickRender(WailaTickHandler.java:55)
    at cpw.mods.fml.common.eventhandler.ASMEventHandler_340_WailaTickHandler_tickRender_RenderTickEvent.invoke(.dynamic)
    at cpw.mods.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:54)
    at cpw.mods.fml.common.eventhandler.EventBus.post(EventBus.java:138)
    at cpw.mods.fml.common.FMLCommonHandler.onRenderTickStart(FMLCommonHandler.java:335)
    at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:987)
    at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:887)
    at net.minecraft.client.main.Main.main(SourceFile:148)
    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:286)
    at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:376)
    at org.multimc.EntryPoint.listen(EntryPoint.java:165)
    at org.multimc.EntryPoint.main(EntryPoint.java:54)
commented

The traceback printed by Waila is actually incomplete.

Waila catches a ReportedException thrown by RenderItem which contains a Minecraft crash report, which is why it only goes up to RenderItem.func_82406_b. The full traceback is contained in the ReportedException's crashReport, but it never gets printed because Waila only treats it as a regular Exception and can't look at the CrashReport contained in the ReportedException (which never gets reported because Waila catches it. Kind of a catch-22?). If there's an issue to report to Waila, it's about the crash report getting swallowed.

It's entirely likely that the traceback in the CrashReport points to something in Mekanism.