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>
* Replace HashMap with BTreeMap in valence_nbt
Turns out that `BTreeMap`s are a bit faster when the element count is low.
This change also makes debugging compounds a bit easier since the elements are displayed in sorted order.
* Simplify read_list function slightly
This adds the `prevent-proxy-connections` server property and implements it into valence.
Note that if the server is in offline mode, this changes nothing.
By default, proxy connections are allowed.
Fixes#95
* Add basic enchantment extraction
* Change source format to individual fields rather than a list
Co-authored-by: Terminator <terminator@nonexistent.com>
