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/ClientNetworkContext.java

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

47 lines
1.8 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
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
package dan200.computercraft.shared.network.client;
import dan200.computercraft.shared.command.text.TableBuilder;
import dan200.computercraft.shared.computer.core.ComputerState;
import dan200.computercraft.shared.computer.terminal.TerminalState;
import dan200.computercraft.shared.computer.upload.UploadResult;
Send entire DFPWM encoder state to the client This ensures the client decoder is in sync with the server. Well, mostly - we don't handle the anti-jerk, but that should correct itself within a few samples. Fixes #1748
2024-03-15 18:25:57 +00:00
import dan200.computercraft.shared.peripheral.speaker.EncodedAudio;
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
import dan200.computercraft.shared.peripheral.speaker.SpeakerPosition;
import net.minecraft.core.BlockPos;
import net.minecraft.network.chat.Component;
import net.minecraft.resources.ResourceLocation;
import net.minecraft.sounds.SoundEvent;
import javax.annotation.Nullable;
import java.util.UUID;
/**
* The context under which clientbound packets are evaluated.
*/
public interface ClientNetworkContext {
void handleChatTable(TableBuilder table);
void handleComputerTerminal(int containerId, TerminalState terminal);
Some cleanup to network messages - Use enums for key and mouse actions, rather than integer ids. - Change TerminalState to always contain a terminal. We now make TerminalState nullable when we want to skip sending anything.
2024-04-25 17:19:34 +00:00
void handleMonitorData(BlockPos pos, @Nullable TerminalState terminal);
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
void handlePlayRecord(BlockPos pos, @Nullable SoundEvent sound, @Nullable String name);
Some cleanup to network messages - Use enums for key and mouse actions, rather than integer ids. - Change TerminalState to always contain a terminal. We now make TerminalState nullable when we want to skip sending anything.
2024-04-25 17:19:34 +00:00
void handlePocketComputerData(UUID instanceId, ComputerState state, int lightState, @Nullable TerminalState terminal);
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
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
void handlePocketComputerDeleted(UUID instanceId);
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
Send entire DFPWM encoder state to the client This ensures the client decoder is in sync with the server. Well, mostly - we don't handle the anti-jerk, but that should correct itself within a few samples. Fixes #1748
2024-03-15 18:25:57 +00:00
void handleSpeakerAudio(UUID source, SpeakerPosition.Message position, float volume, EncodedAudio audio);
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
void handleSpeakerMove(UUID source, SpeakerPosition.Message position);
void handleSpeakerPlay(UUID source, SpeakerPosition.Message position, ResourceLocation sound, float volume, float pitch);
void handleSpeakerStop(UUID source);
Make the main mod non-null by default This was actually much more work than I thought it would be. Tests pass, but I'm sure there's some regressions in here.
2022-11-09 18:58:31 +00:00
void handleUploadResult(int containerId, UploadResult result, @Nullable Component errorMessage);
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
}