Add Minecraft plugin support for Curseforge - #115
Conversation
`getMinecraftVersion(String)` now accepts a boolean for whether to get the Minecraft version for a plugin rather than a mod. This will use the game version type ID of 1, which is not returned in `version-types` API and you just need to "know it" I guess. To be able to know when that boolean should be true, a `plugin` property was added to `CurseforgeOptions` that is true by default when ALL mod-loaders are plugin-based (projects with mixed loaders are assumed to be mod-first, and can always manually change `plugin`). Since plugins don't have environments or specific Java versions (corect me if I'm wrong), their game versions shouldn't be applied either (otherwise the API will error saying it doesn't recognize it). All new tests pass.
| "paper", | ||
| "spigot", | ||
| "bukkit", | ||
| "folia", | ||
| "purpur", | ||
| "bungeecord", | ||
| "velocity", | ||
| "waterfall", |
There was a problem hiding this comment.
Is there anyway this can be done without hard coding the supported platforms? One of the design goals I had when starting off was to make it tottaly platform agnostic.
Ill have to take a close look at what you are doing when i have some more spare time.
There was a problem hiding this comment.
These are used for automatic setting of the plugin option.
If we make a request to Curseforge we can probably get the project's type (mod vs Bukkit plugin) and then set plugin option based on that. Or if we don't want it to be mutable, we can just remove plugin option and get project type when publishing.
There was a problem hiding this comment.
Okay upon further investigation, it seems the newer CurseForge REST API would need to be used.
This API requires a totally separate API key (and doesn't have upload capabilities, so you'd need to supply 2 keys). It requires approval through a form. It took me 2 applications and several weeks to get approved for a personal script that wasn't even public.
I don't see any other API to get a project's game/type.
I don't think that's the right path for MPP. Requiring 2 keys is annoying/confusing and actually getting the REST API key is frustrating/takes forever.
Hard-coding stuff like this is really the only solution I can think of. Unless we lean more into supporting any game, as then we can just directly ask the user "what is the CurseForge project type?" via an option. (this option would need to have special handling for "bukkit" though, as there is no bukkit.curseforge.com API, instead it's baked directly into minecraft.curseforge.com, mixed into mod options). I really hate CurseForge API...
| @get:Input | ||
| val plugin: Property<Boolean> |
There was a problem hiding this comment.
I wonder if there is a way to make this work with all different types of curseforge projects including other games?
There was a problem hiding this comment.
I think so.
Most games don't return anything for version-types, while others do (Hytale returns an HTML page, fun!). I assume this means they only have one version type, which I guess is easier?
All (or at least the ones I tested) games return an array of versions for versions (same formart as Minecraft). One of them just returned a single version in array.
Luckily, they all use the same upload API with the same metadata (apart from game versions of course). So it would just be a matter of changing https://minecraft.curseforge.com to https://wow.curseforge.com or https://sims4.curseforge.com after the plugin's API is updated.
It really just comes down to "how do we know which type of project this is?" (Minecraft mod, Minecraft plugin, Sims 4 mod, etc.). See #115 (comment)
| // Not documented anywhere, but Minecraft versions for plugins use game version type ID = 1. | ||
| // It's not even returned in CurseForge's version-types API... | ||
| @JvmStatic | ||
| val PLUGIN_MINECRAFT_VERSION_TYPE_ID = 1 |
There was a problem hiding this comment.
Im not keen on using undocumented and possibly unstable magic values like this.
There was a problem hiding this comment.
From my previous usage with their upload API (with this same specific issue), this is really the only way.
Bukkit plugins require the game versions with type 1 (I assume 1 = Bukkit Minecraft versions).
Maybe there is some way to get this type ID, but it's not included in version-types, so I have no idea where it could be.
|
Okay my PR does not currently work as-is anyways. I forgot that Bukkit doesn't even support specifying all Minecraft versions. Some versions are minor-only (no patch): 
So right now, publishing fails for me because my range is 1.8.8+, and Bukkit doesn't have 1.8.8 (or 1.8.9, 1.12.2, 1.13.2, etc.). i LOVE curseforge SO MUCH 😂 So MPP somehow needs to know to do 1.8 instead of 1.8.7, 1.8.8, 1.8.9, etc. and same for all the other versions without patches. Yes, 1.8.8 should mark it as 1.8-compatible, that is the standard for Bukkit since there is no specific 1.8.8. Best solution I can think of just hard-coding 1.8-1.17 (excluding 1.8.1) to add 1.8, 1.9, 1.10, etc. (no patch) instead of the full version. If hard-coding is really out-of-the-picture, then maybe it could try adding the full version, then if that fails it could add the shorthand (no patch). |
There was a problem hiding this comment.
Pull request overview
Adds CurseForge publishing support for plugin-based Minecraft loaders (e.g., Paper/Spigot) by introducing a plugin mode that changes how game versions are resolved and which metadata is submitted to the CurseForge API.
Changes:
- Add
CurseforgeOptions.plugin(auto-derived from mod loaders) to distinguish plugin vs mod projects and adjust validation/metadata accordingly. - Extend Minecraft version resolution to support CurseForge’s plugin-specific Minecraft version type (ID = 1) and handle patch vs major.minor lookups.
- Add integration/unit tests covering plugin uploads, version ranges, and skipping mod-only metadata (env/java) for plugins.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/main/kotlin/me/modmuss50/mpp/platforms/curseforge/Curseforge.kt | Adds plugin option/defaulting and alters CurseForge upload metadata construction for plugin projects. |
| src/main/kotlin/me/modmuss50/mpp/platforms/curseforge/CurseforgeVersions.kt | Adds plugin-aware Minecraft version resolution via a plugin-specific version type ID. |
| src/test/kotlin/me/modmuss50/mpp/test/curseforge/CurseforgeTest.kt | Adds integration tests ensuring plugin uploads submit correct gameVersions and skip env versions. |
| src/test/kotlin/me/modmuss50/mpp/test/curseforge/CurseforgeVersionsTest.kt | Adds unit tests validating plugin Minecraft version ID mapping. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
|
Okay it now works with my testing (https://repo.srnyx.com/#/snapshots/me/modmuss50/mod-publish-plugin) |
|
I think this is as good as an implementation for Bukkit plugins can get for now. I think support for ANY game (including non-Minecraft) might just be a bit too broad/complicated, especially for this PR. |
getMinecraftVersion(String)now accepts a boolean for whether to get the Minecraft version for a plugin rather than a mod. This will use the game version type ID of 1, which is not returned inversion-typesAPI and you just need to "know it" I guess.To be able to know when that boolean should be true, a
pluginproperty was added toCurseforgeOptionsthat is true by default when ALL mod-loaders are plugin-based (projects with mixed loaders are assumed to be mod-first, and can always manually changeplugin).Since plugins don't have environments or specific Java versions (corect me if I'm wrong), their game versions shouldn't be applied either (otherwise the API will error saying it doesn't recognize it).
All new tests pass.
Maybe I'll add documentation for it but I'm lowkey lazy...
Fixes #112