Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ChristJohnson opened this issue Jun 13, 2024 · 1 comment
Open

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

ChristJohnson opened this issue Jun 13, 2024 · 1 comment

Comments

@ChristJohnson
Copy link

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants