Dynamic Trees

Dynamic Trees

25M Downloads

Crash when used with more layers

MarcusElg opened this issue ยท 11 comments

commented

Dynamic trees works well on it's own and so does more layers. But when used together Minecraft crashes on start up. Here is the crash:
---- Minecraft Crash Report ----
// Don't be sad, have a hug! <3

Time: 5/10/18 8:55 AM
Description: Initializing game

java.lang.ExceptionInInitializerError
at com.ferreusveritas.dynamictrees.DynamicTrees$RegistrationHandler.newRegistry(DynamicTrees.java:128)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_4_RegistrationHandler_newRegistry_NewRegistry.invoke(.dynamic)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90)
at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:182)
at net.minecraftforge.registries.GameData.fireCreateRegistryEvents(GameData.java:714)
at net.minecraftforge.fml.common.Loader.preinitializeMods(Loader.java:633)
at net.minecraftforge.fml.client.FMLClientHandler.beginMinecraftLoading(FMLClientHandler.java:270)
at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:466)
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:377)
at net.minecraft.client.main.Main.main(SourceFile:123)
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:483)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
Caused by: java.lang.NullPointerException
at morelayers.networking.KeybindProvider.(KeybindProvider.java:15)
at morelayers.EventHandler.attachCapability(EventHandler.java:130)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_13_EventHandler_attachCapability_AttachCapabilitiesEvent.invoke(.dynamic)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90)
at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:182)
at net.minecraftforge.event.ForgeEventFactory.gatherCapabilities(ForgeEventFactory.java:657)
at net.minecraftforge.event.ForgeEventFactory.gatherCapabilities(ForgeEventFactory.java:639)
at net.minecraft.item.ItemStack.forgeInit(ItemStack.java:1216)
at net.minecraft.item.ItemStack.(ItemStack.java:112)
at net.minecraft.item.ItemStack.(ItemStack.java:98)
at net.minecraft.item.ItemStack.(ItemStack.java:95)
at net.minecraft.item.ItemStack.(ItemStack.java:90)
at com.ferreusveritas.dynamictrees.trees.Species.(Species.java:127)
at com.ferreusveritas.dynamictrees.trees.Species$1.(Species.java:70)
at com.ferreusveritas.dynamictrees.trees.Species.(Species.java:70)
... 16 more

A detailed walkthrough of the error, its code path and all known details is as follows:

-- Head --
Thread: Client thread
Stacktrace:
at com.ferreusveritas.dynamictrees.DynamicTrees$RegistrationHandler.newRegistry(DynamicTrees.java:128)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler_4_RegistrationHandler_newRegistry_NewRegistry.invoke(.dynamic)
at net.minecraftforge.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:90)
at net.minecraftforge.fml.common.eventhandler.EventBus.post(EventBus.java:182)
at net.minecraftforge.registries.GameData.fireCreateRegistryEvents(GameData.java:714)
at net.minecraftforge.fml.common.Loader.preinitializeMods(Loader.java:633)
at net.minecraftforge.fml.client.FMLClientHandler.beginMinecraftLoading(FMLClientHandler.java:270)
at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:466)

-- Initialization --
Details:
Stacktrace:
at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:377)
at net.minecraft.client.main.Main.main(SourceFile:123)
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:483)
at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
at net.minecraft.launchwrapper.Launch.main(Launch.java:28)

-- System Details --
Details:
Minecraft Version: 1.12.2
Operating System: Windows 10 (amd64) version 10.0
Java Version: 1.8.0_25, Oracle Corporation
Java VM Version: Java HotSpot(TM) 64-Bit Server VM (mixed mode), Oracle Corporation
Memory: 191034024 bytes (182 MB) / 369098752 bytes (352 MB) up to 1073741824 bytes (1024 MB)
JVM Flags: 8 total; -XX:HeapDumpPath=MojangTricksIntelDriversForPerformance_javaw.exe_minecraft.exe.heapdump -Xmx1G -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:MaxGCPauseMillis=50 -XX:G1HeapRegionSize=16M
IntCache: cache: 0, tcache: 0, allocated: 0, tallocated: 0
FML: MCP 9.42 Powered by Forge 14.23.3.2680 7 mods loaded, 7 mods active
States: 'U' = Unloaded 'L' = Loaded 'C' = Constructed 'H' = Pre-initialized 'I' = Initialized 'J' = Post-initialized 'A' = Available 'D' = Disabled 'E' = Errored

| State | ID           | Version      | Source                        | Signature                                |
|:----- |:------------ |:------------ |:----------------------------- |:---------------------------------------- |
| UC    | minecraft    | 1.12.2       | minecraft.jar                 | None                                     |
| UC    | mcp          | 9.42         | minecraft.jar                 | None                                     |
| UC    | FML          | 8.0.99.99    | forge-1.12.2-14.23.3.2680.jar | e3c3d50c7c986df74c645c0ac54639741c90a557 |
| UC    | forge        | 14.23.3.2680 | forge-1.12.2-14.23.3.2680.jar | e3c3d50c7c986df74c645c0ac54639741c90a557 |
| UC    | dynamictrees | 1.12.2-0.7.6 | DynamicTrees-1.12.2-0.7.6.jar | None                                     |
| UC    | geolosys     | 1.9.1        | Geolosys-1.12.2-1.9.1.jar     | None                                     |
| UC    | morelayers   | 1.2.0        | More+Layers+1.2+(1.12.2).jar  | None                                     |

Loaded coremods (and transformers): 
GL info: ' Vendor: 'Intel' Version: '4.3.0 - Build 20.19.15.4642' Renderer: 'Intel(R) HD Graphics 4400'
Launched Version: 1.12.2-forge1.12.2-14.23.3.2680
LWJGL: 2.9.4
OpenGL: Intel(R) HD Graphics 4400 GL version 4.3.0 - Build 20.19.15.4642, Intel
GL Caps: Using GL 1.3 multitexturing.

Using GL 1.3 texture combiners.
Using framebuffer objects because OpenGL 3.0 is supported and separate blending is supported.
Shaders are available because OpenGL 2.1 is supported.
VBOs are available because OpenGL 1.5 is supported.

Using VBOs: Yes
Is Modded: Definitely; Client brand changed to 'fml,forge'
Type: Client (map_client.txt)
Resource Packs: 
Current Language: English (US)
Profiler Position: N/A (disabled)
CPU: 4x Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz

I'm the creator of More Layers so if I need to update my mod I will but I think the problem is from your side as my mod works on it's own.

commented
commented

Thank you for that. Can you do me a favor and test it with Dynamic Trees 0.7.7c? I've done a lot of changes recently and it would make the crashlog much more relevant.

commented

Where's your source code?

commented

So I'm not sure what's going on here. The crash is coming from more layers running a member function in "capability" which is null. This is causing a NPE which makes my static initialization of my ItemStack fail. I imagine the constructor is run with "CapabilityInject" or some such nonsense that does some kind of voodoo object construction. The point is that it's null when it's run and that's a problem for you. I moved some of my statically initialized itemstack member objects into specific constructors and managed to make it not crash with Dynamic Trees. Instead it crashed for the same reason with CoFHCore. I imagine it will cause a great number of mods to crash. In fact, any mod that has an ItemStack that was constructed either directly or from a chain of calls that originated in a static initialization.
The forge capabities for ItemStacks seem to be added when an ItemStack is constructed. forgeInit() is called from ItemStacks's contructor. If it's constructed statically then you can't gaurantee that other mods won't have ItemStacks that are constructed before you set your capability object.
As a test you can run your mod with CoFHCore and watch it crash. I suggest you rethink how you are doing your object initialization. It seems to be the problem here.

commented

I was able to reproduce this problem. I'll look into it.

commented

I can probably help you but a few things first.

  • May I have a link to that forum so I can see what was suggested there and the reasoning behind it?
  • I don't understand why a mod that simply adds layered blocks needs complicated network code and "capabilities". I think I'm missing something. What's going on with that?
  • Can you put a fully formed project on github with the gradle build script and everything so it can be properly built and imported without having to make all of that stuff just to test it?
  • Also consider putting a deobf jar file on curseforge when you release so people can test in the dev environment without having to build your project from source.
commented

My whole source code is up so do you have any suggestions on how to change it? I don't understand networking much, to even get it working I had to create a thread on the forge forums with over 20 replies. So I don't really know what to change so some help would be appriciated!

commented

Okay. So here's what I did: I moved my ItemStacks that are potentially initialized inside of a static call to inside the constructor and modified my default instance objects to compensate. This is a workaround so that my mod is unaffected by (as far as I can tell) your bug. This will prevent the crash in your mod. I want to be clear that I don't think your problem is solved because I believe you will encounter this issue repeatedly with other mods who create ItemStacks somewhere in static code. Namely CoFHCore is just one example as I witnessed it crash with that mod. I recommend you test compatibility with them as well for a deeper understanding of what is happening. If it turns out that you're the only one doing it right and everybody that crashes is doing it wrong then so be it. Although it's not very pragmatic to be the guy who's right and his stuff doesn't work with anybody else's stuff.

commented

Thanks for your efforts. Yes it crashes with other mods as well :c.To answer your questions:

  1. Here is the tutorial I followed: https://www.planetminecraft.com/blog/forge-tutorial-capability-system/ That's where I got the most of my code from. The forge post isn't so relevant it was mostly do this! And I like what??? But here it is anyways, I've linked to comment where the discussion about networking started: http://www.minecraftforge.net/forum/topic/64075-1122solved-capabilities-and-networking/?tab=comments#comment-302625
  2. I didn't think I would need something this advanced either. The only thing I wanted is that you should be able to place 4 layers at a time when pressing CTRL. This required sending the data over to the server and then storing it in a capability to then get that value from the itemblocks placement methoud...
  3. Uploaded some more stuff. Tell me if I have missed anything inportant (didn't think that the run and build folders were inportant). Hmm it seemed to not upload some of the folders, I hope what's up is enough.
  4. I have now uploaded the sources (I hope that's what you ment): https://minecraft.curseforge.com/projects/more-layers/files/2557063
commented

Just an update and FYI. Your code doesn't just crash with mods using statically initialized ItemStacks. It can also crash during their pre-init phase if they load before your mod does.

commented

Try updating your code with this:

	@SubscribeEvent
	public static void attachCapability(AttachCapabilitiesEvent event) {
		if(KeybindProvider.capability != null) {
			event.addCapability(keybindDown, new KeybindProvider());
		}
	}

This just does a simple check for null on the capability. If it hasn't been built yet then the attachCapability() will do nothing during this time for the ItemStack. I don't know what the right way to fix it is but this will at least prevent the crash.