Skip to content

add mcpforge plugin for 1.12.2 support#1

Open
vfyjxf wants to merge 8 commits into
MorphismMC:mainfrom
vfyjxf:adapt-legacy-1.12.2
Open

add mcpforge plugin for 1.12.2 support#1
vfyjxf wants to merge 8 commits into
MorphismMC:mainfrom
vfyjxf:adapt-legacy-1.12.2

Conversation

@vfyjxf

@vfyjxf vfyjxf commented Jun 28, 2026

Copy link
Copy Markdown
Member

添加了1.12.2支持,对gtceu和jei进行测试过没问题,如果要使用请将nfrt legacy部分发布到local maven才能正常工作

@vfyjxf vfyjxf force-pushed the adapt-legacy-1.12.2 branch 2 times, most recently from e6a89a7 to 1bcbfff Compare June 28, 2026 17:22
@gate-guardian gate-guardian added the type: feature [PR] Add something new for game content, code, e.t.c. label Jun 29, 2026
@vfyjxf vfyjxf force-pushed the adapt-legacy-1.12.2 branch from 1bcbfff to b83f669 Compare June 29, 2026 04:21
vfyjxf added 7 commits June 29, 2026 12:23
Mirror everything ForgeGradle-2's GradleStartCommon exposes to 1.12.2 mods
at runtime, not just notch-srg + csvDir:

PopulateForgeGradleMcpCache now derives the SRG maps FG-2 would have
generated alongside the verbatim copies: srg-mcp/mcp-srg/notch-srg are
copied, and when a notch->SRG map is available srg-notch (inverse),
notch-mcp (compose notch->SRG with SRG->MCP) and mcp-notch (its inverse)
are produced by parsing the SRG-format text. CL/FD/MD tags are preserved
through invert/compose.

McpForgeModDevPlugin.configureRunTasks sets every GradleStart.srg.*
property (srgDir, csvDir, notch-srg/notch-mcp/srg-mcp/mcp-srg/mcp-notch)
plus fml.ignoreInvalidMinecraftCertificates, so mods reading any of them
(CodeChickenLib et al.) resolve correctly. The populateForgeGradleMcpCache
lookup is now guarded with findByName since the task only exists when
mcpMappings is configured.

Also fixes the stale McpForgeExtension Javadoc (legacyForge -> mcpForge,
LegacyForgeModdingSettings -> McpForgeModdingSettings).
Verified empirically that NFRT's createMinecraftArtifacts output for the
1.12.2 legacy-MCP path is already fully MCP-named and patched (the source
patches — GLAllocation.generateDisplayLists, CrashReportCategory
.firstTwoElementsOfStackTraceMatch — are applied by NFRT's decompile/recompile
pipeline when disableRecompilation=false, the mcpforge default). Morphism
launches to the main menu (18 mods, sound, texture atlas) with the jar
post-processor disabled — the remap pass and the two method rewrites are no-ops
on an already-correct jar.

Removes the whole now-dead chain:
- LegacyForgeJarProcessor (mcpforge, 1085-line ASM remapper)
- ForgeJarPostProcessor adapter + its registration in McpForgeModDevPlugin
- JarPostProcessor SPI (main) — sole consumer was the above
- getJarPostProcessors / remapLegacyForgeMinecraftReferences /
  findRequestedResult in CreateMinecraftArtifacts (nfrtgradle)

Net -1164 lines. stripJarSignatures and removePreAppliedLegacyForgeRuntimePatches
are kept (unrelated concerns).

Note: the no-recompile path (disableRecompilation=true) still leaks obfuscated
type names (e.g. awu->EnumFacing) that binary remap misses and this processor
only partially fixed — that path is a separate NFRT-side limitation, not
something mcpforge should paper over.
…yForgeRuntimePatches

Verified empirically that NFRT's createMinecraftArtifacts output for the
default (disableRecompilation=false) legacy-MCP path is already clean: the
recompiled game jar contains no signature files, no META-INF, and no
binpatches.pack.lzma (only the harmless deobfuscation_data lzma, which was
never stripped anyway). The recompile pipeline produces fresh unsigned classes
and doesn't carry the binary-patch payload.

So stripJarSignatures and removePreAppliedLegacyForgeRuntimePatches were no-ops
on the already-clean default-path jar — same situation as the removed
LegacyForgeJarProcessor. Morphism still launches to the main menu (18 mods,
sound, texture atlas) with both removed.

Note: the no-recompile path (gameJarNoRecompWithNeoForge, built via
createBinaryWithNeoForge) DOES still carry FORGE.SF/FORGE.DSA/binpatches.pack.lzma,
but that path doesn't work for real mods anyway (binary remap leaks obfuscated
type names). Cleaning it belongs in NFRT's binary-merge step, not MDG.
The no-recompile (binary-patch) path is not viable for 1.12.2/MCP: the binary
remap leaks obfuscated type references and mangles generic signatures, so mods
cannot compile or run against gameJarNoRecompWithNeoForge. Throw an
InvalidUserCodeException if disableRecompilation is set, so users get a clear
error instead of the cryptic binary-path failures. The decompile+recompile path
remains the only supported one.
…ilation)

McpForgeModdingSettings no longer extends LegacyForgeModdingSettings; it is a
standalone type with only the fields mcpforge uses (forge/neoForge/mcp version,
mcpMappings, enabledSourceSets, obfuscateJar). Crucially there is no
disableRecompilation setter at all, so the no-recompile path cannot be expressed
- eliminating the risk at the source rather than guarding it at runtime.

The previous runtime guard in enable() is removed (no longer needed); create()
is now passed disableRecompilation=false directly.
…ooks SPI

The -XstartOnFirstThread gate (usesLegacyAppleLwjgl2) and the Forge splash
disable (configureLegacyForgeSplash) both hardcoded "1.12.2" + arch checks
directly in main. Move both behind McpToolchainHooks SPI queries:
  - usesLegacyAppleLwjgl2(mc) → mcpforge delegates to Lwjgl2Natives.shouldUse-
    AppleNativeReplacement (the single source of truth for the ARM LWJGL2 replace).
  - needsLegacyForgeSplashDisabled(mc) → mcpforge returns true for 1.12.2.

Main no longer contains any "1.12.2" string or arch sniffing; the 1.12.2
logic lives entirely in mcpforge (where it belongs). When mcpforge isn't
applied, the SPI defaults return false (modern behavior).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type: feature [PR] Add something new for game content, code, e.t.c.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants