Player

I don't think there's any realistic use case where keeping the original deobf names is beneficial, everything but calling main will most certainly need to access obfuscated parts as well..

What "issues with the application" do you mean? There's obviously some problems if the user then runs the server as non-root due to file permissions, but that's to be expected.

Does your mod declare a dependency on Fabric Loader 0.12+? Does the behavior change if that changes?

I need to know what dependencies your fabric.mod.json declares on Loader, it controls the mixin locals algorithm being used. If you depend on a loader version >= 0.12, it'll use...

Mixin in particular is a library where we don't want to diverge too much from upstream unless there's enough of a reason for it. Did you try a sampling based...

At.target Javadoc: > must be specified as a fully-qualified member path including the class name and signature So more a case of not rejecting the invalid target cleanly, the root...

It looks like the ModifyArg is now seeing the descriptor of the Redirect target method instead of the original one.

Does the behavior change if you run with the jvm arg `-Dfabric.debug.loadLate=carpet`?

Thanks for the info, Loader 0.12 changes mod load order (by mod id in production instead of impl defined), which causes the mixin to fail. https://github.com/SpongePowered/Mixin/issues/544 is the same issue...

It is not so much a diff tool (doesn't even have a proper diff view) but for finding common parts between obfuscated jars. Tools like Proguard assign random names to...