[zeng-github01]

Description

resolved #38

This PR introduces two different compatibility approaches for legacy Forge MDKs.

Python MDK Support

All Python-based MDKs are converted into a modern FG1-style userdev package.

Depending on the Forge version, processing is split into two separate pipelines:

• Forge 1.6.x and above → ProcessV2
• Forge 1.5.x and below → ProcessPython

ProcessPython

ProcessPython introduces a custom subclass of FG2Userdev to bypass FG2's requirement for dev.json.

This is necessary because dev.json was introduced in Forge 1.6.x and does not exist in earlier MDKs. By extending FG2Userdev, the implementation is able to reuse as much of the existing FG2 logic as possible while remaining compatible with older Forge versions.

Automatic Mapping Generation

This PR also adds automatic mappings generation for Python MDKs.

When processing a legacy Python MDK, a mappings archive can be generated automatically and registered through:

net.minecraftforge.mcmaven.impl.MinecraftMaven#getForgeMappings

To preserve existing mapping definitions, generated mappings are only added when no mapping entry already exists for the target Forge version.

If a mapping is already present, the existing ForgeMaven mapping takes precedence and the generated mapping is ignored.

Current Status

Due to limitations in the decompiler toolchain, the implementation currently works reliably only for Forge 1.5.x. This demonstrates that the overall compatibility strategy is technically viable.

However, Forge 1.4.7 still encounters patch application failures. The issue is suspected to be related to FernFlower decompilation output not matching the expected source format, possibly due to incompatible decompiler parameters.

At the moment, the exact parameter differences required to reproduce the expected output are not fully understood, so the investigation remains incomplete.

Summary

• Added compatibility support for legacy Python MDKs.
• Converted legacy MDKs into a modern FG1-style userdev format.
• Introduced version-specific processing paths:
  • ProcessV2 for Forge 1.6.x+
  • ProcessPython for Forge 1.5.x and older
• Added a custom FG2Userdev implementation to support MDKs without dev.json.
• Added automatic mappings generation and registration for Python MDKs.
• Existing ForgeMaven mappings always take precedence over generated mappings.
• Successfully validated on Forge 1.5.x.
• Forge 1.4.7 still requires additional investigation due to patch application failures.

[zeng-github01]

@LexManos Added experimental support for 1.5.2. The porting process appears largely successful; only a few dependency-related issues and some problems with Fernflower remain to be resolved. Currently, the dependencies are hardcoded for version 1.5.2.

Edit: CleanupTool requires a 1.4.x mode. The current 1.6.4 mode is compatible with versions 1.5 through 1.6.4. FML/Forge patches for 1.4.x rely heavily on "varn"—a patch format adopted by mcp-mcversion-srg. Additionally, a 1.5.x mode may need to be added to handle third-party libraries included in the input; the current implementation relies on manual trimming, which is highly inconvenient due to timing issues.

[zeng-github01]

No sound

[zeng-github01]

Compatibility progress update: added a 1.4.7 mode to the mcpcleanup tool and set the FML parameter to 0; the forge/fmlpatches zip has been successfully applied.

EDITED
However, there are still missing dependencies during the recompilation step; it may be necessary to hardcode a list of dependencies within StupidHacks for each major version prior to 1.6.x.

[zeng-github01]

@LexManos I’ve encountered an issue: during recompilation, the system consistently reports that I am catching an exception that is never actually thrown. It seems there is a problem with the joined.exc file within the mcp-1.5.2-srg I generated, but I’m not sure how to resolve it.

EDITED:However, version 1.6.2 does not have this issue; the primary difference in the file appears to be just the absence of the "max index" description on the first line.

[zeng-github01]

New research findings: The "recompile" error is caused by MCInject failing to correctly handle joined.exc. In version 1.5.x and earlier, joined.exc includes entries for third-party libraries (such as those from Argo); however, the version used by Mavenizer is configured to ignore classes that do not fall under the net/minecraft namespace.

@LexManos
I cannot find the source code for MCInject, which is used by Mavenizer. Consequently, progress has been put on hold for the time being.

Additionally, the mapping CSV provided by the Python MDK is missing a function mapping for "argo" (SRG->MCP). For testing purposes, I have manually added this mapping; however, a proper solution will need to be found for the production environment, as this would otherwise interfere with recompilation.