Loading the DH Api
The example repo the DH Api is simply added through a
implementation directive in the build.grade file. However, I am facing the issue that the game will obviously crash when my mod is loaded, but not DH, and the class loaded can't find DH's classes.
For example: java.lang.NoClassDefFoundError: com/seibel/distanthorizons/api/methods/events/interfaces/IDhApiEvent
Now I am not sure I am supposed to include the DH Api jar or what? I'm also confused because the API version on Modrinth seems really old. Is it assured to be stable?7 Replies
The API is stable, the reason the API jar is so old is because the API hasn't changed and as such hasn't needed a new version (this is good because it means the API hasn't had any breaking changes).
The API is a subset of the full DH jar and is MC version agnostic so you can develop for all DH versions at the same time.
When working with an optional dependency you generally put that code in a separate class that's only loaded if the dependency is present. In this case check if DH is loaded using your mod loader's API (for example:
FabricLoader.getInstance().isModLoaded("distanthorizons")) and then load the class.Right, that makes sense. I was quite confused because I had already added such a check, but it was still throwing a NoClassDefFoundError. I think that is because the event callbacks were loaded by the class loaded despite the code using them not being executed. I would be nice if you could change the
implementation to a compileOnly in the buld.gradle of the example project.
Also, do you think it's better to check via isModLoaded("distanthorizons") or Class.forName("com.seibel.distanthorizons.api.DhApi"); with a try-catch?Personally I'd do
Class.forName("com.seibel.distanthorizons.api.DhApi"); because it's mod loader agnostic, but either should work just fine.I guess checking for both is actually best, since another mod might JIJ the api.
Unlikely, but it can't hurt.
Thanks for the quick responses!
👍