mirror of
https://github.com/SquidDev-CC/CC-Tweaked
synced 2025-03-09 13:08:13 +00:00
234f69e8e5
Everything old is new again! CC's network message implementation has gone through several iterations: - Originally network messages were implemented with a single class, which held an packet id/type and and opaque blobs of data (as string/int/byte/NBT arrays), and a big switch statement to decode and process this data. - In 42d3901ee37892e259de26ebb57cf59ce284416e, we split the messages into different classes all inheriting from NetworkMessage - this bit we've stuck with ever since. Each packet had a `getId(): int` method, which returned the discriminator for this packet. - However, getId() was only used when registering the packet, not when sending, and so in ce0685c31f7315d15d3250c6c8605171b33aa99f we removed it, just passing in a constant integer at registration instead. - In 53abe5e56eec6840890770b6ec36a5d009357da7, we made some relatively minor changes to make the code more multi-loader/split-source friendly. However, this meant when we finally came to add Fabric support (8152f19b6efd71b66c3821ad94aacaddb7d26298), we had to re-implement a lot of Forge's network code. In 1.20.4, Forge moves to a system much closer to Fabric's (and indeed, Minecraft's own CustomPacketPayload), and so it makes sense to adapt to that now. As such, we: - Add a new MessageType interface. This is implemented by the loader-specific modules, and holds whatever information is needed to register the packet (e.g. discriminator, reader function). - Each NetworkMessage now has a type(): MessageType<?> function. This is used by the Fabric networking code (and for NeoForge's on 1.20.4) instead of a class lookup. - NetworkMessages now creates/stores these MessageType<T>s (much like we'd do for registries), and provides getters for the clientbound/serverbound messages. Mod initialisers then call these getters to register packets. - For Forge, this is relatively unchanged. For Fabric, we now `FabricPacket`s.