You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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
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:
However, when I run
mcman init --mrpack test-1.0.0.mrpack
, the following occurs:Most of the way through typing this, I realized there was another configuration that would also work, so I tested it to no avail:
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 thatAddonType::Mod
andAddonType::Plugin
share only one property. This is clear in the Modrinth modpack format schema. Your only example of a datapack in aserver.toml
is asymetric to the mrpack schema.I believe this can be easily fixed by adding and implementing
AddonType::Datapack
(and potentiallyAddonType::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 theserver.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:
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?
The text was updated successfully, but these errors were encountered: