FRAPI relies on mod load order
kb-1000 opened this issue ยท 3 comments
With FRAPI, the renderer implementation must explicitly register the renderer instance with the API.
This, as far as I can tell, is supposed to happen in its ClientModInitializer.
The order in which mods are loaded, including entrypoints getting called, is unfortunately completely undefined, which means a mod relying on FRAPI may end up getting loaded before indigo or indium, and won't see a renderer in its initializer. That's... let's say, less than ideal, and has caused me some hard to debug issues.
May I ask why you are instantiating objects that depend on the renderer API so early?
If that's really intended to be disallowed, that must be explicitly documented and should mention proper replacements.
But, you're supposed to be registering your mod's rendering code in the client initializer, aren't you? One may want to already create materials etc there, or for a more obvious reason, you may want to select different codepaths based on whether an FRAPI renderer is available.