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

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

41 lines
1.4 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: 2021 The CC: Tweaked Developers
//
// SPDX-License-Identifier: MPL-2.0
Rewrite speaker networking code Speakers now play sounds using a custom set of packets. - When playing a sound, we send the resource id, position, volume, pitch and a UUID for the _speaker_ to all nearby clients. - This UUID is then used when we need to update the sound. When the speaker is moved or destroyed, we send a new packet to clients and update accordingly. This does have one side effect, that speakers can now only play one sound at a time. I think this is accceptable - otherwise it's possible to spam ward in a loop. Notes still use the old networking code, and so will not be affected. Closes #823
2021-06-18 21:23:04 +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.speaker.SpeakerBlockEntity;
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 dan200.computercraft.shared.peripheral.speaker.SpeakerPeripheral;
import net.minecraft.core.UUIDUtil;
import net.minecraft.network.RegistryFriendlyByteBuf;
import net.minecraft.network.codec.StreamCodec;
import net.minecraft.network.protocol.common.custom.CustomPacketPayload;
Rewrite speaker networking code Speakers now play sounds using a custom set of packets. - When playing a sound, we send the resource id, position, volume, pitch and a UUID for the _speaker_ to all nearby clients. - This UUID is then used when we need to update the sound. When the speaker is moved or destroyed, we send a new packet to clients and update accordingly. This does have one side effect, that speakers can now only play one sound at a time. I think this is accceptable - otherwise it's possible to spam ward in a loop. Notes still use the old networking code, and so will not be affected. Closes #823
2021-06-18 21:23:04 +00:00
import java.util.UUID;
/**
* Stops a sound on the client
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>
Rewrite speaker networking code Speakers now play sounds using a custom set of packets. - When playing a sound, we send the resource id, position, volume, pitch and a UUID for the _speaker_ to all nearby clients. - This UUID is then used when we need to update the sound. When the speaker is moved or destroyed, we send a new packet to clients and update accordingly. This does have one side effect, that speakers can now only play one sound at a time. I think this is accceptable - otherwise it's possible to spam ward in a loop. Notes still use the old networking code, and so will not be affected. Closes #823
2021-06-18 21:23:04 +00:00
* Called when a speaker is broken.
*
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 source The {@linkplain SpeakerPeripheral#getSource() id} of the speaker playing audio.
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 SpeakerBlockEntity
Rewrite speaker networking code Speakers now play sounds using a custom set of packets. - When playing a sound, we send the resource id, position, volume, pitch and a UUID for the _speaker_ to all nearby clients. - This UUID is then used when we need to update the sound. When the speaker is moved or destroyed, we send a new packet to clients and update accordingly. This does have one side effect, that speakers can now only play one sound at a time. I think this is accceptable - otherwise it's possible to spam ward in a loop. Notes still use the old networking code, and so will not be affected. Closes #823
2021-06-18 21:23:04 +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 SpeakerStopClientMessage(UUID source) implements NetworkMessage<ClientNetworkContext> {
public static final StreamCodec<RegistryFriendlyByteBuf, SpeakerStopClientMessage> STREAM_CODEC = UUIDUtil.STREAM_CODEC
.map(SpeakerStopClientMessage::new, SpeakerStopClientMessage::source)
.cast();
Rewrite speaker networking code Speakers now play sounds using a custom set of packets. - When playing a sound, we send the resource id, position, volume, pitch and a UUID for the _speaker_ to all nearby clients. - This UUID is then used when we need to update the sound. When the speaker is moved or destroyed, we send a new packet to clients and update accordingly. This does have one side effect, that speakers can now only play one sound at a time. I think this is accceptable - otherwise it's possible to spam ward in a loop. Notes still use the old networking code, and so will not be affected. Closes #823
2021-06-18 21:23:04 +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) {
context.handleSpeakerStop(source);
Rewrite speaker networking code Speakers now play sounds using a custom set of packets. - When playing a sound, we send the resource id, position, volume, pitch and a UUID for the _speaker_ to all nearby clients. - This UUID is then used when we need to update the sound. When the speaker is moved or destroyed, we send a new packet to clients and update accordingly. This does have one side effect, that speakers can now only play one sound at a time. I think this is accceptable - otherwise it's possible to spam ward in a loop. Notes still use the old networking code, and so will not be affected. Closes #823
2021-06-18 21:23:04 +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<SpeakerStopClientMessage> 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.SPEAKER_STOP;
}
Rewrite speaker networking code Speakers now play sounds using a custom set of packets. - When playing a sound, we send the resource id, position, volume, pitch and a UUID for the _speaker_ to all nearby clients. - This UUID is then used when we need to update the sound. When the speaker is moved or destroyed, we send a new packet to clients and update accordingly. This does have one side effect, that speakers can now only play one sound at a time. I think this is accceptable - otherwise it's possible to spam ward in a loop. Notes still use the old networking code, and so will not be affected. Closes #823
2021-06-18 21:23:04 +00:00
}