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/client/PocketComputerDataMessage.java

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

61 lines
2.6 KiB
Java
Raw Normal View History

License CC:T according to the REUSE specification (#1351) This adds SPDX license headers to all source code files, following the REUSE[1] specification. This does not include any asset files (such as generated JSON files, or textures). While REUSE does support doing so with ".license" files, for now we define these licences using the .reuse/dep5 file. [1]: https://reuse.software/
2023-03-15 21:52:13 +00:00
// SPDX-FileCopyrightText: 2022 The CC: Tweaked Developers
//
// SPDX-License-Identifier: MPL-2.0
Remove ClientComputer Historically CC has maintained two computer registries; one on the server (which runs the actual computer) and one on the client (which stores the terminal and some small bits of additional data). This means when a user opens the computer UI, we send the terminal contents and store it in the client computer registry. We then send the instance id alongside the "open container" packet, which is used to look up the client computer (and thus terminal) in our client-side registry. This patch makes the computer menu syncing behaviour more consistent with vanilla. The initial terminal contents is sent alongside the "open container" packet, and subsequent terminal changes apply /just/ to the open container. Computer on/off state is synced via a vanilla ContainerData/IIntArray. Likewise, sending user input to the server now targets the open container, rather than an arbitrary instance id. The one remaining usage of ClientComputer is for pocket computers. For these, we still need to sync the current on/off/blinking state and the pocket computer light. We don't need the full ClientComputer interface for this case (after all, you can't send input to a pocket computer someone else is holding!). This means we can tear out ClientComputer and ClientComputerRegistry, replacing it with a much simpler ClientPocketComputers store. This in turn allows the following changes: - Remove IComputer, as we no longer need to abstract over client and server computers. - Likewise, we can merge ComputerRegistry into the server registry. This commit also cleans up the handling of instance IDs a little bit: ServerComputers are now responsible for generating their ID and adding/removing themselves from the registry. - As the client-side terminal will never be null, we can remove a whole bunch of null checks throughout the codebase. - As the terminal is available immediately, we don't need to explicitly pass in terminal sizes to the computer GUIs. This means we're no longer reliant on those config values on the client side! - Remove the "request computer state" packet. Pocket computers now store which players need to know the computer state, automatically sending data when a new player starts tracking the computer.
2022-10-21 17:17:42 +00:00
package dan200.computercraft.shared.network.client;
import dan200.computercraft.shared.computer.core.ComputerState;
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
import dan200.computercraft.shared.computer.core.ServerComputer;
Remove all Minecraft references from the core package This is an initial step before refactoring this into a separate module. It's definitely not complete - there's a lot of work needed to remove referneces to the main ComputerCraft class for instance - but is a useful first step.
2022-10-30 09:20:26 +00:00
import dan200.computercraft.shared.computer.terminal.TerminalState;
Remove ClientComputer Historically CC has maintained two computer registries; one on the server (which runs the actual computer) and one on the client (which stores the terminal and some small bits of additional data). This means when a user opens the computer UI, we send the terminal contents and store it in the client computer registry. We then send the instance id alongside the "open container" packet, which is used to look up the client computer (and thus terminal) in our client-side registry. This patch makes the computer menu syncing behaviour more consistent with vanilla. The initial terminal contents is sent alongside the "open container" packet, and subsequent terminal changes apply /just/ to the open container. Computer on/off state is synced via a vanilla ContainerData/IIntArray. Likewise, sending user input to the server now targets the open container, rather than an arbitrary instance id. The one remaining usage of ClientComputer is for pocket computers. For these, we still need to sync the current on/off/blinking state and the pocket computer light. We don't need the full ClientComputer interface for this case (after all, you can't send input to a pocket computer someone else is holding!). This means we can tear out ClientComputer and ClientComputerRegistry, replacing it with a much simpler ClientPocketComputers store. This in turn allows the following changes: - Remove IComputer, as we no longer need to abstract over client and server computers. - Likewise, we can merge ComputerRegistry into the server registry. This commit also cleans up the handling of instance IDs a little bit: ServerComputers are now responsible for generating their ID and adding/removing themselves from the registry. - As the client-side terminal will never be null, we can remove a whole bunch of null checks throughout the codebase. - As the terminal is available immediately, we don't need to explicitly pass in terminal sizes to the computer GUIs. This means we're no longer reliant on those config values on the client side! - Remove the "request computer state" packet. Pocket computers now store which players need to know the computer state, automatically sending data when a new player starts tracking the computer.
2022-10-21 17:17:42 +00:00
import dan200.computercraft.shared.network.NetworkMessage;
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
import dan200.computercraft.shared.network.NetworkMessages;
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
import dan200.computercraft.shared.network.codec.MoreStreamCodecs;
Remove ClientComputer Historically CC has maintained two computer registries; one on the server (which runs the actual computer) and one on the client (which stores the terminal and some small bits of additional data). This means when a user opens the computer UI, we send the terminal contents and store it in the client computer registry. We then send the instance id alongside the "open container" packet, which is used to look up the client computer (and thus terminal) in our client-side registry. This patch makes the computer menu syncing behaviour more consistent with vanilla. The initial terminal contents is sent alongside the "open container" packet, and subsequent terminal changes apply /just/ to the open container. Computer on/off state is synced via a vanilla ContainerData/IIntArray. Likewise, sending user input to the server now targets the open container, rather than an arbitrary instance id. The one remaining usage of ClientComputer is for pocket computers. For these, we still need to sync the current on/off/blinking state and the pocket computer light. We don't need the full ClientComputer interface for this case (after all, you can't send input to a pocket computer someone else is holding!). This means we can tear out ClientComputer and ClientComputerRegistry, replacing it with a much simpler ClientPocketComputers store. This in turn allows the following changes: - Remove IComputer, as we no longer need to abstract over client and server computers. - Likewise, we can merge ComputerRegistry into the server registry. This commit also cleans up the handling of instance IDs a little bit: ServerComputers are now responsible for generating their ID and adding/removing themselves from the registry. - As the client-side terminal will never be null, we can remove a whole bunch of null checks throughout the codebase. - As the terminal is available immediately, we don't need to explicitly pass in terminal sizes to the computer GUIs. This means we're no longer reliant on those config values on the client side! - Remove the "request computer state" packet. Pocket computers now store which players need to know the computer state, automatically sending data when a new player starts tracking the computer.
2022-10-21 17:17:42 +00:00
import dan200.computercraft.shared.pocket.core.PocketServerComputer;
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
import net.minecraft.core.UUIDUtil;
import net.minecraft.network.RegistryFriendlyByteBuf;
import net.minecraft.network.codec.ByteBufCodecs;
import net.minecraft.network.codec.StreamCodec;
import net.minecraft.network.protocol.common.custom.CustomPacketPayload;
Remove ClientComputer Historically CC has maintained two computer registries; one on the server (which runs the actual computer) and one on the client (which stores the terminal and some small bits of additional data). This means when a user opens the computer UI, we send the terminal contents and store it in the client computer registry. We then send the instance id alongside the "open container" packet, which is used to look up the client computer (and thus terminal) in our client-side registry. This patch makes the computer menu syncing behaviour more consistent with vanilla. The initial terminal contents is sent alongside the "open container" packet, and subsequent terminal changes apply /just/ to the open container. Computer on/off state is synced via a vanilla ContainerData/IIntArray. Likewise, sending user input to the server now targets the open container, rather than an arbitrary instance id. The one remaining usage of ClientComputer is for pocket computers. For these, we still need to sync the current on/off/blinking state and the pocket computer light. We don't need the full ClientComputer interface for this case (after all, you can't send input to a pocket computer someone else is holding!). This means we can tear out ClientComputer and ClientComputerRegistry, replacing it with a much simpler ClientPocketComputers store. This in turn allows the following changes: - Remove IComputer, as we no longer need to abstract over client and server computers. - Likewise, we can merge ComputerRegistry into the server registry. This commit also cleans up the handling of instance IDs a little bit: ServerComputers are now responsible for generating their ID and adding/removing themselves from the registry. - As the client-side terminal will never be null, we can remove a whole bunch of null checks throughout the codebase. - As the terminal is available immediately, we don't need to explicitly pass in terminal sizes to the computer GUIs. This means we're no longer reliant on those config values on the client side! - Remove the "request computer state" packet. Pocket computers now store which players need to know the computer state, automatically sending data when a new player starts tracking the computer.
2022-10-21 17:17:42 +00:00
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
import java.util.Optional;
Replace integer instance IDs with UUIDs Here's a fun bug you can try at home: - Create a new world - Spawn in a pocket computer, turn it on, and place it in a chest. - Reload the world - the pocket computer in the chest should now be off. - Spawn in a new pocket computer, and turn it on. The computer in chest will also appear to be on! This bug has been present since pocket computers were added (27th March, 2024). When a pocket computer is added to a player's inventory, it is assigned a unique *per-session* "instance id" , which is used to find the associated computer. Note the "per-session" there - these ids will be reused if you reload the world (or restart the server). In the above bug, we see the following: - The first pocket computer is assigned an instance id of 0. - After reloading, the second pocket computer is assigned an instance id of 0. - If the first pocket computer was in our inventory, it'd be ticked and assigned a new instance id. However, because it's in an inventory, it keeps its old one. - Both computers look up their client-side computer state and get the same value, meaning the first pocket computer mirrors the second! To fix this, we now ensure instance ids are entirely unique (not just per-session). Rather than sequentially assigning an int, we now use a random UUID (we probably could get away with a random long, but this feels more idiomatic). This has a couple of user-visible changes: - /computercraft no longer lists instance ids outside of dumping an individual computer. - The @c[instance=...] selector uses UUIDs. We still use int instance ids for the legacy selector, but that'll be removed in a later MC version. - Pocket computers now store a UUID rather than an int. Related to this change (I made this change first, but then they got kinda mixed up together), we now only create PocketComputerData when receiving server data. This makes the code a little uglier in some places (the data may now be null), but means we don't populate the client-side pocket computer map with computers the server doesn't know about.
2024-03-17 12:21:21 +00:00
import java.util.UUID;
Remove ClientComputer Historically CC has maintained two computer registries; one on the server (which runs the actual computer) and one on the client (which stores the terminal and some small bits of additional data). This means when a user opens the computer UI, we send the terminal contents and store it in the client computer registry. We then send the instance id alongside the "open container" packet, which is used to look up the client computer (and thus terminal) in our client-side registry. This patch makes the computer menu syncing behaviour more consistent with vanilla. The initial terminal contents is sent alongside the "open container" packet, and subsequent terminal changes apply /just/ to the open container. Computer on/off state is synced via a vanilla ContainerData/IIntArray. Likewise, sending user input to the server now targets the open container, rather than an arbitrary instance id. The one remaining usage of ClientComputer is for pocket computers. For these, we still need to sync the current on/off/blinking state and the pocket computer light. We don't need the full ClientComputer interface for this case (after all, you can't send input to a pocket computer someone else is holding!). This means we can tear out ClientComputer and ClientComputerRegistry, replacing it with a much simpler ClientPocketComputers store. This in turn allows the following changes: - Remove IComputer, as we no longer need to abstract over client and server computers. - Likewise, we can merge ComputerRegistry into the server registry. This commit also cleans up the handling of instance IDs a little bit: ServerComputers are now responsible for generating their ID and adding/removing themselves from the registry. - As the client-side terminal will never be null, we can remove a whole bunch of null checks throughout the codebase. - As the terminal is available immediately, we don't need to explicitly pass in terminal sizes to the computer GUIs. This means we're no longer reliant on those config values on the client side! - Remove the "request computer state" packet. Pocket computers now store which players need to know the computer state, automatically sending data when a new player starts tracking the computer.
2022-10-21 17:17:42 +00:00
/**
* Provides additional data about a client computer, such as its ID and current state.
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
*
* @param id The {@linkplain ServerComputer#getInstanceUUID() instance id} of the pocket computer.
* @param state Whether the computer is on, off, or blinking.
* @param lightState The colour of the light, or {@code -1} if off.
* @param terminal The computer's terminal. This may be absent, in which case the terminal will not be updated on.
Remove ClientComputer Historically CC has maintained two computer registries; one on the server (which runs the actual computer) and one on the client (which stores the terminal and some small bits of additional data). This means when a user opens the computer UI, we send the terminal contents and store it in the client computer registry. We then send the instance id alongside the "open container" packet, which is used to look up the client computer (and thus terminal) in our client-side registry. This patch makes the computer menu syncing behaviour more consistent with vanilla. The initial terminal contents is sent alongside the "open container" packet, and subsequent terminal changes apply /just/ to the open container. Computer on/off state is synced via a vanilla ContainerData/IIntArray. Likewise, sending user input to the server now targets the open container, rather than an arbitrary instance id. The one remaining usage of ClientComputer is for pocket computers. For these, we still need to sync the current on/off/blinking state and the pocket computer light. We don't need the full ClientComputer interface for this case (after all, you can't send input to a pocket computer someone else is holding!). This means we can tear out ClientComputer and ClientComputerRegistry, replacing it with a much simpler ClientPocketComputers store. This in turn allows the following changes: - Remove IComputer, as we no longer need to abstract over client and server computers. - Likewise, we can merge ComputerRegistry into the server registry. This commit also cleans up the handling of instance IDs a little bit: ServerComputers are now responsible for generating their ID and adding/removing themselves from the registry. - As the client-side terminal will never be null, we can remove a whole bunch of null checks throughout the codebase. - As the terminal is available immediately, we don't need to explicitly pass in terminal sizes to the computer GUIs. This means we're no longer reliant on those config values on the client side! - Remove the "request computer state" packet. Pocket computers now store which players need to know the computer state, automatically sending data when a new player starts tracking the computer.
2022-10-21 17:17:42 +00:00
*/
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
public record PocketComputerDataMessage(
UUID id, ComputerState state, int lightState, Optional<TerminalState> terminal
) implements NetworkMessage<ClientNetworkContext> {
public static final StreamCodec<RegistryFriendlyByteBuf, PocketComputerDataMessage> STREAM_CODEC = StreamCodec.composite(
UUIDUtil.STREAM_CODEC, PocketComputerDataMessage::id,
MoreStreamCodecs.ofEnum(ComputerState.class), PocketComputerDataMessage::state,
ByteBufCodecs.VAR_INT, PocketComputerDataMessage::lightState,
ByteBufCodecs.optional(TerminalState.STREAM_CODEC), PocketComputerDataMessage::terminal,
PocketComputerDataMessage::new
);
Remove ClientComputer Historically CC has maintained two computer registries; one on the server (which runs the actual computer) and one on the client (which stores the terminal and some small bits of additional data). This means when a user opens the computer UI, we send the terminal contents and store it in the client computer registry. We then send the instance id alongside the "open container" packet, which is used to look up the client computer (and thus terminal) in our client-side registry. This patch makes the computer menu syncing behaviour more consistent with vanilla. The initial terminal contents is sent alongside the "open container" packet, and subsequent terminal changes apply /just/ to the open container. Computer on/off state is synced via a vanilla ContainerData/IIntArray. Likewise, sending user input to the server now targets the open container, rather than an arbitrary instance id. The one remaining usage of ClientComputer is for pocket computers. For these, we still need to sync the current on/off/blinking state and the pocket computer light. We don't need the full ClientComputer interface for this case (after all, you can't send input to a pocket computer someone else is holding!). This means we can tear out ClientComputer and ClientComputerRegistry, replacing it with a much simpler ClientPocketComputers store. This in turn allows the following changes: - Remove IComputer, as we no longer need to abstract over client and server computers. - Likewise, we can merge ComputerRegistry into the server registry. This commit also cleans up the handling of instance IDs a little bit: ServerComputers are now responsible for generating their ID and adding/removing themselves from the registry. - As the client-side terminal will never be null, we can remove a whole bunch of null checks throughout the codebase. - As the terminal is available immediately, we don't need to explicitly pass in terminal sizes to the computer GUIs. This means we're no longer reliant on those config values on the client side! - Remove the "request computer state" packet. Pocket computers now store which players need to know the computer state, automatically sending data when a new player starts tracking the computer.
2022-10-21 17:17:42 +00:00
public PocketComputerDataMessage(PocketServerComputer computer, boolean sendTerminal) {
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
this(
computer.getInstanceUUID(),
computer.getState(),
computer.getLight(),
sendTerminal ? Optional.of(computer.getTerminalState()) : Optional.empty()
);
Remove ClientComputer Historically CC has maintained two computer registries; one on the server (which runs the actual computer) and one on the client (which stores the terminal and some small bits of additional data). This means when a user opens the computer UI, we send the terminal contents and store it in the client computer registry. We then send the instance id alongside the "open container" packet, which is used to look up the client computer (and thus terminal) in our client-side registry. This patch makes the computer menu syncing behaviour more consistent with vanilla. The initial terminal contents is sent alongside the "open container" packet, and subsequent terminal changes apply /just/ to the open container. Computer on/off state is synced via a vanilla ContainerData/IIntArray. Likewise, sending user input to the server now targets the open container, rather than an arbitrary instance id. The one remaining usage of ClientComputer is for pocket computers. For these, we still need to sync the current on/off/blinking state and the pocket computer light. We don't need the full ClientComputer interface for this case (after all, you can't send input to a pocket computer someone else is holding!). This means we can tear out ClientComputer and ClientComputerRegistry, replacing it with a much simpler ClientPocketComputers store. This in turn allows the following changes: - Remove IComputer, as we no longer need to abstract over client and server computers. - Likewise, we can merge ComputerRegistry into the server registry. This commit also cleans up the handling of instance IDs a little bit: ServerComputers are now responsible for generating their ID and adding/removing themselves from the registry. - As the client-side terminal will never be null, we can remove a whole bunch of null checks throughout the codebase. - As the terminal is available immediately, we don't need to explicitly pass in terminal sizes to the computer GUIs. This means we're no longer reliant on those config values on the client side! - Remove the "request computer state" packet. Pocket computers now store which players need to know the computer state, automatically sending data when a new player starts tracking the computer.
2022-10-21 17:17:42 +00:00
}
@Override
Make net code more multi-loader friendly NetworkMessage follows vanilla's Packet much more closely now: the handler takes a context argument, which varies between the client and server. - The server handler just returns the ServerPlayer who sent the message. - The client context provides handleXyz(...) methods for each clientbound packet. Our packet subclasses call the appropriate method - the implementation of which contains the actual implementation. Doing this allows us to move a whole bunch of client-specific code into the main client package, dropping several @OnlyIn annotations and generally reducing the risk of accidentally loading client classes on the server. We also abstract out some packet sending and general networking code to make it easier to use in a multi-loader context.
2022-11-06 20:12:32 +00:00
public void handle(ClientNetworkContext context) {
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
context.handlePocketComputerData(id, state, lightState, terminal.orElse(null));
Remove ClientComputer Historically CC has maintained two computer registries; one on the server (which runs the actual computer) and one on the client (which stores the terminal and some small bits of additional data). This means when a user opens the computer UI, we send the terminal contents and store it in the client computer registry. We then send the instance id alongside the "open container" packet, which is used to look up the client computer (and thus terminal) in our client-side registry. This patch makes the computer menu syncing behaviour more consistent with vanilla. The initial terminal contents is sent alongside the "open container" packet, and subsequent terminal changes apply /just/ to the open container. Computer on/off state is synced via a vanilla ContainerData/IIntArray. Likewise, sending user input to the server now targets the open container, rather than an arbitrary instance id. The one remaining usage of ClientComputer is for pocket computers. For these, we still need to sync the current on/off/blinking state and the pocket computer light. We don't need the full ClientComputer interface for this case (after all, you can't send input to a pocket computer someone else is holding!). This means we can tear out ClientComputer and ClientComputerRegistry, replacing it with a much simpler ClientPocketComputers store. This in turn allows the following changes: - Remove IComputer, as we no longer need to abstract over client and server computers. - Likewise, we can merge ComputerRegistry into the server registry. This commit also cleans up the handling of instance IDs a little bit: ServerComputers are now responsible for generating their ID and adding/removing themselves from the registry. - As the client-side terminal will never be null, we can remove a whole bunch of null checks throughout the codebase. - As the terminal is available immediately, we don't need to explicitly pass in terminal sizes to the computer GUIs. This means we're no longer reliant on those config values on the client side! - Remove the "request computer state" packet. Pocket computers now store which players need to know the computer state, automatically sending data when a new player starts tracking the computer.
2022-10-21 17:17:42 +00:00
}
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
@Override
Update to 1.20.5 - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 19:17:43 +00:00
public CustomPacketPayload.Type<PocketComputerDataMessage> type() {
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
return NetworkMessages.POCKET_COMPUTER_DATA;
}
Remove ClientComputer Historically CC has maintained two computer registries; one on the server (which runs the actual computer) and one on the client (which stores the terminal and some small bits of additional data). This means when a user opens the computer UI, we send the terminal contents and store it in the client computer registry. We then send the instance id alongside the "open container" packet, which is used to look up the client computer (and thus terminal) in our client-side registry. This patch makes the computer menu syncing behaviour more consistent with vanilla. The initial terminal contents is sent alongside the "open container" packet, and subsequent terminal changes apply /just/ to the open container. Computer on/off state is synced via a vanilla ContainerData/IIntArray. Likewise, sending user input to the server now targets the open container, rather than an arbitrary instance id. The one remaining usage of ClientComputer is for pocket computers. For these, we still need to sync the current on/off/blinking state and the pocket computer light. We don't need the full ClientComputer interface for this case (after all, you can't send input to a pocket computer someone else is holding!). This means we can tear out ClientComputer and ClientComputerRegistry, replacing it with a much simpler ClientPocketComputers store. This in turn allows the following changes: - Remove IComputer, as we no longer need to abstract over client and server computers. - Likewise, we can merge ComputerRegistry into the server registry. This commit also cleans up the handling of instance IDs a little bit: ServerComputers are now responsible for generating their ID and adding/removing themselves from the registry. - As the client-side terminal will never be null, we can remove a whole bunch of null checks throughout the codebase. - As the terminal is available immediately, we don't need to explicitly pass in terminal sizes to the computer GUIs. This means we're no longer reliant on those config values on the client side! - Remove the "request computer state" packet. Pocket computers now store which players need to know the computer state, automatically sending data when a new player starts tracking the computer.
2022-10-21 17:17:42 +00:00
}