Infer type/version/loader from packwiz

[lhvy]

Enhancement Type

Improve an existing feature

Describe the enhancement

Currently using packwiz with Quilt for the latest release of Minecraft and the Quilt loader can cause problems because the container sees that the type is set to Quilt, and downloads whichever version of the loader it prefers, which in this case is actually 0.18.x beta, which is incompatible with mods in my packwiz pack. This could be fixed if the version, type and loader version env vars were simply replaced with values read directly from the packwiz pack.

[itzg]

I am gradually working towards this type of capability with CurseForge modpacks. So, this enhancement makes sense for packwiz also.

The unique challenge with the packwiz version is that it'll need to pre-download the definition and interpret just enough to get the versions.

[itzg]

As discussed in Discord this track nicely with TYPE=AUTO_CURSEFORGE where it would be TYPE=PACKWIZ

Pack format info

Example pack

[WilsontheWolf]

Had a similar issue, where despite my pack having the minecraft version set, it downloaded the latest and then it couldn't boot due to mod incompatibilities.

[jcotton42]

The unique challenge with the packwiz version is that it'll need to pre-download the definition and interpret just enough to get the versions.

This seems like it shouldn't be too bad? knocks on wood

The pack.toml pointed to by the URL contains all the pertinent versions under the [versions] heading.

[jcotton42]

One way that comes to mind is, if the TYPE is packwiz, then set the VERSION, TYPE, and other variables from the manifest, then let the image continue as normal.

e.g. a packwiz manifest with

[versions]
minecraft = "1.21.1"
neoforge = "21.1.169"

Would result in VERSION=1.12.1, TYPE=NEOFORGE, and NEOFORGE_VERSION=21.1.169. The rest of the startup scripts would then continue as before, none the wiser that their settings were coming from packwiz instead of the container env.

[jcotton42]

I threw together a proof of concept supporting just NeoForge master...jcotton42:docker-minecraft-server:versions-from-packwiz

Running docker run -e TYPE=packwiz -e PACKWIZ_URL=https://github.com/jcotton42/modpacks/raw/refs/heads/main/packs/DragonPack/pack.toml -e EULA=TRUE minecraft-server where pack.toml is this file

https://github.com/jcotton42/modpacks/blob/55b2f63ad887dbf0f30b7e166cd00a742fc1bea4/packs/DragonPack/pack.toml

Results in

[init] Running as uid=1000 gid=1000 with /data as 'drwxr-x--- 2 1000 1000 4096 May 20 05:59 /data'
[init] Image info: buildtime=local,version=local,revision=local
[init] Resolving type given NEOFORGE
[mc-image-helper] 06:05:59.423 INFO  : Running NeoForge 21.1.169 installer for Minecraft 1.21.1. This might take a while...
[init] Running packwiz installer against URL: https://github.com/jcotton42/modpacks/raw/refs/heads/main/packs/DragonPack/pack.toml
packwiz-installer was started without packwiz-installer-bootstrap. Use the bootstrapper for automatic updates! (Disregard this message if you have your own update mechanism)
Loading manifest file...
Loading pack file...
Loading MultiMC pack file...
MultiMC not detected
Checking local files...
Modpack name: Dragon Pack
Checking local files...
Comparing new files...
Side changed, invalidating all mods
Validating existing files...
...

So it seems to work.

[itzg]

Thanks @jcotton42 !

I would have preferred it to be implemented in mc-image-helper like CurseForge and Modrinth packs; however, the proposed approach seems good.

FYI mc-image-helper has a toml-path subcommand which can be used to extract values from a toml file rather than needing to use awk. Refer to the usage section.

Here's an example of where I use that

https://github.com/itzg/docker-mc-proxy/blob/5c4144cbf77d1e82f73479a97f57216665b78d05/scripts/health.sh#L13

A PR would be great if you want to proceed.

[jcotton42]

I could definitely put it in image-helper if you would prefer.

What kind of approach were you envisioning? Just bootstrap the necessary Minecraft and modloader versions, leaving the actual pack installations for the later script parts? Or something else?

[rhullah]

I love that movement is happening with this, thanks @jcotton42!!

[itzg]

I could definitely put it in image-helper if you would prefer.

Yeah it would be great if you could take a stab at enhancing it there.

What kind of approach were you envisioning? Just bootstrap the necessary Minecraft and modloader versions, leaving the actual pack installations for the later script parts? Or something else?

Ideally the image helper approach could track Modrinth and CurseForge incorporating the packwiz installer download execution from

docker-minecraft-server/scripts/start-setupModpack

Lines 30 to 47 in 1370f58

	function handlePackwiz() {
	# If packwiz url passed, bootstrap packwiz and update mods before other modpack processing
	if [[ "${PACKWIZ_URL:-}" ]]; then
	if ! packwizInstaller=$(mc-image-helper maven-download \
	--maven-repo=https://maven.packwiz.infra.link/repository/release/ \
	--group=link.infra.packwiz --artifact=packwiz-installer --classifier=dist \
	--skip-existing); then
	logError "Failed to get packwiz installer"
	exit 1
	fi
	log "Running packwiz installer against URL: ${PACKWIZ_URL}"
	if ! java -cp "${packwizInstaller}" link.infra.packwiz.installer.Main -s server "${PACKWIZ_URL}"; then
	logError "Failed to run packwiz installer"
	exit 1
	fi
	fi
	}

and directly kicking off the modloader install as part of it.

Perhaps a larger exercise than you originally planned so a script-side approach is good too.