Running game with custom mappings and namespace outside fabric-loom.

[qyl27]

This is an enhancement. It added an easier way to run the game with any mapping file and target namespace without fabric-loom for debugging.
I have some errors couldn't reproduce when starting with the IDE. So I want to launch the game with named namespace for clearly inspecting, instead of searching on linkie.

It added some property:

• fabric.development.deobfGameJar for deobf the game jar, although we're in development.
• fabric.mappingsPath can load yarn mappings from an URI (we must use the resource named mappings/mappings.tiny in the classpath before).
• fabric.targetNamespace can be set to something other which in the mappings, maybe even helps for versioning it?

This PR won't break the existing behaviors, and passed the unit tests on my machine.

[Player3324]

I'm afraid this doesn't quite appear like the right approach, but I've been experiencing the same limitations and worked on them. The root cause is that the development flag is heavily overloaded with meanings which don't necessarily coincide for all reasonable scenarios. It controls namespace selection, whether to deobfuscate, the namespace selection, enabling the class path mod finder, extra debugging/verification etc.

This is a longer process, some work already landed in the current branch, there's more in the extension branch, some extra work is yet to be done.

With these changes you'd supply the game jar and mappings the regular way, targetNamespace is already implemented in the branch. deobfGameJar is implied through a mismatch between gameMappingNamespace and runtimeMappingNamespace. I may add something more explicit for mappingsPath since putting it on the class path is not preferred, I have a PR in the works that move game libraries similarly and may put that on top after discussing the loom implications.

[qyl27]

I'm afraid this doesn't quite appear like the right approach, but I've been experiencing the same limitations and worked on them. The root cause is that the development flag is heavily overloaded with meanings which don't necessarily coincide for all reasonable scenarios. It controls namespace selection, whether to deobfuscate, the namespace selection, enabling the class path mod finder, extra debugging/verification etc.

This is a longer process, some work already landed in the current branch, there's more in the extension branch, some extra work is yet to be done.

With these changes you'd supply the game jar and mappings the regular way, targetNamespace is already implemented in the branch. deobfGameJar is implied through a mismatch between gameMappingNamespace and runtimeMappingNamespace. I may add something more explicit for mappingsPath since putting it on the class path is not preferred, I have a PR in the works that move game libraries similarly and may put that on top after discussing the loom implications.

Noticed the branch was stale for 10 months?

I agree that deobfGameJar was implied the mismatch between original namespace and target namespaces. Its a large change I think. I want to treat this PR as a minor enhancement.

Explicit adding the mappings path because we have only a mapping with official and intermediary namespaces by default at runtime. In developing environment, the mapping with named was provided by loom. Otherwise, we have to create a mappings.jar and add to classpath manually.