2023-03-15 21:52:13 +00:00
|
|
|
// SPDX-FileCopyrightText: 2021 The CC: Tweaked Developers
|
|
|
|
//
|
|
|
|
// SPDX-License-Identifier: MPL-2.0
|
|
|
|
|
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;
|
2022-11-09 23:58:56 +00:00
|
|
|
import dan200.computercraft.shared.peripheral.speaker.SpeakerBlockEntity;
|
2024-04-25 19:17:43 +00:00
|
|
|
import dan200.computercraft.shared.peripheral.speaker.SpeakerPeripheral;
|
2022-04-28 18:54:28 +00:00
|
|
|
import dan200.computercraft.shared.peripheral.speaker.SpeakerPosition;
|
2024-04-25 19:17:43 +00:00
|
|
|
import net.minecraft.core.UUIDUtil;
|
|
|
|
import net.minecraft.network.RegistryFriendlyByteBuf;
|
|
|
|
import net.minecraft.network.codec.StreamCodec;
|
|
|
|
import net.minecraft.network.protocol.common.custom.CustomPacketPayload;
|
2021-06-18 21:23:04 +00:00
|
|
|
|
|
|
|
import java.util.UUID;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Starts a sound on the client.
|
2022-10-25 18:17:55 +00:00
|
|
|
* <p>
|
2021-06-18 21:23:04 +00:00
|
|
|
* Used by speakers to play sounds.
|
|
|
|
*
|
2024-04-25 19:17:43 +00:00
|
|
|
* @param source The {@linkplain SpeakerPeripheral#getSource() id} of the speaker playing audio.
|
|
|
|
* @param pos The new position of the speaker.
|
2022-11-09 23:58:56 +00:00
|
|
|
* @see SpeakerBlockEntity
|
2021-06-18 21:23:04 +00:00
|
|
|
*/
|
2024-04-25 19:17:43 +00:00
|
|
|
public record SpeakerMoveClientMessage(
|
|
|
|
UUID source, SpeakerPosition.Message pos
|
|
|
|
) implements NetworkMessage<ClientNetworkContext> {
|
|
|
|
public static final StreamCodec<RegistryFriendlyByteBuf, SpeakerMoveClientMessage> STREAM_CODEC = StreamCodec.composite(
|
|
|
|
UUIDUtil.STREAM_CODEC, SpeakerMoveClientMessage::source,
|
|
|
|
SpeakerPosition.Message.STREAM_CODEC, SpeakerMoveClientMessage::pos,
|
|
|
|
SpeakerMoveClientMessage::new
|
|
|
|
);
|
2021-06-18 21:23:04 +00:00
|
|
|
|
2022-04-28 18:54:28 +00:00
|
|
|
public SpeakerMoveClientMessage(UUID source, SpeakerPosition pos) {
|
2024-04-25 19:17:43 +00:00
|
|
|
this(source, pos.asMessage());
|
2021-06-18 21:23:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
2022-11-06 20:12:32 +00:00
|
|
|
public void handle(ClientNetworkContext context) {
|
|
|
|
context.handleSpeakerMove(source, pos);
|
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
|
2024-04-25 19:17:43 +00:00
|
|
|
public CustomPacketPayload.Type<SpeakerMoveClientMessage> 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_MOVE;
|
|
|
|
}
|
2021-06-18 21:23:04 +00:00
|
|
|
}
|