valence/crates/valence_client/src/interact_entity.rs

50 lines
1.6 KiB
Rust
Raw Normal View History

Decoupled Packet Handlers (#315) ## Description Closes #296 - Redesigned the packet decoder to return packet _frames_ which are just the packet ID + data in raw form. - Made packet frame decoding happen in the client's tokio task. This has a few advantages: - Packet frame decoding (decompression + decryption + more) can happen in parallel. - Because packets are parsed as soon as they arrive, an accurate timestamp can be included with the packet. This enables us to implement client ping calculation accurately. - `PacketEvent`s are now sent in the event loop instead of a giant match on the serverbound packets. This is good because: - Packets can now be handled from completely decoupled systems by reading `PacketEvent` events. - The entire packet is available in binary form to users, so we don't need to worry about losing information when transforming packets to events. I.e. an escape hatch is always available. - The separate packet handlers can run in parallel thanks to bevy_ecs. - The inventory packet handler systems have been unified and moved completely to the inventory module. This also fixed some issues where certain inventory events could _only_ be handled one tick late. - Reorganized the client module and moved things into submodules. - The "default event handler" has been removed in favor of making clients a superset of `PlayerEntityBundle`. It is no longer necessary to insert `PlayerEntityBundle` when clients join. This does mean you can't insert other entity types on the client, but that design doesn't work for a variety of reasons. We will need an "entity visibility" system later anyway. ## Test Plan Steps: 1. Run examples and tests.
2023-04-09 05:55:31 +10:00
use bevy_app::prelude::*;
use bevy_ecs::prelude::*;
Reorganize Project (#321) ## Description - `valence` and `valence_protocol` have been divided into smaller crates in order to parallelize the build and improve IDE responsiveness. In the process, code architecture has been made clearer by removing circular dependencies between modules. `valence` is now just a shell around the other crates. - `workspace.packages` and `workspace.dependencies` are now used. This makes dependency managements and crate configuration much easier. - `valence_protocol` is no more. Most things from `valence_protocol` ended up in `valence_core`. We won't advertise `valence_core` as a general-purpose protocol library since it contains too much valence-specific stuff. Closes #308. - Networking code (login, initial TCP connection handling, etc.) has been extracted into the `valence_network` crate. The API has been expanded and improved with better defaults. Player counts and initial connections to the server are now tracked separately. Player counts function by default without any user configuration. - Some crates like `valence_anvil`, `valence_network`, `valence_player_list`, `valence_inventory`, etc. are now optional. They can be enabled/disabled with feature flags and `DefaultPlugins` just like bevy. - Whole-server unit tests have been moved to `valence/src/tests` in order to avoid [cyclic dev-dependencies](https://github.com/rust-lang/cargo/issues/4242). - Tools like `valence_stresser` and `packet_inspector` have been moved to a new `tools` directory. Renamed `valence_stresser` to `stresser`. Closes #241. - Moved all benches to `valence/benches/` to make them easier to run and organize. Ignoring transitive dependencies and `valence_core`, here's what the dependency graph looks like now: ```mermaid graph TD network --> client client --> instance biome --> registry dimension --> registry instance --> biome instance --> dimension instance --> entity player_list --> client inventory --> client anvil --> instance entity --> block ``` ### Issues - Inventory tests inspect many private implementation details of the inventory module, forcing us to mark things as `pub` and `#[doc(hidden)]`. It would be ideal if the tests only looked at observable behavior. - Consider moving packets in `valence_core` elsewhere. `Particle` wants to use `BlockState`, but that's defined in `valence_block`, so we can't use it without causing cycles. - Unsure what exactly should go in `valence::prelude`. - This could use some more tests of course, but I'm holding off on that until I'm confident this is the direction we want to take things. ## TODOs - [x] Update examples. - [x] Update benches. - [x] Update main README. - [x] Add short READMEs to crates. - [x] Test new schedule to ensure behavior is the same. - [x] Update tools. - [x] Copy lints to all crates. - [x] Fix docs, clippy, etc.
2023-04-22 07:43:59 +10:00
use valence_core::packet::c2s::play::player_interact_entity::EntityInteraction;
use valence_core::packet::c2s::play::PlayerInteractEntityC2s;
use valence_entity::EntityManager;
Decoupled Packet Handlers (#315) ## Description Closes #296 - Redesigned the packet decoder to return packet _frames_ which are just the packet ID + data in raw form. - Made packet frame decoding happen in the client's tokio task. This has a few advantages: - Packet frame decoding (decompression + decryption + more) can happen in parallel. - Because packets are parsed as soon as they arrive, an accurate timestamp can be included with the packet. This enables us to implement client ping calculation accurately. - `PacketEvent`s are now sent in the event loop instead of a giant match on the serverbound packets. This is good because: - Packets can now be handled from completely decoupled systems by reading `PacketEvent` events. - The entire packet is available in binary form to users, so we don't need to worry about losing information when transforming packets to events. I.e. an escape hatch is always available. - The separate packet handlers can run in parallel thanks to bevy_ecs. - The inventory packet handler systems have been unified and moved completely to the inventory module. This also fixed some issues where certain inventory events could _only_ be handled one tick late. - Reorganized the client module and moved things into submodules. - The "default event handler" has been removed in favor of making clients a superset of `PlayerEntityBundle`. It is no longer necessary to insert `PlayerEntityBundle` when clients join. This does mean you can't insert other entity types on the client, but that design doesn't work for a variety of reasons. We will need an "entity visibility" system later anyway. ## Test Plan Steps: 1. Run examples and tests.
2023-04-09 05:55:31 +10:00
use crate::event_loop::{EventLoopSchedule, EventLoopSet, PacketEvent};
pub(super) fn build(app: &mut App) {
app.add_event::<InteractEntity>().add_system(
handle_interact_entity
.in_schedule(EventLoopSchedule)
.in_base_set(EventLoopSet::PreUpdate),
);
}
#[derive(Copy, Clone, Debug)]
pub struct InteractEntity {
pub client: Entity,
/// The entity being interacted with.
pub entity: Entity,
/// If the client was sneaking during the interaction.
pub sneaking: bool,
/// The kind of interaction that occurred.
pub interact: EntityInteraction,
}
fn handle_interact_entity(
mut packets: EventReader<PacketEvent>,
entities: Res<EntityManager>,
mut events: EventWriter<InteractEntity>,
) {
for packet in packets.iter() {
if let Some(pkt) = packet.decode::<PlayerInteractEntityC2s>() {
// TODO: check that the entity is in the same instance as the player.
// TODO: check that the distance between the player and the interacted entity is
// within some configurable tolerance level.
if let Some(entity) = entities.get_by_id(pkt.entity_id.0) {
events.send(InteractEntity {
client: packet.client,
entity,
sneaking: pkt.sneaking,
interact: pkt.interact,
})
}
}
}
}