Skip to content

Add modern Forge, NeoForge, and Fabric protocol support - #51

Open
Pix3lPirat3 wants to merge 2 commits into
PrismarineJS:masterfrom
Pix3lPirat3:feat/forge-compat-matrix
Open

Pix3lPirat3 wants to merge 2 commits into
PrismarineJS:masterfrom
Pix3lPirat3:feat/forge-compat-matrix

Conversation

@Pix3lPirat3

@Pix3lPirat3 Pix3lPirat3 commented Sep 11, 2026

Copy link
Copy Markdown

Fix legacy FML handshake and reset behavior, install per-client Forge command registries, and add explicit modern Forge, NeoForge, and Fabric networking handlers. Reject unimplemented channels and registry content instead of advertising unsupported mod behavior.

  • fix FML1 initial/reset sequencing and preserve the existing forgeMods option across FML2/FML3 automatic selection
  • install per-client command argument registries and implement Forge's modern configuration handshake
  • add explicit NeoForge channel, compatibility-check, frozen-registry, and clean-server recipe negotiation
  • add Fabric common networking, registry decoding, and opt-in per-client registry mappings
  • fail explicitly for unsupported channels, codecs, recipes, flags, and versions instead of treating an advertised mod list as gameplay support

Depends on PrismarineJS/node-minecraft-protocol#1528.

This branch raises the Node.js minimum to 22 to match the companion protocol library.

This was tested against real servers;

  • Forge servers from Minecraft 1.7.10 through 26.1.2, covering FML1, FML2, FML3, and the modern configuration protocol. The exercised Forge builds were 10.13.4.1614, 14.23.5.2859, 25.0.223, 36.2.34, 37.1.1, 40.3.0, 43.5.0, 47.4.10, 48.1.0, 49.2.0, 52.1.0, 61.2.0, and 64.1.0.
  • NeoForge 20.4.251 on Minecraft 1.20.4, 21.1.250 on 1.21.1, and 21.11.45 on 1.21.11. The client completed channel negotiation, registry synchronization, command-tree decoding, and the clean-server recipe exchange. Required-channel mismatch cases were also verified to reject with the expected error.
  • Fabric Loader 0.19.5 on Minecraft 1.20.1, 1.20.2, 1.21.1, and 1.21.11 with matching Fabric API and Better Combat fixtures. On 1.21.11 the client applied all synchronized registries and decoded a real triggered custom particle and custom item component.
  • Velocity 4.1.1 build 24 transfers across two independent backends. The client reached A -> B -> A while repeating the complete handshake and receiving a new position on every backend for Forge 1.7.10/1.12.2, Forge 1.20.4 with ProxyCompatibleForge 1.3.1, NeoForge 1.20.4 with ProxyCompatibleForge 1.3.1, and Fabric 1.21.11 with FabricProxy-Lite 2.11.0.

PR #46 overlaps the mod-list override fix. Forge PR #43 supplies separate FML3 ping decoding; this branch accepts that decoded response shape but does not copy its decoder.

Dependency:

Fix legacy FML handshake and reset behavior, install per-client Forge command registries, and add explicit modern Forge, NeoForge, and Fabric networking handlers. Reject unimplemented channels and registry content instead of advertising unsupported mod behavior.

@rom1504 rom1504 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Astra agent review — AI-generated, not manually written by the maintainer.

With the explicitly required NMP #1528 candidate installed, lint and all 103 tests pass, including the TCP configuration cycles and captured registry/packet fixtures. I found one additional reconfiguration issue: Fabric-owned schemas survive a move to a backend that sends no registry-sync payload. The inline finding includes a production-client/codec reproduction and the upstream condition that permits this sequence. I did not rerun the Java Forge/NeoForge/Fabric or Velocity server matrix.

Skills used: prismarine-lifecycle-action-review traced registry state across configuration re-entry; prismarine-protocol-data-review exercised the actual compiled consumer with the declared candidate dependency; prismarine-architecture-review checked ownership of installed schemas; prismarine-review checked current head and existing discussion.


client.on('state', state => {
if (state === 'configuration') {
registryReceived = false

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Astra agent review — AI-generated, not manually written by the maintainer.

Please reset the previous session's Fabric-owned registry mappings/schemas as well as the negotiation flags. A backend need not send a replacement payload: Fabric's RegistrySyncManager.configureClient skips registry sync when there is nothing to remap. After a mapped backend A → configuration → clean backend B, registryHandler is therefore never called, while client.fabricRegistries and the helper's customPackets entries still describe A.

I reproduced this with a real NMP Client and #1528's compiled codecs: install a valid registry swapping ash/cloud IDs, enter play, then configuration/play without a new sync. B's vanilla ash bytes still decode as cloud. Explicitly clearing the helper's owned mappings restores ash. Give that cleanup a configuration-lifetime owner (preserving caller-owned custom schemas), and extend the transfer regression to a backend with no registry payload.

Skills used: prismarine-lifecycle-action-review checked re-entry without replacement state; prismarine-protocol-data-review verified the decoded consequence; prismarine-architecture-review identified ownership-preserving cleanup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants