search

ParadigmMC / mcman

Powerful Minecraft Server Manager CLI. Easily install jars (server, plugins & mods) and write config files. Docker and git support included.
GNU General Public License v3.0
176 stars 14 forks source link

[bug] (mrpack) relative_path datapack import issue #64

Open ChristJohnson opened 5 months ago

ChristJohnson commented 5 months ago

System: Debian 12: java: default-jre (java 17) package in Debian 12 stable repo rustup 1.27.1 (default environment) mcman 0.4.5 (installed via cargo install; used to generate one version of the mrpack) packwiz unknown version (installed today via go install)

Windows 11 (just updated to 10.0.22631 Build 22631): java: jdk-17 modrinth: Theseus v0.7.1 (used to generate one version of the mrpack)

Issue: I am creating a lightweight fabric server to host a datapack. I have some optimization mods installed alongside the data pack. I have generated the mrpack in different ways and verified that the mrpack is being generated correctly. When I use the Modrinth client to import the mrpack, it correctly generates the following directory layout:

server/
|-datapack
| |-Rouguecraft 1.2.2.zip
|-mods
| |-fabric-api-0.97.1+1.20.4.jar
| ...
...

However, when I run mcman init --mrpack test-1.0.0.mrpack, the following occurs:

server/
|-mods
| |-fabric-api-0.97.1+1.20.4.jar
| |-Rouguecraft 1.2.2.zip
| ...
...

Most of the way through typing this, I realized there was another configuration that would also work, so I tested it to no avail:

server/
|-mods
| |-fabric-api-0.97.1+1.20.4.jar
|-world
| |-datapacks
| | |-Rouguecraft 1.2.2.zip
| ...
...

This scenario does not occur within the control of mcman.

I conclude that the bug is a logical error occurring on import of mrpack files. I'm not exactly familiar with the modding community's vocabulary, but I would qualify a datapack as an AddonType because there is only one property that AddonType::Mod and AddonType::Plugin share only one property. This is clear in the Modrinth modpack format schema. Your only example of a datapack in a server.toml is asymetric to the mrpack schema.

I believe this can be easily fixed by adding and implementing AddonType::Datapack (and potentially AddonType::WorldDatapack). Assuming I have not missed a key portion of the code base, there is no case considered for global datapacks. I see two solutions, depending on the case.

In the case that global datapacks are may be exported in many pack formats, then adding a (global) [[datapacks]] table to the server.toml schema would be the best choice.

In the case that this bug is niche, then I would suggest implementing a hinting system for global datapacks. While I've only had experience with the modrinth portion of this program so far, it seems like the following is a decent enough fix:

[[mods]]
type = "modrinth"
datapack = [default:false | true]
id = "rogue-craft"
version = "N2eTx4OM"

Additional Thoughts: NOTE: this bug also occurs during mcman import modrinth.

I also noticed that there is a separate argument/command for mcman import datapack, but that only allows for URLs.

related TODO?

TheAlan404 commented 5 months ago

you came pretty close, the bug originates from interop/mrpack.rs#L66 where it adds every files entry from the mrpack into the [[mods]] list (without checking the file's path)

the whole system was a big oversight and this issue should be fixed on the next release which overhauls a lot of things, join the discord if you would like to discuss or contribute

as for the current non-overhaul version, i dont think theres something i can fix, even with a band-aid...

ps. i'd like to applaud you for this very detailed issue