Mekanism

Mekanism

111M Downloads

Rendering Issue with 5x ore processing setup

miksbricks opened this issue ยท 8 comments

commented

Having rendering issues with all types of pipes - at least elite and ultimate.
render1
render2

Should render ultimate mechanical pipes but it doesn't. Water is flowing through pipes into evaporation unit the pipes are just not rendering.
render3
render4

Running the Hermitpack 1.5.1 release which has Mekanism 9.2.1, Mekanism tools 9.2.1 and Mekanism Generators 9.2.1

commented

Are you using Optifine?

commented

You're not the only one. I've just made my 5* ore processing and also all my pressurised pipes are not displaying. It's not only Mekanism, but also some ender io conduits not showing.
Everything works as supposed.
Using a custom build version from the current (16 December) 1.10 branch, without optifine.

Mod list and Screenshot will follow soon.

commented

@miksbricks, do you have a client and server log of this when it happens?

Posting the logs of mine (and screenshots):
Clientlog, serverlog, modlist
https://gist.github.com/thommy101/995fa39fbf44eb8d46d8a3eb141087cc

Screenshots
http://imgur.com/a/RsDsT

Keep in mind, my logs also contains stuff of EnderIO, as it also has a render issue ( SleepyTrousers/EnderIO-1.5-1.12#3910 )

commented

If that is the same as the one reported earlier, the rendering problem is caused by the TileEntities on the client-side not having any data.I have no idea what stops them from being synced.

Update: I should have looked into the logfile first. Yes, that's the problem. Mekanism throws an exception when encoding its network packet, stopping the TE data for that chunk to be sent.

commented

Looking at my log, I've found a bug in Mekanism regarding tile entities at line 219 (IllegalStateException) . Maybe it prevents any other tile entity to send it's data to the client.
I'll take a look if it can be reproduced easily and solve it if possible.

commented

Did some digging, somehow the facing of a machine (in my instance a resistive heater) changes from north to down. The clientfacing (I assume this is used for rendering) stays the correct value. Mekanism tries to get the left and right of the current facing to get the input and output. This fails when given an facing of up or down, causing an IllegalStateException to be thrown.

Modifying it so that in case of mismatch it uses client render solves the issue, but it's not a nice and clean solution. Best solution is to find out where the wrong facing is coming from and fix that.

I'll let you all know if I find a cause of it.

commented

Sorry - No I am not using Optifine. I don't have logs that far back.

commented

This should be fixed when #4184 is redone and merged.