What exactly is the purpose of the Modrinth mod? #26
-
Hi, bit confused on what the exact purpose of the Modrinth mod was, is it an API for developers to use as a sort of wrapper for the plugin messages on the server or an example implementation? Both? I've seen these things been thrown around a bit so I'm just asking for clarification and in case anyone else was wondering the same thing. (p.s. there's some pretty nasty typoes in things like the changelogs and repo descs. did not want to open an issue because that seems rude so i'll just put it as a PS here (Fore as Forge, Interfacing as Interfacting)) |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
The distributed mod is the official method of using the Mod API, and downstream mods should be using this mod as a dependency and either requiring their users to install the mod or at least in the case of fabric, including it with the distributed JAR if wanted. The primary reason for this is to allow multiple mods to nicely interface with the Mod API and not cause conflicts with each other. Especially in the case of Fabric, as I believe the APIs in Fabric API for using plugin messages only allow a single decoder/encoder per channel. While you technically could implement the Mod API directly into your mod manually, it would be heavily advised against doing so. If you have two different implementations of the Mod API, this can cause issues with subscribing to event packets and could also cause other weird behavior when it comes to different packet versions. Our goal with this API is to also maintain backward compatibility the best we can. For example, a mod built with version 1.0 of the Mod API will ideally still function with version 1.1 of the Mod API, even if that version brings structure changes to packet data. TLDR; The Mod API on Modrinth is the "middle man" in-between downstream mods and communicating with the API, allowing multiple mods to work together without conflict. |
Beta Was this translation helpful? Give feedback.
The distributed mod is the official method of using the Mod API, and downstream mods should be using this mod as a dependency and either requiring their users to install the mod or at least in the case of fabric, including it with the distributed JAR if wanted. The primary reason for this is to allow multiple mods to nicely interface with the Mod API and not cause conflicts with each other. Especially in the case of Fabric, as I believe the APIs in Fabric API for using plugin messages only allow a single decoder/encoder per channel.
While you technically could implement the Mod API directly into your mod manually, it would be heavily advised against doing so. If you have two different imp…