I was just loading up Modded Minecraft and I was at the 3/7 or 4/7 mark, I don't exactly remember which one it was, and it crashed.

Minecraft version: 1.12.2
Wizardry version: 4.3
Environment: Singleplayer/LAN game/Server

Issue details: This crash seems to be almost the same case with this issue: #517
I was just loading up the game at the point where it said 3/7 or 4/7 and an incompatibility error occurred and my game crashed, I sort of expected a crash to happen but I was really hoping that It wouldn't crash and that it would load just fine, but it crashed anyway.

Other mods involved: Security Craft

Link to crash report (if applicable): https://pastebin.com/mupDWxGR

@bl4ckscor3 Thanks for the info (and sorry for not seeing this earlier!). This issue seems kind of similar to #542, which was fixed on the other mod's end as well.

This issue relates to my item override generator system, which dynamically generates item overrides for multiple models based on a single override model file. The system goes through registered models on resource load and applies the generator to any models with overrides that match a particular pattern. However, to determine which models to apply it to, it obviously has to call getOverrides during model baking, which is where the crash is happening.

I don't think it's either mod's fault per se, it's just that other mods don't expect getOverrides to be called at that point. I could of course fix this by restricting the override generator to just models in the ebwizardry domain, but that would then prevent addons from using the system. Instead I think I'll just add a try/catch around getOverrides, hopefully that will stop this happening for any other mods.

I suspect it probably is the same as #517, but I'll leave this open just in case. Thanks for reporting.

Your welcome.

I still had the crash with securitycraft using the 4.3.1 patch.
https://pastebin.com/ZbXbRumi

Ok. Hopefully, this fixes it.

Hi, SecurityCraft dev here. In order for our block mine model to show differently only in the inventory, we use a custom IBakedModel implementation to render a different model based on the camera transforms. In the ModelBakeEvent, we replace the model that was loaded by vanilla with this custom implementation (see here). The previously loaded model is being saved in the new transform-based model, so it can still be used (called defaultModel in ModelBlockMine). For whatever reason, when Wizardry is installed, that default model is null and that is what was causing the crash. I believe, that it shouldn't be null in the first place, but maybe I am wrong about this. I don't know why Wizardry is causing this, but hopefully this information will help you to find the root cause - if it is even Wizardry's fault at all.

For now, we're releasing a fix for this by adding null checks and returning fallback values if the default model is null. Minecraft starts up fine, and our model still works with this fix.