[Forge] "incompatible modded server" when MixinExtras jar is used only server-side

[Fourmisain]

Forge does a compatibility check in the server list, marking servers as incompatible if the client doesn't have any mod that is required (and mods are marked as required by default): The server can still be joined and everything will work as expected, though it is an eye sore.

Mods can opt-out of this check via this API call:

ModLoadingContext.get().registerExtensionPoint(IExtensionPoint.DisplayTest.class,
    () -> new IExtensionPoint.DisplayTest(() -> IExtensionPoint.DisplayTest.IGNORESERVERONLY, (a, b) -> true));

This code is for 1.20.2. Previously (not exactly sure when) the constant was called NetworkConstants.IGNORESERVERONLY. Sadly the value changed too, breaking binary compatibility, so fixing this would require multiple mixinextras-forge builds.

---

As a workaround one should be able to remove implementation(include("io.github.llamalad7:mixinextras-forge:0.2.0-rc.4")) and add a Mixin plugin with a manual MixinExtrasBootstrap.init(); call. edit: Nope, one needs to shadow mixinextras-common at least.

[LlamaLad7]

I might just have to do some best effort reflection based on the current version. Thanks for the report. And if you're shadowing mixinextras make sure to relocate it as covered in the new readme.

[Fourmisain]

Right, you could just switch out the constant depending on the version.

Just double checked, the constant did change in 1.20.2 aka Forge 48.0.0. The constant is just the string "SERVER_ONLY", before that it was "OHNOES\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31\uD83D\uDE31",

If I remember correctly the API was broken once before, going from 1.16 to 1.17, or maybe 1.17 to 1.18 - though that doesn't really matter considering the missing jar-in-jar support.

From my quick testing, this simple forge version check should do the trick: ModList.get().getModContainerById("forge").get().getModInfo().getVersion().getMajorVersion() >= 48

P.S. Haven't looked at NeoForge yet.

[LlamaLad7]

Should be fixed in 0.2.0-rc.5. Please re-open if not.

[Fourmisain]

Ohh, didn't know they added displayTest in the mods.toml, that's a lot better!

The 0.2.0-rc.5 version couldn't be found on maven, apparently the JitPack build failed?

No matching toolchains found for requested specification: {languageVersion=17, vendor=any, implementation=vendor-specific} for LINUX on x86_64

Weird. The build starts out using openjdk version "1.8.0_292", apparently wants to compile the code with Java 17 but can't find a toolchain to use / download. I'm not sure how your build works, but maybe it can run directly under Java 17? You can force JitPack to use Java 17 that by adding a jitpack.yml like this.

[LlamaLad7]

It probably does need Java 17, but by now you should be using the mavencentral artifact anyway. See the new README.

[LlamaLad7]

JitPack is now fixed, but I'd 100% use the new artifact instead.