Can't Read the Crashlog, Want to Learn - Single Player Crashing

[HalestormXV]

Alright, so I put together a single player pack for myself. The pack adds a lot of custom spawns. The pack also has all mods updated to 1.7.10 (as far as I can tell although some say 1.7.2 but are ones that i believe are backwards compatible, regardless all were obtained from their official threads that said 1.7.10) and runs fine on my Multi player server that I play alone on. I like the Multiplayer Server much better then SinglePlayer. I have run into this issue that ONLY occurs on my Single Player world. I have generated a fresh new single player world by the way so it is not an old world. The server crashes with a client side crash. Now mind you this only happens on single player, NOT on my SMP world. I don't think it'd be possible that a mod is incompatible on single-player lol, right? Anyway here is the crashlog. But I can't read it and would like to learn how to read it so I can interpret where these problems are originating from. So if anyone can shed some light on what the issue causing my crash would be I would appreciate it.

 

But please don't just say "Aether II crashes your world and isn't compatible with X mod." Please just try and explain how you found out it was Aether II or Xenos Reliquary, etc. and how you arrived at the conclusion that it was incompatible with X mod. Like I said, I don't want to just blab about my pack crashing, I would like to learn how to interpret these crash logs. Some of them I can understand but this particular one I can't. Here is the crash log:

 

http://pastebin.com/dP2hzWkG

Edited February 18, 2015 by HalestormXV

[plowmanplow]

java.lang.NullPointerException: Unexpected error
        at net.minecraft.client.network.NetHandlerPlayClient.func_147281_a(NetHandlerPlayClient.java:744)
        at net.minecraft.network.play.server.S0FPacketSpawnMob.func_148833_a(SourceFile:97)
        at net.minecraft.network.play.server.S0FPacketSpawnMob.func_148833_a(SourceFile:15)
        at net.minecraft.network.NetworkManager.func_74428_b(NetworkManager.java:212)
        at net.minecraft.client.multiplayer.PlayerControllerMP.func_78765_e(PlayerControllerMP.java:273)

This error isn't very specific, and provides few clues as to which mod may be causing the problem. The first three lines indicate that there was a problem in the code which is sending mob spawn information (S0FPacket) from the server (which is built into SSP) and the client. Since there aren't any specific mods present in the exception, and the code locations are listing vanilla classes, the issue is likely to be that one of the mods adding mobs is doing so improperly and that the vanilla code is getting data which it does not expect, and therefor causing a crash.

 

Which mod is it? With just that crash report it is impossible to say. You have SO many mods adding mobs that it will take some trial and error to isolate the source of the crash.

[HalestormXV]

Alright, well that makes sense then.

 

I knew it must have had something to do with the mob adding mods. So its a trial and error test then so it seems. My gut tells me Aether II, only beacuse this error occured when I had Millenair and then stopped occurring when I took it out, but now I put Aether II in and it happens again. Although as far as I thought Aether II only does stuff in its own dimension but regardless that doesn't matter as I will have to thoroughly test anyway to be sure.

 

Now another question I have is as follows: this crash as you said is related to vanilla classes and mods not executing spawn code correctly thus causing the client crash. So my question becomes, does this error not occur on my SMP server because it is handled differently, perhaps more efficiently, or something else? Or is the better statement to make: "This error has not YET occurred on my SMP server and most likely will at one point or another if whatever mod is causing this tries to execute spawn code again."

Edited February 18, 2015 by HalestormXV

[plowmanplow]

It could definitely be a case of "hasn't happened yet", but if you are using Cauldron as your server it may be that Cauldron does some "fancy optimization magic" on the back-end which is catching this before it becomes a crash and silently ignoring it. If you are using the default Forge universal as your server I wouldn't think it would be doing anything different from the client so more likely a "not yet" issue.

 

As an example, the OreSpawn mods does some "weird things" related to mob spawning and frequently conflicts with other mods resulting in fairly non-informative crash reports. However, I've come to notice that if I see a "Spawn24" packet reference in the crash report and OreSpawn is present, that is where the issue is. Removing OreSpawn always fixes the problem. That's not to say it is specifically OreSpawn's issue (is likely due to a conflict with another mod), but since I've seen that exact error on WIDELY varying packs I've started pointing the finger at OreSpawn.

[HalestormXV]

Interesting. In doing some testing I have come across some odd results. I have generated a new world and as expected it crashed on load. I attempted to enter into the world 3 separate times and all three times it crashed with the same error. However, I then decided to rename aether to zaether in an attempt to change the load order and i was able to log into my world 3 consecutive times. This does require more testing but could the load order have been a cause of the conflict? I am not sure if that still applies in 1.7.10.

 

And by the way I do appreciate your response plowman I am always open to learning.

Edited February 18, 2015 by HalestormXV

[plowmanplow]

If there are multiple mods overloading the same vanilla classes it is possible that load order could make a difference.

[HalestormXV]

Alright, well it appears my hunch was correct. The error was originating from Aether II and although renaming Aether II to zAether corrected the world generation/load issue it did not correct the issue once you loaded into the Aether world. Now I am aware that Aether is still in alpha and that was too be expected and it doesn't help when you add in all the other mods that add creatures into the game that are in this particular pack lol. However, I am glad I managed to find the root of the problem and see that the error log being thrown was indeed not a normal one.