Jump to content

[1.14.4] IForgeItem#initCapabilities called before Capabilities are registered


Choonster

Recommended Posts

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#initClientModLoader.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 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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.