So I thought I'd try my hand at updating Custom Ore Gen from 1.7.10 to 1.10.2, figuring that I can bypass the blockstate issues by just letting COG handle it as metadata as it always has and translate back into blockstate only when it interfaces with vanilla code.

 

Not the greatest solution in the world, but one that would be quick and easy to pull off.  90% of everything else was just figuring out the new name something got.

 

That left me with a UI issue where the buttons and sliders weren't getting their mouse clicks (fixed) and....an issue I have no idea how to even diagnose.

 

The issue is that everything seems to run just fine.  Game loads up, I can use all UI, I can create a new world.

 

And that's it.  Once a world is created (either by loading a save or creating a new world) it reaches 100% says "Changing view distance to 12, from 10" and then hangs.  No further messages are printed, the game just displays a dirt background with "0%" written in the center.

 

I tried going into debug mode and seeing where the execution goes, but it appears to just be ticking the world as normal.  In so doing, I got it to print the "Can't keep up! Did the system time change, or is the server overloaded?" message.  Hitting escape on this "0%" screen returns me to the main menu and throws a NPE in ForgeChunkManager.unloadWorld (line 620).

 

I have a fork at https://github.com/Draco18s/CustomOreGen/tree/1.10-Update

Accidental infinite loop or recursion somewhere (like when generating ore for the spawn-area's chunks)? How far can you get in the debugger? If you put a print into the ore-gen, does the log fill as in infinite loop / circular calling?

 

Calling circles can occur when your program calls methods you're not expected to call. If their calls then come back to your method, the program gets stuck in infinite recursion.

 

Then again, maybe your ore-gen has a loop with an exit condition that sometimes can't be satisfied (like when an ore isn't allowed to replace anything, so the method keeps trying different randoms forever attempting to find a place for it).

No, the loop was the main game loop.  Everything was functioning as it should, except I couldn't see the game.

 

Ended up just commenting out event handlers until I could get into the game, narrowed it down to one.

 

https://github.com/Draco18s/CustomOreGen/blob/1.10-Update/src/main/java/CustomOreGen/FMLInterface.java#L87-L93

    @SubscribeEvent
    public void onServerTick(ServerTickEvent event)
    {
    	if (event.phase == TickEvent.Phase.END) {
    		ServerState.checkIfServerChanged(FMLServerHandler.instance().getServer(), (WorldInfo)null);
    	}
    }

 

Examining this in the debugger is actually difficult, because having the

checkIfServerChanged

commented lets the game run.  Having it uncommented prevents the game from running, but the breakpoint on it is never encountered.  Ended up having to round-about get at it (comment, run in debug, uncomment) and found that

FMLServerHandler.instance().getServer()

is returning null, and only null.

 

Is there another way to get the MinecraftServer instance without access to a World object serverside?

Is there another way to get the MinecraftServer instance without access to a World object serverside?

 

FMLServerHandler.instance().getServer() will return null on an integrated server. Use FMLCommonHandler.INSTANCE.getMinecraftServerInstance() instead, it works for both integrated and dedicated servers.

 

 

Ah ha, brilliant.  I'll give that a bash.

 

Edit:

Yup, that prevented the problem.  Still some issues deeper on in (a command throws "error: null") but that's one step closer to a port.

Thanks diesieben07. I'm only trying to help the maintainers get it updated, so I don't know how it does most of what it does, so I was making an educated guess and was wrong, but couldn't find an alternative.

 

The change made it work, which is good. There's still two issues, neither of which I'm qualified to resolve, but the mod runs well enough for my purposes (cancels vanilla or been and does is own).