Posted July 27, 20196 yr Minecraft Version: 1.14.4 Forge Version: 28.0.19 Code: https://github.com/Choonster-Minecraft-Mods/TestMod3/tree/ba1306dd180514cc7dd135b21262f8eb72cdd305 Log: https://gist.github.com/Choonster/2ee4d06856ca409f85b89728e9ddd47e After updating to 1.14.4 and attempting to run the client (the first time since updating to 1.14), I encountered a crash due to LastUseTimeModelItem#initCapabilities being called when LastUseTimeCapability.LAST_USE_TIME_CAPABILITY was still null. It appears that an ItemStack of this Item is being created in Minecraft#populateSearchTreeManager, which is called towards the end of Minecraft#init. ClientModLoader.begin is called earlier in Minecraft#init to start loading mods, but this doesn't actually fire FMLCommonSetupEvent (the event that Capabilities are registered in) directly; instead it registers a resource reload listener that fires the event (and the other setup events). The initial reload that calls this listener doesn't happen until the very end of Minecraft#init (after Minecraft#populateSearchTreeManager). It feels counter-intuitive that IForgeItem#initCapabilities can be called before Capabilities have actually been registered, but is this a bug or is it intended behaviour? Edited July 27, 20196 yr by Choonster Formatting Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.
July 27, 20196 yr Not a currently known issue: https://github.com/MinecraftForge/MinecraftForge/issues?utf8=✓&q=is%3Aissue+is%3Aopen+capabilities Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable. If you think this is the case, JUST REPORT ME. Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice. Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked. DO NOT PM ME WITH PROBLEMS. No help will be given.
July 30, 20196 yr Author I decided to report this on GitHub. Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.
August 3, 20196 yr Author Lex responded to the issue on GitHub and basically said to register the capabilities earlier and add null protection to the IForgeItem#createProvider implementation: Quote Register your cap in your constructor and hope it is called before anything anywhere creates a ItemStack. Since that's not feasible in a multithreaded world, better solution, add null protection to your createProvider code. Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.
August 3, 20196 yr Author It turns out that the constructor of the @Mod class is too early to call CapabilityManager#registerCapability as it uses the CapabilityManager#callbacks map, but this is only initialised between RegistryEvent.NewRegistry and RegistryEvent.Register being fired. Due to this, I kept the capability registration in FMLCommonSetupEvent and just added null protection to the IForgeItem#initCapabilities implementations. This fixed the crash. You can see the changes I made in this commit. Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.