[Bug] 15.0.1 Universal fails to patch SkinManager on NeoForge 1.21.1: "matched protocol 0 but did not modify any bytecode"

[Kitty-Hivens]

CustomSkinLoader_Universal-15.0.1 on Minecraft 1.21.1 with NeoForge crashes at startup:

java.lang.IllegalStateException: Failed to transform net/minecraft/client/resources/SkinManager with customskinloader:skin-manager-patch
Caused by: java.lang.IllegalStateException: Patch 'customskinloader:skin-manager-patch:skin-manager.<init>.v1' matched protocol 0 but did not modify any bytecode. If you want to force CustomSkinLoader to ignore this patch failure, add -Dcustomskinloader.ignorePatchFailure=true to the JVM arguments.

Reproduced identically on NeoForge 21.1.234 and 21.1.241. Sinytra Connector is present in the modpack; disabling the other skin-related mods (EMF/ETF) does not change the outcome.

With -Dcustomskinloader.ignorePatchFailure=true the game starts, but skins do not load at all (default skin renders for everyone), so the failed SkinManager hook is load-bearing rather than optional.

Full log available on request.

[ZekerZhayard]

I cannot reproduce this issue locally.

Please upload:

• logs/latest.log
• logs/debug.log

Thanks!

[ZekerZhayard]

Additionally, I think this may be related to the launcher rather than the mod itself.
If the launcher does not add the vanilla Minecraft jar to the classpath, this issue may be triggered. The official launcher behavior is that the vanilla jar should be included in the classpath.

[Kitty-Hivens]

You are right, thanks -- checked our launcher (a custom one) and it does filter the vanilla client jar out of the game classpath. That explains why the failure reproduced across NeoForge versions and mod combinations. We will fix the classpath on the launcher side and re-test.

Requested logs from a failing session (latest.log + debug.log): https://gist.github.com/Kitty-Hivens/b0bab97cdc3675d873280627687d7b1a

[Kitty-Hivens]

Correction to my previous comment -- the classpath lead does not hold up. Two findings after a closer look:

1. The exclusion I mentioned is on a different launch path of our launcher. The failing instance launches through a path that intentionally leaves the vanilla jar off -cp and provides it through FML's locators (putting it back there produces reads more than one module named minecraft).
2. More decisively, the logs I attached show CSL successfully transforming other classes from that same vanilla client jar in the failing session:

Transformed net/minecraft/client/renderer/texture/HttpTexture with [customskinloader:skin-texture-patch]
Transformed net/minecraft/server/packs/resources/Resource with [customskinloader:interface-patch]
Transformed net/minecraft/server/packs/resources/ResourceManager with [customskinloader:interface-patch]

So the class data is reachable; what fails is specifically skin-manager-patch (skin-manager.<init>.v1, register-texture, register-skins, get-insecure-skin-information) and render-patch:player-tab-overlay.render.v1, all reporting matched protocol 0 but did not modify any bytecode. Environment: NeoForge 21.1.234 and 21.1.241, official mappings, Sinytra Connector present.

It looks like the patch patterns do not match this SkinManager / PlayerTabOverlay bytecode in that environment, rather than a jar being missing. Happy to dump the actual SkinManager.<init> bytecode from the srg client jar if that helps.

[ZekerZhayard]

(I don't know how your launcher organizes the game directory, so the following description assumes the directory layout created by the official Minecraft launcher.)

What I mean is not the vanilla jars under .minecraft/libraries/net/neoforged. I mean the version jar at:

.minecraft/versions/<version>/<version>.jar

CustomSkinLoader reads the version.json inside that jar to determine the current Minecraft version. If that file cannot be found, it falls back to version 0, which is treated as a version earlier than Minecraft 1.14 (because version.json did not exist before snapshot 18w43b / Minecraft 1.14).

Also, regarding the patches you mentioned: those patches are almost version-independent, so the fact that they were applied successfully does not necessarily mean the version was detected correctly.

[Kitty-Hivens]

Confirmed -- that is exactly it. Checked our layout against your description:

1. version.json is present in the root of the client-<version>-extra.jar that the NeoForge installer produces, but our launch path does not put that jar on -cp (only the srg client jar is there). So ClassLoader.getSystemClassLoader().getResourceAsStream("version.json") in VersionMetadataReader finds nothing.

2. The fallback is also dead in this environment: net/minecraft/realms/RealmsSharedConstants no longer exists in 1.21.1 (the protocol constant lives in net/minecraft/SharedConstants now), so the bytecode fallback reads nothing either.

Both detection paths come up empty, CSL assumes version 0 and selects the pre-1.14 patch variants against 1.21.1 bytecode -- which is precisely the matched protocol 0 but did not modify any bytecode failure. And since the patches that did apply are near version-independent, their success was a red herring, as you said.

The fix is on our launcher's side: restore the client extra jar on the classpath, matching the official launcher layout. It carries no classes (only version.json plus assets/data), so it does not trigger the module conflict that keeps the main client jar off -cp. I will report back here once it is tested.

One small suggestion, feel free to ignore: a secondary fallback reading the protocol constant from net/minecraft/SharedConstants would make detection survive layouts like ours on modern versions. Happy to file that separately if useful.

[Kitty-Hivens]

Fix confirmed. We restored the client extra jar on the pack classpath, and version detection now resolves 1.21.1 correctly: all patches apply (no more matched protocol 0), the game starts, and skins load fine, HD included, without ignorePatchFailure.

Thanks for pointing at the version detection mechanism -- that was the missing piece. Closing, since the root cause was on our launcher's side. The SharedConstants fallback offer from my previous comment stands if you want it as a separate issue.