Closes#82Closes#43Closes#64
# Changes and Improvements
- Packet encoding/decoding happens within `Client` instead of being sent
over a channel first. This is better for performance and lays the
groundwork for #83.
- Reduce the amount of copying necessary by leveraging the `bytes` crate
and recent changes to `EncodePacket`. Performance is noticeably improved
with maximum players in the `rust-mc-bot` test going from 750 to 1050.
- Packet encoding/decoding code is decoupled from IO. This is easier to
understand and more suitable for a future protocol lib.
- Precise control over the number of bytes that are buffered for
sending/receiving. This is important for limiting maximum memory usage
correctly.
- "packet controllers" are introduced, which are convenient structures
for managing packet IO before and during the play state.
- `byte_channel` module is created to help implement the
`PlayPacketController`. This is essentially a channel of bytes
implemented with an `Arc<Mutex<BytesMut>>`.
- Error handling in the update procedure for clients was improved using
`anyhow::Result<()>` to exit as early as possible. The `client` module
is a bit cleaner as a result.
- The `LoginPlay` packet is always sent before all other play packets.
We no longer have to worry about the behavior of packets sent before
that packet. Most packet deferring performed currently can be
eliminated.
- The packet_inspector was rewritten in response to the above changes.
- Timeouts on IO operations behave better.
# Known Issues
- The packet_inspector now re-encodes packets rather than just decoding
them. This will cause problems when trying to use it with the vanilla
server because there are missing clientbound packets and other issues.
This will be fixed when the protocol module is moved to a separate
crate.
There are a number of places where usernames are passed around. Using this type ensures that the contained string is actually a valid username and not some other kind of string. For instance you can use it as a function argument to indicate that only valid usernames are accepted, or return it from a function to indicate that only valid usernames are produced.
This is analogous to the existing `Ident<S>` type.
Closes#114
Note that this is a band-aid solution to a more general problem. In the
future, there should be a function in the `block` module to handle all
these placement rules.
This allows packets to calculate their exact length up front.
This isn't currently tested or being used for anything, but that will come in later changes.
This is a very rough version of the inventory module and associated features. This will be a good base to start building something more robust.
- adds a player inventory to all clients
- makes clients keep track of what inventory they have open
- adds very naive state sync for inventories
related: #53
# Test plans
### Building
1. run `building` example
2. pick any block from creative
3. place it
4. pick a different block from creative
5. place 2
6. break the last one
7. see that both remaining blocks don't become dirt
### Chest inventories
1. run `chest` example
2. sneak to give yourself a stone block
3. open the chest (it's invisible on top of the stone block)
4. place stone in chest
5. see the stone moving around in the chest
## Known Issues
To be fixed in later PRs
- It's very easy to duplicate items if you take the stone out of the chest on the same tick as the server trying to move the item.
- The chest is invisible when you spawn in. It appears if you break it.
- `get_slot` and `set_slot` can panic.
Adds the performance_tests/ directory.
In the future we could use our own fake client software instead of
rust-mc-bot. This would make it easier to run the tests.
* `RespawnRequest` client event
* `CombatDeath` packet
* `kill` client method
* `death.rs` example
* clippy lint fix
* Clean up examples
* Fix formatting
* `win_game`, `set_respawn_screen` client methods
* respawn screen no longer deferred
This means that death example does not have respawn screen now.
Co-authored-by: Ryan <ryanj00a@gmail.com>
The current approach to managing chunk data is misconceived. This new approach uses genuine paletted containers and does not suffer from complexities caused by caching. As a result, memory usage (according to htop) in the terrain example with render distance = 32 has gone from 785 megs to 137 megs. That's 17.4% of the memory it used to use. Terrain generation speed was not affected.
Adding all the items, just like the blocks are. This will adress 1. and 2. bullet from issue #53
This will also make it easier to convert between block <-> item.
* Expose extracted enchantments to Rust.
* Give enchantments a `level: i16` field.
* Update enchantment derive impls
* Restructure how enchants are exposed to Rust through C-like enums
* Update build/enchant.rs
Co-authored-by: Ryan Johnson <ryanj00a@gmail.com>
* Update build/enchant.rs
Co-authored-by: Ryan Johnson <ryanj00a@gmail.com>
* Move enchantment sources to their own struct.
* make id() function return it's discriminant instead of matching
Co-authored-by: Ryan Johnson <ryanj00a@gmail.com>
