Fix missing controller result codecs on clients

[Ricket]

Summary

Explicitly register the XNet controller list-result codecs during client setup.

This prevents clients from disconnecting when opening an XNet Controller if the annotation-driven command registration is not present in McJtyLib's client-side command-info registry.

Problem

Opening an XNet Controller could disconnect the client with:

Internal Exception: io.netty.handler.codec.DecoderException:
Failed to decode packet 'clientbound/minecraft:custom_payload'

The underlying exception was:

Failed decoding custom payload mcjtylib:sendresulttoclient:
java.lang.IllegalStateException:
Command 'xnet.controller.getChannelInfo' is not registered!

The server successfully handles the request and sends a mcjtylib:sendresulttoclient payload. While decoding that payload, the client reads the command name and looks up its CommandInfo through McJtyLib.getCommandInfo(). The lookup returns null, so the payload cannot be decoded.

TileEntityController.CMD_GETCHANNELS and CMD_GETCONNECTEDBLOCKS already have the appropriate @ServerCommand annotations. McJtyLib normally discovers those annotations while registering the block and uses them to populate its command-info registry. However, in the affected client environment, the corresponding entry was absent when the payload arrived.

Fix

Register the serializers for these two controller list commands explicitly during FMLClientSetupEvent:

• xnet.controller.getChannelInfo
• xnet.controller.getConnectedBlocks

The registrations use the existing command names, result types, and serializer implementations already declared by TileEntityController.

This is intentionally a client-side initialization fix. It does not change:

• Packet IDs or payload encoding
• Command names
• Mod IDs or versions
• Server behavior
• Saved data

The small helper mirrors the raw ISerializer boundary already used by McJtyLib's annotation scanner. McJtyLib's registerListCommandInfo() accepts functions typed with FriendlyByteBuf, while ISerializer exposes functions typed with RegistryFriendlyByteBuf.

Reproduction environment

• Minecraft 1.21.1
• NeoForge 21.1.234
• XNet 7.0.7
• McJtyLib 9.0.21
• All the Mons 1.1.1
• Dedicated server with matching client and server mod JARs

Before the change:

1. Join the dedicated server.
2. Open an XNet Controller.
3. The client disconnects while decoding xnet.controller.getChannelInfo.

Testing

• Built successfully with Java 21 using ./gradlew build.
• Installed the patched XNet JAR on the client only.
• Left the dedicated server unchanged.
• Joined the existing server and opened the previously affected XNet Controller.
• The controller opened successfully without disconnecting the client.
• The client remained compatible with the unmodified XNet 7.0.7 server.

The project currently reports no test sources for its Gradle test and testJunit tasks.

[Ricket]

Actually this might not be the root cause. It does not reproduce consistently. So, after going another round with my agent, it found this other possible cause:

---

McJtyLib stores all command metadata in this:

private static final Map<String, CommandInfo> commandInfos = new HashMap<>();

Multiple McJty-family mods can register commands during NeoForge’s parallel mod construction. Concurrent writes to a plain HashMap are unsafe and can nondeterministically lose entries.

That explanation fits the evidence:

• The entry was missing for the entire original launch.
• It failed three times during that launch.
• It exists in later stock launches.
• Nothing explicitly clears the map.
• The same exact JAR can therefore work or fail between launches.

Our XNet patch performs another put during client setup. That may mask a lost entry, but client setup is also a parallel lifecycle phase. It is therefore a defensive workaround, not a demonstrated root-cause fix—and arguably does make XNet messier.

---

I'm out of time tonight but it could be worth doing some load/fuzz type testing to try to get a repro. Or simply acknowledge if the above is true and switch that to a concurrent map.