Description

When I try to load EnderIO together with Applied Energistic minecraft crashes at launch.

Environment

Single player minecraft with forge and a number of mods I like to play with. Trying to find out why it crashed by loading it up nearly a 100 times with different combinations of mods, untill I found out that it is the combination of EnderIO and AE2 that prevents it loading.

Loaded up minecraft with nothing but those 2 (and openeye for crashlogs) and dumped the crashlog in pastebin: http://pastebin.com/wpZ9MDr9

• Minecraft Version: 1.10.2
• AE2 Version: v4_alpha_9
• Forge Version: 12.18.3.2185
• EnderCore: v0.4.1.61-beta
• EnderIO: v3.0.1.141_beta

As I am not sure which of the 2 mods is responsible I posted this in both githubs, the other ticket can be found here: SleepyTrousers/EnderIO-1.5-1.12#3921

I can't really help here because I cannot start the game up in my dev env if I add AE2:

java.lang.AbstractMethodError
	at net.minecraft.client.renderer.block.statemap.BlockStateMapper.getBlockstateLocations(BlockStateMapper.java:62)
	at net.minecraftforge.client.model.ModelLoader.loadBlocks(ModelLoader.java:227)
	at net.minecraftforge.client.model.ModelLoader.setupModelRegistry(ModelLoader.java:146)
	at net.minecraft.client.renderer.block.model.ModelManager.onResourceManagerReload(ModelManager.java:28)
	at net.minecraft.client.resources.SimpleReloadableResourceManager.registerReloadListener(SimpleReloadableResourceManager.java:122)
	at net.minecraft.client.Minecraft.startGame(Minecraft.java:540)
	at net.minecraft.client.Minecraft.run(Minecraft.java:386)
	at net.minecraft.client.main.Main.main(Main.java:118)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
	at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at net.minecraftforge.gradle.GradleStartCommon.launch(GradleStartCommon.java:97)
	at GradleStart.main(GradleStart.java:26)

PS: Also, in a standalone MultiMC instance it works for me

There is even a big fat notice at the bottom about what exactly is wrong...

I saw a line saying "Could not find a crafting ingredient for 'crystalFluix' (stack=null, object=null) in recipe 'Conduit, ME'" with the suggested solution of "Note: To start the game anyway, you can disable recipe loading in the Ender IO config file. However, then all of Ender IO's crafting recipes will be missing." However, disabling all receipes doesn't seem like a workable fix to me, so instead I thought it better to report this issue.

@yueh I think I got it. Are you registering your oreDict names in the init phase by chance? That phase where we should register recipes that reference those oreDict names? Which fails if your mod is loaded after our mod because someone renamed the jars?

I am not sure if you are asking me that question, because I am a mod user and not a mod maker. I did however rename the jars, if I know what order they should load in I can change that easily!

@AlHollandiyah That was for yueh. Renaming the jars so that ae2 is loaded first will help you for now. However, the root cause is as I wrote above.

@HenryLoenwind Thanks, that did indeed solve the crash! I will keep track of this github though, to see if this workaround is still necessary with the next update!

Yes, they are registered during init. Or not at all, because neither the item nor the oredict entry is required to exist.

If you don't want other mods to use your oreDict entries for recipes, then don't register them. They are a inter-mod-compatibility feature. Otherwise register them in the preinit, where they belong, so other mods can use them for recipes.

I do not at all care about the case when a user configures your mod to not provide certain items. Those users will know what to do when another mod fails to register its recipes because an item they disabled is missing. That's why we provide the name of the config file with the recipes in the error message.

According to the actual docs, init is the phase to register oredict entries. Maybe this is no longer correct, but that is not our problem. It is probably not ideal for other mods. But as long it states "register oredict here", we will stick to it. Otherwise Lex will just start complaining about mods not behaving like he intended. If someone feels it is wrong, they should raise the issue to forge.