Add unsup support

[caitlynrw]

Add support for unsup, a modpack bootstrap tool for custom setups. This tool is designed to be self-contained and transparent to launchers so shouldn't have too many run on effects.

Resolves #3798.

Currently, I've added a new server type, which will run unsup as a 'preloader' before handing control back to the containers more regular startup sequence. As unsup can control the jars installed, it will probably need to be coupled with the CUSTOM_JAR_EXEC var.

I still need to add support for unsup version selection, as well as error handling (ie a missing unsup.ini file).

I'm testing with the unsup.ini file from the Rewind Upsilon project.

version=1
preset=minecraft

source_format=packwiz
source=https://rewindmc.com/packwiz/upsilon/pack.toml

force_env=server

[flavors]
flavor=standard
gregtech=gregtech_on
dartcraft=dartcraft_off

[itzg]

Looking great so far!

Yeah it looks like either setting CUSTOM_JAR_EXEC or SERVER should work out. What does a typical unsup invocation look like?

[caitlynrw]

What does a typical unsup invocation look like?

Typically the jar is just called with an environment type (client or server), unsup then pulls all other information from the unsup.ini file. There's also a series of environment variables to control internal behaviour. unsup is designed to work on functionally any Java version Minecraft will run on.

Upsilon's start script just runs the below command which will then pull the actual pack sources from the ini file and associated URL.

java -jar unsup.jar server

[caitlynrw]

Yeah it looks like either setting CUSTOM_JAR_EXEC or SERVER should work out.

Does setting the type to FORGE, FABRIC ect include any additional features other than their installers and 'manual' mod installation?

[itzg]

Typically the jar is just called with an environment type (client or server)

In that case, yeah CUSTOM_JAR_EXEC is best.

Does setting the type to FORGE, FABRIC ect include any additional features other than their installers and 'manual' mod installation?

FAMILY is the more important variable to set since it is used to determine mods or plugins capability for individual files installed. TYPE is still expected to be set in case users want to use that in variable placeholders, but isn't critical if that's hard to get out of unsup

[caitlynrw]

Ok, I've added some error detection (unsup not downloading, ini file missing) and added an FYI about configuring the custom server vars.

I've also set a default version for unsup, I assume having the container pull the releases.json and find the latest (non-prerelease) version would be preferable though.

Additionally, I think I've found a related oversight. Java agents, given there's no specific env var for them, I've included the call in EXTRA_ARGS, this means they're getting appended to the end of the JVM invocation and not ran. I'm specifically noticing NilLoader isn't getting run. Changing the environment variable from EXTRA_ARGS to JVM_OPTS fixes the agent running problem

[caitlynrw]

Ok, I think:tm: this is feature complete.

Summary of additions

• UNSUP server type
• UNSUP_VERSION environment variable, if left blank, the latest 'release' build will be pulled from Maven.
• All environment variables from unsup, most notable probably being BOOTSTRAP_URL which can be used to set a remote location for the config file. unsup also uses DEBUG for extra console logging.

I haven't made any commits for the documentation yet, once this passes a sanity-check, I'll start working on the docs.

I've tested this locally with the unsup.ini above. My docker run command is included below. I've been testing this with eclipse-temurin:8-jre-jammy as a base image.

docker run --rm -p 25565:25565 -e EULA=true -e TYPE=UNSUP -e UNSUP_VERSION=1.1.6 -e DEBUG=true -e CUSTOM_JAR_EXEC="-cp forge.jar:minecraft-server.jar net.minecraft.server.MinecraftServer" -e JVM_OPTS="-Dnil.alwaysUseAdHocLogger=true -XX:+UseG1GC -javaagent:nilloader.jar" -v .server:/data docker-minecraft-server-unsup:latest

[itzg]

I haven't reviewed the code yet but wanted to mention that I don't want users to have to fill out

-e CUSTOM_JAR_EXEC="-cp forge.jar:minecraft-server.jar net.minecraft.server.MinecraftServer"

Your code should be populating that variable and export'ing so it can be picked up at exec stage.

[caitlynrw]

I don't want users to have to fill out [CUSTOM_JAR_EXEC]

This could be hard to do reliably. unsup doesn't download the server software itself in the server env (I may have said it did before, whoops), instead the server software can be included as part of the packwiz data. Rewind includes metadata files for the Forge and Vanilla. This means that a pack developer could name the jar files basically anything.

I could search the directory for plausible server software like the FTBA deployer does, and/or just fallback on searching the root directory for a net.minecraft.server.MinecraftServer class.

[itzg]

How will you document the approach for users to put the right value for CUSTOM_JAR_EXEC?

This could be hard to do reliably.

Yes, reliable automation is hard to implement. Implementing on top of another automation tool is also challenging since their strategy may not fit.

Speaking of which, maybe unsup isn't a good fit for this image. Perhaps a separate image should be maintained focusing on unsup. Ideally the unsup developers would kick that off.

[caitlynrw]

I do think unsup is a good tool for this image to support.
I'll see if I can parse the unsup/packwiz manifests in a script to then find the server type and maybe search for a classpath that way. (If using unsup on the client-side too, the javaagent can update the MMC components so Forge versions and similar stuff is documented in pack.toml)

[itzg]

I do want to point out that I introduced and constantly enhance https://github.com/itzg/mc-image-helper to solve complexities like it sounds like you're describing. It became unmanageable to perform extensive json, toml, etc processing all via bash script...and I don't want to regress on that.

[caitlynrw]

Yea, saw the toml-path subcommand which looks as though it could be very helpful 👀

[itzg]

If you bump mc-image-helper to 1.53.0 here

docker-minecraft-server/Dockerfile

Line 52 in f3ed098

ARG MC_HELPER_VERSION=1.52.1

then you can use the new ini-path subcommand. The expression syntax is a little more specialized since I couldn't use the json path library with it. The syntax it supports is

• /field for global fields, such as /preset
• section/field, such as flavors/flavor
• section/field[index] but probably not applicable for unsup's