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

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

54 lines
2.1 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: 2018 The CC: Tweaked Developers
//
// SPDX-License-Identifier: MPL-2.0
Move from FMLEventChannel to SimpleNetworkWrapper - Split each network packet into it's own individual IMessage class. - Move the TextTable into separate classes for server and client based rendering.
2018-12-29 12:18:05 +00:00
package dan200.computercraft.shared.network.client;
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;
Split CC:T into common and forge projects After several weeks of carefully arranging ribbons, we pull the string and end up with, ... a bit of a messy bow. There were still some things I'd missed. - Split the mod into a common (vanilla-only) project and Forge-specific project. This gives us room to add Fabric support later on. - Split the project into main/client source sets. This is not currently statically checked: we'll do that soon. - Rename block/item/tile entities to use suffixes rather than prefixes.
2022-11-09 23:58:56 +00:00
import dan200.computercraft.shared.peripheral.diskdrive.DiskDriveBlockEntity;
Update to Minecraft 1.17.1 - Remap everything to use MojMap class names too. This is what Forge uses, so \o/. This does NOT currently rename any classes to use suffix notation or BlockEntity. That will come in a later change. We do however rename references of "World" to "Level". - Move the test mod into a separate "cctest" source set. As Forge now works using Jigsaw we cannot have multiple mods defining the same package, which causes problems with our JUnit test classes. - Remove our custom test framework and replace it with vanilla's (this is no longer stripped from the jar). RIP kotlin coroutines. It's still worth using Kotlin here though, just for extension methods. - Other 1.17-related changes: - Use separate tile/block entity tick methods for server and client side, often avoiding ticking at all on the client. - Switch much of the monitor rendering code to use vanilla's built-in shader system. It's still an incredibly ugly hack, so not really expecting this to work with any rendering mods, but we'll cross that bridge when we come to it.
2021-08-03 20:46:53 +00:00
import net.minecraft.core.BlockPos;
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
import net.minecraft.core.Holder;
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;
Update to Minecraft 1.17.1 - Remap everything to use MojMap class names too. This is what Forge uses, so \o/. This does NOT currently rename any classes to use suffix notation or BlockEntity. That will come in a later change. We do however rename references of "World" to "Level". - Move the test mod into a separate "cctest" source set. As Forge now works using Jigsaw we cannot have multiple mods defining the same package, which causes problems with our JUnit test classes. - Remove our custom test framework and replace it with vanilla's (this is no longer stripped from the jar). RIP kotlin coroutines. It's still worth using Kotlin here though, just for extension methods. - Other 1.17-related changes: - Use separate tile/block entity tick methods for server and client side, often avoiding ticking at all on the client. - Switch much of the monitor rendering code to use vanilla's built-in shader system. It's still an incredibly ugly hack, so not really expecting this to work with any rendering mods, but we'll cross that bridge when we come to it.
2021-08-03 20:46:53 +00:00
import net.minecraft.sounds.SoundEvent;
Move from FMLEventChannel to SimpleNetworkWrapper - Split each network packet into it's own individual IMessage class. - Move the TextTable into separate classes for server and client based rendering.
2018-12-29 12:18:05 +00:00
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
import java.util.Optional;
Move from FMLEventChannel to SimpleNetworkWrapper - Split each network packet into it's own individual IMessage class. - Move the TextTable into separate classes for server and client based rendering.
2018-12-29 12:18:05 +00:00
/**
Turn inspections up to 11 OK, so let's get this out of the way, there's some actual changes mixed in here too. I'm really sorry: - Turtles can now not be renamed with unnamed item tags (previously it would clear the name, this seemed a little unideal). - commands.getBlock(s)Data will also include NBT. Now, onto the horror story which is these inspection changes: - Make a lot of methods static - Typo fixes - Make utility classes final + private constructor - Lots of reformatting (ifs -> ternary, invert control flow, etc...) - ??? - Profit! I'm so going to regret this - can pretty much guarantee this is going to break something.
2019-03-29 21:21:39 +00:00
* Starts or stops a record on the client, depending on if {@link #soundEvent} is {@code null}.
Some improvements to Javadoc publishing - Use <p> everywhere. This is uglier, but also technically more correct. This requires a version bump to cct-javadoc, and will give me a massive headache when merging. - Link against the existing OpenJDK docs.
2022-10-25 18:17:55 +00:00
* <p>
Move from FMLEventChannel to SimpleNetworkWrapper - Split each network packet into it's own individual IMessage class. - Move the TextTable into separate classes for server and client based rendering.
2018-12-29 12:18:05 +00:00
* Used by disk drives to play record items.
*
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
* @param pos The position of the speaker, where we should play this sound.
* @param soundEvent The sound to play, or {@link Optional#empty()} if we should stop playing.
* @param name The title of the audio to play.
Split CC:T into common and forge projects After several weeks of carefully arranging ribbons, we pull the string and end up with, ... a bit of a messy bow. There were still some things I'd missed. - Split the mod into a common (vanilla-only) project and Forge-specific project. This gives us room to add Fabric support later on. - Split the project into main/client source sets. This is not currently statically checked: we'll do that soon. - Rename block/item/tile entities to use suffixes rather than prefixes.
2022-11-09 23:58:56 +00:00
* @see DiskDriveBlockEntity
Move from FMLEventChannel to SimpleNetworkWrapper - Split each network packet into it's own individual IMessage class. - Move the TextTable into separate classes for server and client based rendering.
2018-12-29 12:18:05 +00:00
*/
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
public record PlayRecordClientMessage(
BlockPos pos, Optional<Holder<SoundEvent>> soundEvent, Optional<String> name
) implements NetworkMessage<ClientNetworkContext> {
public static final StreamCodec<RegistryFriendlyByteBuf, PlayRecordClientMessage> STREAM_CODEC = StreamCodec.composite(
BlockPos.STREAM_CODEC, PlayRecordClientMessage::pos,
ByteBufCodecs.optional(SoundEvent.STREAM_CODEC), PlayRecordClientMessage::soundEvent,
ByteBufCodecs.optional(ByteBufCodecs.STRING_UTF8), PlayRecordClientMessage::name,
PlayRecordClientMessage::new
);
Move from FMLEventChannel to SimpleNetworkWrapper - Split each network packet into it's own individual IMessage class. - Move the TextTable into separate classes for server and client based rendering.
2018-12-29 12:18:05 +00:00
public PlayRecordClientMessage(BlockPos pos) {
Update to 1.20.5 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
this(pos, Optional.empty(), Optional.empty());
Move from FMLEventChannel to SimpleNetworkWrapper - Split each network packet into it's own individual IMessage class. - Move the TextTable into separate classes for server and client based rendering.
2018-12-29 12:18:05 +00:00
}
Move our message model to be closer to Forge's It's rather embarassing that it's been restructured _again_, but I think this is a nice middle-ground. The previous implementation was written mostly for Fabric, which doesn't always map perfectly to Forge. - Move the message identifier into the registration phrase. It's not really a property of the message itself, rather a property of the registry, so better suited there. - Move message handling into the message itself. Honestly, it was just ending up being rather messy mixing the logic in two places. This also means we can drop some proxy methods, as it's easier to have conditionally loaded methods. - Move network registry into a dedicated class, as that's what we're doing for everything else.
2019-01-12 19:42:34 +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 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
context.handlePlayRecord(pos, soundEvent.map(Holder::value).orElse(null), name.orElse(null));
Move our message model to be closer to Forge's It's rather embarassing that it's been restructured _again_, but I think this is a nice middle-ground. The previous implementation was written mostly for Fabric, which doesn't always map perfectly to Forge. - Move the message identifier into the registration phrase. It's not really a property of the message itself, rather a property of the registry, so better suited there. - Move message handling into the message itself. Honestly, it was just ending up being rather messy mixing the logic in two places. This also means we can drop some proxy methods, as it's easier to have conditionally loaded methods. - Move network registry into a dedicated class, as that's what we're doing for everything else.
2019-01-12 19:42:34 +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 (#1793) - Switch most network code to use StreamCodec - Turtle/pocket computer upgrades now use DataComponentPatch instead of raw NBT.
2024-04-25 20:32:48 +00:00
public CustomPacketPayload.Type<PlayRecordClientMessage> 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.PLAY_RECORD;
}
Move from FMLEventChannel to SimpleNetworkWrapper - Split each network packet into it's own individual IMessage class. - Move the TextTable into separate classes for server and client based rendering.
2018-12-29 12:18:05 +00:00
}