[1.14.4] Early exchanging gadget ItemStack tooltip instantiation causes crash with BlockData serialisation with 10+ mods installed

Forge: 28.1.79 Building Gadgets: 3.1.1b Crash report: Here Screenshot: inapplicable

This is a bit of a crazy one that I’ve had difficulty replicating. Having Building Gadgets (latest version), as well as the latest version of al132’s Techemistry (and associated library mods) along with the latest version of Random Patches, plus the top 10 or so mods on Twitch, causes the above crash, implying that your serializer is getting null at some point on this line.

Line in question:

tag.putString(NBTKeys.KEY_SERIALIZER, tileData.getSerializer().getRegistryName().toString())

Either tileData (which is unlikely as the constructor requires nonnull), the result of getSerializer, or the result of that serializer’s registry name (more likely that it hasn’t been registered yet) are null. Given that this is taking place during the item tooltip function (func_82840_a), I’m assuming that Random Patches’ classloading is causing this to load earlier than expected – potentially before the expected registrations.

Regardless of either of the versions of Techemistry or Random Patches, however, it might be wise to program defensively in this case and check for multiple nulls, potentially serializing nothing, especially as this only seems to occur when a specific combination of mods trigger (or trigger classloading) first, and only during the searchtree creation on the client, which I believe is specifically limited to the creative tab.

Thus, it would presumably not affect actual exchanging gadgets.

[noobanidus]

I’ll check it out but I definitely think that will solve the issue.

Have you looked into DeferredRegistry<T> and RegistryObject<T>? It’s a slightly more complex system but it automatically generates suppliers that are then automatically registered, allowing for static initialization of anything that has a Forge registry. I mostly based the code in MysticalWorld on Tropicraft’s system. My library for it in MysticalLib is still fresh, here’s an example of it.

I’m not sure if it would precisely resolve the issue in this case, but at the very you’ll be able to tell if the serializer is being accessed before the actual registry event for the serializer.

(Just beware that it’s better to do EntityTypes statically.)

Upon testing, there’s now another error that appears to be shifting back to an optional failing, so … I think it’s fixed!

[MajorTuvok]

Ah, ok nice 😃