FRAPI relies on mod load order

[kb-1000]

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.

[Technici4n]

May I ask why you are instantiating objects that depend on the renderer API so early?

[kb-1000]

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.

[Technici4n]

I generally create my materials in UnbakedModel#bake.

(And a FRAPI renderer should always be available. I know this isn't the case due to Sodium, but that's not something that FRAPI should work around. The proper fix is to PR FRAPI support into Sodium "one day".)

[sylv256]

As discussed in Discord, Renderer should be registered via ServiceLoader or a similar mechanism alongside a defined entrypoint during which—upon invocation—it is safe to use Renderer. Both of these would be handled by FRAPI which would ensure a consistent registration time.