Minecraftforge: Investigating curious case of "Invalid dimension id 144"

[YoungCP]

At present, not 100% sure on reproduction, might be Java 8 u172?

Time: 5/16/18 2:17 AM
Description: There was a severe problem during mod loading that has caused the game to fail

net.minecraftforge.fml.common.LoaderExceptionModCrash: Caught exception from Compact Machines 3 (compactmachines3)
Caused by: java.lang.IllegalArgumentException: Invalid dimension id 144
at net.minecraft.world.DimensionType.func_186069_a(DimensionType.java:77)
at net.minecraftforge.common.DimensionManager.registerDimension(DimensionManager.java:116)
at org.dave.compactmachines3.world.tools.DimensionTools.registerDimension(DimensionTools.java:19)
at org.dave.compactmachines3.CompactMachines3.preInit(CompactMachines3.java:57)

DimensionManager.java:116 A two year old line of code...

DimensionType.getById(type.getId()); //Check if type is invalid {will throw an error} No clue how it would be invalid tho...

Finally throws an error...

Is this check even valid?

[SquidDev]

I believe this is related to #3885?

[YoungCP]

After reading #3885 I decided to pursue the -XX:CompileCommand route, but couldn't get Java to run with any variation on the exclude directive (bug in Java?)... so I dropped that after reading that by default it will automatically load any .hotspot_compiler file in the launch directory... but not sure how that worked, so... I added a .hotspot_compiler file and used the -XX:CompileCommandFile directive to point to it and used Process Monitor to discover that it indeed was using the minecraft instance directory (and noticed it concatenating the launch directory to the full path, making that route useless), and so I just removed the command line, and it loaded the file...

In the file, I added 2 directives (this may be overkill);

exclude net.minecraftforge.common.DimensionManager::registerDimension
exclude net.minecraft.world.DimensionType::*

But it does indeed appear to have alleviated the problem. (5 launches of SevTech Ages w/ some extra mods that register dimensions)

I believe that the mysterious 55 dimension limit mentioned in the other ticket was definitely related to the interpreter switching over to the compiler.

So... is this a possible solution?

[YoungCP]

Actually, it wasn't loading it. I had the error happen again.

Saw this; Java HotSpot(TM) 64-Bit Server VM warning: .hotspot_compiler file is present but has been ignored. Run with -XX:CompileCommandFile=.hotspot_compiler to load the file. ... it only checked it, didn't load it. 😞

[thiakil]

DimensionType::values() is usually the culprit (yes this is the same as the linked issue). Also the error message in your latest post seems to tell you what to do to solve it; add the listed flag to JVM options.

Ideally the solution would be for modders to add all DimensionTypes well before any dimensions are registered and avoiding using values() where possible in that period, so that the values array is not cache by JIT. This is something you could pass on to the devs of the mods you installed.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___." or "Here's a screenshot of this issue on the latest version"). Thank you for your contributions!

[stale[bot]]

This issue has been automatically closed because it has not had activity in a long time. Please feel free to reopen it or create a new issue.

[Pangamma]

This issue still exists.

[DaemonUmbra]

I don't believe this issue exists in 1.14.4 or 1.15.2, if I am incorrect please provide a debug.log showing this error from one of those versions.