In hindsight "NPE while joining SP world" would have been a better title I guess.

Issue:

Game disconnects to main menu after receiving an error/NPE when loading into a new world.

PS: May or may not be related to scannable mod (according to the stacktrace anyway)?

Logs:

Error log: https://gist.github.com/DeadSix27/d0290de5440d8f887a0d0b53075962cb

Full log if needed: https://gist.github.com/DeadSix27/7ffa64951d9ab4e1bdab21a812eadb1e

Steps to reproduce:

I couldn't reproduce it sadly.. I loaded into the world and disconnected .. next time I loaded into it.. it didn't disconnect.
I used the seed: -2678382728159516681
And if needed heres a twitch export: https://github.com/DeadSix27/mc_stuff/releases/download/1.0/mekanism_disconnect_issue-1.0.0.zip (massive pack, requires ~8-10GB of RAM)

Versions:

Forge: forge-1.12.2-14.23.5.2814.jar
Mekanism: 1.12.2-9.6.6.358

Definitely a weird one; I can't see anywhere that sets it to null.

Give us a ping if it happens again after next release though of course

I tested a bit more and it seems like it happens (reproduce able) on the first world join after booting the game. Every join after that first failed join works fine.
Maybe that information helps?

I'll report back if its fixed once the new version is out.

https://minecraft.curseforge.com/projects/mekanism/files/2691591 contains the possible fix

I tried that version and still encounter that issue.

Error log with newest version: https://gist.github.com/DeadSix27/d4d01095ae735e4c9b8e65e68e05fc5a

That said I'm pretty sure its a different mod causing this at this point... even without Mekanism I encounter that issue, but it does not show up in the error log? Only in the game screen/disconnect message.

Is there a way I could debug this on a running game?

PS: I can probably narrow it down to a specific mod by separation, but that will take me a long while.

Perhaps try it in a test world with just Mekanism and Scanner? You'd need to have a somewhat similar setup in terms of mek blocks placed and scanner in inventory.

It is possible to get a debugger attached, but annoyingly difficult.

Just had a look at the log error (hence the strikeout), it definitely looks like Scannable is the one at fault here, it's calling getPickBlock with a null world :|

But it's also occurring during onClientDisconnectionFromServer event... so this likely isn't the cause of your disconnection, something earlier is going screwy.

The disconnect is something different, it turns out though that there was still legacy error catching going on that was logging the stacktrace of the null pointer instead of passing it up to scannable to handle. This should be fixed in 9.7 via #5369

It would be interesting to see if you get any more log issues/crashes from this as of the 9.7.0 release https://minecraft.curseforge.com/projects/mekanism/files/2698323

We no longer have extra try/catch blocks so my guess is that the error log will properly be handled. Hopefully the crash goes away as well or at least produces an easier to find report.

@pupnewfster I'll test in the next days and report back.

Took me a while to get back to this, but I tested with the latest release of Mekanism now and it still disconnects without any crashlog at all upon first join.
But no more error logs related to mekanism or similar.

Works fine without scannable though.. so I guess ill just continue this issue on their issue tracker?

Well they might not be able to help, as it would seem its an issue on the server side, as pupnewfster found Scannable does handle and ignore the error (it only got noticed since we log it). I'd leave the issue on their repo tho, no world access should be getting done when the world is null.

If you can post the server log (or if single player the complete log file) from the time of disconnection we might be able to help you locate the problem though

I made a bare profile with almost no config changes started it and joined an existing world:

This is the entire log of it: https://gist.github.com/DeadSix27/5181d146f1374b26efc19c9e0494ad4f

I think I figured it out though, it was a timeout issue.. the timeout limit must have been lowered.. my old config must have gotten overwritten.. increasing that makes the join succeed without issues.

Now the question is why this time it mentions "timed out" in the log and the previous times it didn't.. .. and also why it shows an disconnect-error instead of a "timed out" message on the screen

wtf, you're timing out in single player? There's not even a network connection there

I know right? The world loading can time out.. it took me ages back then to figure that one out... i dont know how the internal server is built.. but maybe it uses a local connection too? I mean its just a built in server that you connect via localhost isnt it?

Anyway this mod solved many of my issues back then: https://minecraft.curseforge.com/projects/randompatches

See timeout patches. (EDIT: I only use the timeout patch part of that mod.)

It's just weird that the client errored out on disconnect.. rather than complaining about timeouts.

EDIT: The other weird thing is that without scannables it works fine, but with, it errors out.. I can't imagine that mod adding that much load time to the join process...

Scannable seems to scan the whole Block Registry on connect/disconnect, and given the timings of packets, that itself can cause the timeout, when combined with X other mods doing the same.

IMO (note that I've not looked tooo far into it) no mod should be sending packets from the login events, as it delays the handshake process (they should be queued for later). Mek is guilty of this too iirc, but we just load the config and don't do further processing

As for why there was just an error before, if that was a server it'd be because the server did actually close the connection, so the client doesnt get a graceful message

Good to know. Guess that concludes this issue?

Still don't know why it never mentioned time outs up until now.. only that error. I remember when encountering timeouts when using an actual server it showed the time out message at least on one end (either server or client), with a internal server i'd think the log will include both ends.. guess it doesnt..

Either way, thanks for all your help and insight on this.

Good to know. Guess that concludes this issue?

Yeah, unless you can find more detailed messages in the server log there's not much I can help with. One day soon I might make a mini mod that names and shames things that delay startup tho

@thiakil that would be awesome indeed (that mod).