1.0.9 cannot load on Paper 26.2: shaded CommandAPI 11.2.0 has no 26.2 handler and throws UnsupportedVersionException

[Elkidogz]

Summary

GeyserModelEngine 1.0.9 fixes the packetevents-related failure on MC 26.x (thanks — the bump to packetevents 2.13.0 is exactly what was needed), but it still cannot load on Paper 26.2 because of a second, independent problem: the shaded CommandAPI version handler has no entry for 26.2 and is configured to throw rather than fall back.

I hit this while upgrading a production server from Paper 26.1.2 to 26.2. Reporting it from jar inspection rather than a live boot — see "What I have and haven't verified" at the bottom, so you can weigh it accordingly.

Environment

Server	Paper 26.2 build 84 (26.2.build.84-stable, mappings 26.2, variant paper)
Java	Temurin 25.0.2+10 LTS
GeyserModelEngine	1.0.9 (latest tag, published 2026-07-31), sha256 5f78ca0c4cb6ee8ad7a2dd01cf69aba436623612e8bc1d12a1cae9c5b4f21901, 7,211,792 bytes
Geyser	2.11.0
ModelEngine	R4.1.1

The problem

GeyserModelEngine.class calls CommandAPI.onLoad(...) with a CommandAPI config object, so CommandAPI initialises during plugin load — before any of the packetevents work matters.

The shaded CommandAPI is 11.2.0, whose CommandAPIVersionHandler selects an implementation by matching the Paper version string. Reading the constant pool of re/imc/geysermodelengine/libs/commandapi/CommandAPIVersionHandler.class in the released 1.0.9 jar, the complete set of supported version strings is:

1.20.6, 1.21, 1.21.1, 1.21.2, 1.21.3, 1.21.4, 1.21.5,
1.21.6, 1.21.7, 1.21.8, 1.21.9, 1.21.10, 1.21.11, 26.1

26.1 is the highest — there is no 26.2 entry. The corresponding handler classes present in the jar stop at PaperNMS_26_1 / NMS_26_1.

When no version matches, CommandAPIVersionHandler consults fallbackToLatestNMS(); if that is false it throws UnsupportedVersionException (both symbols are present in the same class). CommandAPI's Bukkit/Paper config defaults fallbackToLatestNMS to false, and I could find no class under re/imc/geysermodelengine/ (39 non-shaded classes) that references fallbackToLatestNMS, so the default appears to stand.

Net effect: on Paper 26.2 the plugin should fail during load with UnsupportedVersionException, regardless of the packetevents fix.

Suggested fix

Bump the shaded CommandAPI to 12.0.0 (released 2026-07-28), which postdates Paper 26.2 — 1.0.9 was released 2026-07-31 and appears to have just missed it.

If a CommandAPI bump isn't practical right away, calling .setFallbackToLatestNMS(true) on the config would at least let it attempt the 26.1 NMS implementation on newer versions instead of hard-failing. That's obviously a weaker guarantee, so the version bump seems clearly preferable.

Why this isn't #55 / #56

Those cover 1.21.9/1.21.10 and the packetevents error. This is a distinct blocker on a different shaded dependency, and it survives the 1.0.9 packetevents fix. I couldn't find an existing issue mentioning CommandAPI or 26.2.

What I have and haven't verified

Verified directly by inspecting the released 1.0.9 jar: the shaded CommandAPI version-string table stops at 26.1; only PaperNMS_26_1/NMS_26_1 handlers ship; fallbackToLatestNMS and UnsupportedVersionException both exist in CommandAPIVersionHandler; no GeyserModelEngine class references fallbackToLatestNMS; GeyserModelEngine.class references both CommandAPI...onLoad and a CommandAPI config type.

Not verified: I have not booted 1.0.9 on 26.2 and captured a stack trace. Having found this blocker in the artifact, I deliberately didn't deploy it to production. So the failure is predicted from the code path, not observed — if you know of a reason the fallback would be enabled at runtime, I'd be glad to be wrong.

For reference, 1.0.8 on Paper 26.2 fails earlier and differently, with an NPE in the shaded packetevents SpigotReflectionUtil.initConstructors — which is what led me to try 1.0.9.

Happy to run 1.0.9 on a 26.2 lab instance and post the actual trace if that would help.

[xSquishyLiam]

I can update the dependency next time on my pc however my servers are on 26.2 and don't encounter this issue at all so that's odd

[Elkidogz]

Correction — I was wrong. 1.0.9 loads fine on Paper 26.2. Please close.

I've now actually booted it, which I should have done before filing. GeyserModelEngine 1.0.9 enables cleanly on Paper 26.2 build 92. My report was reasoning from the artifact and it reached the wrong conclusion.

What the runtime shows

[Server thread/INFO]: [CommandAPI] Loaded version PaperNMS_26_1
[Server thread/WARN]: [CommandAPI] Loading the CommandAPI with the latest and
                      potentially incompatible NMS implementation
[Server thread/INFO]: [Geyser-Spigot] Enabled extension GeyserModelEngineExtension

No UnsupportedVersionException. Plugin count 63, 63 enabled, 0 disabled.

Where my analysis went wrong

The part I got right: shaded CommandAPI 11.2.0 has no 26.2 handler, and its version table does stop at 26.1.

The part I got wrong, and it was the load-bearing part: I claimed fallbackToLatestNMS was left at false, so the missing handler would throw. It doesn't — CommandAPI falls back to PaperNMS_26_1 and logs a warning. I inferred the default from CommandAPIBukkitConfig's constructor and from finding no call to the setter in GeyserModelEngine's own classes, and I never verified that inference against a running server. A missing setter call is not proof of the effective value.

So the practical outcome on 26.2 is a warning, not a failure.

What still stands

Bumping the shaded CommandAPI to 12.0.0 would still be worth doing — running on a 26_1 NMS implementation against a 26.2 server is explicitly flagged by CommandAPI as "potentially incompatible", and command registration is not somewhere you want to be relying on a fallback path. But that's an improvement, not the blocker I described.

Apologies for the noise — filing a predicted failure as a bug report was the wrong call when a lab server was available to test it on. I'd suggest closing this unless you want to keep it open for the CommandAPI 12.0.0 bump specifically.

For completeness: 1.0.8 does genuinely fail on 26.2 with the shaded packetevents NPE (SpigotReflectionUtil.initConstructors), so 1.0.9 is a real fix for that — thanks for shipping it.