Invalid game version ID: 9008 belongs to an invalid dependency. #42
Comments
|
That's the first time I've ever seen this error. |
|
I think, I found the issue. CurseForge version manifest has a duplicate entry for // An original one.
// This one is used to publish mods.
{
"id": 9008,
"gameVersionTypeID": 73250, // Version type 73250 corresponds to Minecraft 1.18
"name": "1.18.2",
"slug": "1-18-2",
"apiVersion": null
}// And here we have this copycat.
{
"id": 9016,
"gameVersionTypeID": 1, // Version type 1 does not exist :)
"name": "1.18.2",
"slug": "1-18-2",
"apiVersion": ""
}"Hate" would be too nice of a word to describe my feelings towards the mess they call an API. |
|
I'll implement a workaround for such cases in the upcoming update, so thank you for the report |
|
It looks like you're having issues similar to what I ran into with itsmeow/curseforge-upload#16 - gameVersionTypeID 1 is Bukkit, but it's not actually declared anywhere in the API. My current action using curseforge-upload "works" only because when no valid versions are tagged CF just selects whatever the latest available Bukkit version is. This means I have to manually edit the release created to correct versions, which partially defeats the point of automating it. I haven't poked through your source to look at your usage of the CF API, but I'm hoping it would be possible to add a CF-specific gameVersionType identifer that would support numeric values to skip the secondary lookup. |
Why, though? I don't care about CF's messy "API", so why should users? Especially, when the action will be able to resolve this problem on its own |
Mostly lack of need to maintain it on your part. At the end of the day, I just want the ability to ensure that |
Of course I am! Moving to Node16 and adding support for more project types is the key theme of the next update :)
Don't worry, there will be no magic values that I need to constantly maintain. |
|
|
|
@Zoey2936, On the bright side of things, I'm almost done with the code for the new update. However I still need to write unit tests (and a few integration ones). Also I wanted to ship a friendly documentation for the action with v4.0. So, there's still work to be done, but I'm almost there. |
|
I'm working on the issue right now, and I have a question. You were trying to publish a plugin, which supports Spigot, Paper, and Purpur, but the problem is CurseForge does not officially support anything except Bukkit. So, should |
|
I personally don't think you should bother with a My exhaustive list for CF would be The DBO side of CurseForge was intended exclusively for anything that will run on a CB server, however, DBO hasn't provided CB since the 1.7 fiasco. Spigot is now technically the lowest level Bukkit server software since Spigot declared CB unsupported software that exists only as part of the build chain a couple versions back. DBO does allow files that require Spigot's API additions and do not run on CB. I've seen plugins that target other platforms there as well, but I cannot find any explicitly stated rules. I poked around to check, and apparently you can't even make a new project right now because Overwolf is transitioning to their own system and DBO is basically an afterthought tacked on to the back side of the CF site ever since CF acquired it. |
|
Thank you for providing insight into the world of Minecraft plugins! I must admit, I'm not very familiar with this area since I haven't worked with plugins before and don't have any plans to do so. While investigating this issue, I discovered another problem with CurseForge's versioning system. Contrary to my initial assumption that there were only two concurrent types of Minecraft versions (one for plugins and one for everything else), I found that there are actually three:
What makes this situation even more baffling is that CurseForge has subcategories such as "Worlds" and "Resource Packs" within the "Addons" category, which use different Minecraft versions than their standalone counterparts. It's astonishing that a software so poorly organized, seemingly designed by individuals without any programming knowledge and a lack of basic common sense, not only continues to function but is also part of a multi-billion-dollar company. This realization just makes me appreciate Modrinth a little bit more. So, somebody, please, tell Modrinth devs that I love them and everything they stand for. Given these circumstances, even if I were to hardcode specific project types that should use different Minecraft versions on CurseForge, I still wouldn't be able to accurately determine the correct version for resource packs and similar projects. As a result, the most viable solution appears to be trying every possible combination until one works. For example, consider the following configuration: loaders: |
fabric
forge
game-versions: |
1.RV-Pre1
1.12.2
1.16.5
java: |
Java 1.8
Java 16Previously, [
8203, 6756, // 1.16.5, 1.12.2
7499, 7498, // Fabric, Forge
4458, 8325, // Java 8, Java 16
]Now, [
// Mods, modpacks, etc
[
8203, 6756, 5997, // 1.16.5, 1.12.2, 1.9.2
7499, 7498, // Fabric, Forge
4458, 8325, // Java 8, Java 16
],
// Plugins
[ 7915, 6588, 585 ], // 1.16, 1.12, 1.9
// Addons
[ 7997, 7434, 7431 ], // 1.16, 1.12, 1.9
]I can then iterate through these IDs until CurseForge accepts a valid combination. I've also implemented a simple heuristic: if no IDs are found for a given list of loaders, it's more likely that the user didn't specify any mod loaders and we're dealing with a plugin. For example, with the following configuration: loaders: |
spigot
paper
game-versions: |
1.RV-Pre1
1.12.2
1.16.5
java: |
Java 1.8
Java 16
[
// Plugins
[ 7915, 6588, 585 ], // 1.16, 1.12, 1.9
// Mods, modpacks, etc
[ 8203, 6756, 5997 ], // 1.16.5, 1.12.2, 1.9.2
// Addons
[ 7997, 7434, 7431 ], // 1.16, 1.12, 1.9
]So, it should take 1 try to publish a mod or a plugin and 2-3 tries (internally and without any user input, of course) to publish a resource pack or something similar to CurseForge. It's not the most elegant solution, but hey, we're dealing with the digital equivalent of a tangled ball of yarn here. I believe this is the best way I can handle the CurseForge chaos for now. |
|
Fixed in v3.3. |
https://github.com/Ghost-chu/QuickShop-Hikari/actions/runs/3531473607
When mc-publish trying release artifact to CurseForge, CF returns an 400 Bad Request response:
Error Response
Github Actions Logs
Actions Script
Any solution is greatly appreciated!
The text was updated successfully, but these errors were encountered: