mirrors
/
CC-Tweaked
mirror of https://github.com/SquidDev-CC/CC-Tweaked
1
0
Fork 0
Code Issues Releases Wiki Activity
CC-Tweaked/projects/common/src/main/java/dan200/computercraft/shared/network/MessageType.java

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

29 lines
940 B
Java
Raw Normal View History

Add a MessageType for network messages 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.
2024-01-03 09:15:38 +00:00
// SPDX-FileCopyrightText: 2023 The CC: Tweaked Developers
//
// SPDX-License-Identifier: MPL-2.0
package dan200.computercraft.shared.network;
Update to 1.20.4
2024-01-31 20:55:14 +00:00
import net.minecraft.network.protocol.common.custom.CustomPacketPayload;
import net.minecraft.resources.ResourceLocation;
Add a MessageType for network messages 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.
2024-01-03 09:15:38 +00:00
/**
* A type of message to send over the network.
* <p>
* Much like recipe or argument serialisers, each type of {@link NetworkMessage} should have a unique type associated
* with it. This holds platform-specific information about how the packet should be sent over the network.
*
* @param <T> The type of message to send
* @see NetworkMessages
* @see NetworkMessage#type()
*/
public interface MessageType<T extends NetworkMessage<?>> {
Update to 1.20.4
2024-01-31 20:55:14 +00:00
/**
* Get the id of this message type. This will be used as the custom packet channel name.
*
* @return The id of this message type.
* @see CustomPacketPayload#id()
*/
ResourceLocation id();
Add a MessageType for network messages 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.
2024-01-03 09:15:38 +00:00
}