Mekanism

Mekanism

111M Downloads

Client crashes if Mekanism items are rendered by Tinker's Construct Crafting Stations or Drying Racks in 1.10.2

TheSeven opened this issue ยท 7 comments

commented

I'm getting seemingly random client crashes in rendering code if certain Mekanism items (I guess things which are tile entities, e.g. Atomic Disassembler, Solar Generators, ...) are rendered by Tinker's Construct (on top of a Crafting Station, hanging on a Drying Rack, etc.).

First of all, the Mekanism items aren't visible on the Crafting Station or Drying Rack, which makes tracking down the cause of the crash rather tricky (because the culprit isn't visible). This first happened to me when I accidentally hung an Atomic Disassembler into a Drying Rack, and it took me several days to figure out what exactly had happened.

The client will crash after anything between a few seconds to a few minutes if one of those situations is present. With OptiFine enabled, it will usually crash within 5 seconds after joining the game (much faster than without it).

The crash dumps will show IndexOutOfBoundsExceptions in DirectByteBuffer.putFloat called by VertexBuffer.func_181662_b, called by rendering code of seemingly random items.
An example of such a backtrace follows:
java.lang.IndexOutOfBoundsException at java.nio.Buffer.checkIndex(Buffer.java:546) at java.nio.DirectByteBuffer.putFloat(DirectByteBuffer.java:897) at net.minecraft.client.renderer.VertexBuffer.func_181662_b(VertexBuffer.java:607) at net.minecraft.client.particle.Particle.func_180434_a(SourceFile:199) at net.minecraft.client.particle.ParticleManager.func_78874_a(ParticleManager.java:335) at net.minecraft.client.renderer.EntityRenderer.func_175068_a(EntityRenderer.java:1790) at net.minecraft.client.renderer.EntityRenderer.func_78471_a(EntityRenderer.java:1556) at net.minecraft.client.renderer.EntityRenderer.func_181560_a(EntityRenderer.java:1335) at net.minecraft.client.Minecraft.func_71411_J(Minecraft.java:1076) at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:371) at net.minecraft.client.main.Main.main(SourceFile:124) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) at net.minecraft.launchwrapper.Launch.main(Launch.java:28)

Disabling the rendering of items in Crafting Stations seems to help as a workaround, and not doing dumb things such as hanging Atomic Disassemblers into Drying Racks (should this even be possible?) helps as well ;)

Please let me know if you need any further information to track this down.

commented

Shot in the dark as you didn't include a full crash log: Remove Optifine.

EDIT: reread your post and saw that you crash quickly without Optifine, but still crash eventually even if you don't have it. Sorry I missed that.

commented

It crashes both with and without optifine, it just happens much more reproducibly with it.

Full crash report WITH optifine: https://paste.ee/p/uWbAs (crashes within 5 seconds)
Full crash report WITHOUT optifine: https://paste.ee/p/1OmP8 (crashes within a few minutes)

commented

The with Optifine crash looks like most of the others...

The non-optifine crash looks to be crashing on a Smeltery Controller at -447,60,960.

tconstruct{1.10-2.3.3a.jenkins271} (Edited to remove unexpected link).

Try updating TC to 2.4.0. If that doesn't help, you should give them a bug report as well. You could also try replacing that controller with a stone block with commands.

commented

I'll try updating TC tomorrow. I doubt that the smeltery is related though, as I had the same kind of crash a thousand blocks away from that smeltery as well. The common factor was an atomic disassembler hanging on a drying rack.
I've seen a dozen of those crashes, every one while rendering something different. My guess would be that attempting to render some Mekanism item from a context that it doesn't expect screws up something with the vertex buffer, that causes a subsequent rendering operation to crash.
If I find some time tomorrow, I might come up with a minimal test world that reliably reproduces this.

commented

As stated many times, this is a render context issue that I've already attempted far too many times to fix. You can disable the special render in TiCo's config.

commented
**at net.minecraft.client.renderer.VertexBuffer.func_181662_b(VertexBuffer.java:611)
at mods.betterfoliage.client.render.RenderGrass.render(RenderGrass.kt:169)
at mods.betterfoliage.client.Hooks.renderWorldBlock(Hooks.kt:90)
at net.minecraft.client.renderer.chunk.RenderChunk.func_178581_b(RenderChunk.java:278)
at net.minecraft.client.renderer.chunk.ChunkRenderWorker.func_178474_a (ChunkRenderWorker.java:119)
at net.minecraft.client.renderer.chunk.ChunkRenderWorker.run(ChunkRenderWorker.java:47)**

I'm having the same issue. The difference, however, is that I don't have Mekanism loaded. I was using a vanilla water bucket, although the CR suggests BetterFoliage is the culprit.

commented

@GOHpsycho
I don't have Mekanism loaded

Then you have to post it at their forum