This is a starting point for the valence_anvil crate.

It currently supports loading blocks and biomes.

Note on negative Y values: Since UnloadedChunk does not support negative Y values, all parsed Y values are raised to Y=0.

Before merging, make sure the changes from https://github.com/valence-rs/valence/commit/03e89adeb8fc286ef24b1e21f5c78908276fef18 are uploaded to crates.io and the version number is set in Cargo.toml

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.

Open to feedback, right now the implementation is just a copy of the way the blocks are done.

I'm thinking of adding a Vec<Prop> to store props in an enum, such as the hunger the item will restore, attack damage and mining level? and mabye other things, idk?

PR to add particles in a new particles module

• [x] All the particles except Item particle
• [x] Item particle
• [x] Particle example
• [x] Encode trait
• [x] Decode trait
• [ ] Tests (Encode -> Decode round trip)

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.

• automatically handle CloseContainer packet so the client updates open_inventory
• ~~remove InventoryId::NULL in favor of Option<InventoryId>~~
• Use Option<InventoryId> for open_inventory on client

I believe that doing stuff like InventoryId::NULL is an anti pattern, and better facilitated by using Option instead

Using commit cac348a4b6e788f3ecce24c7559c1789f4c8b402, running example combat.

Server log

[2022-09-05T13:03:17Z TRACE valence::server] entering accept loop
[2022-09-05T13:04:22Z ERROR valence::server] connection to 127.0.0.1:64121 ended: error during play: packet contents were not read completely

How to reproduce

• Join the server
• Type a message
• Get disconnected

This bug occurs in all examples and non-examples.

This PR implements dying and respawning of player and death.rs example.

Unresolved

• [ ] DeathMessage packet has no effect when sent on the tick client was created.
• [ ] Investigate NoRespawnBlockAvailable message in GameStateChange packet.
• [ ] Investigate PlayerRespawn's field copy_metadata.
• [ ] Interaction with compass. I think we should solve this in another PR (after implementing Inventory packet etc.).

Additions

Client::kill method

Method for killing the client. Allows to set a message on the death screen.

Death.rs example

To demonstrate (and to follow up on this comment) I also created an example.

It shows how to enable death screen, kill player and respawn, including respawning in another world. Once player inventory is working, interaction with compass would be added to the example.

Tests

Following tests were conducted in the death.rs example.

• Behavior with and without death screen enabled
  • When Death screen is enabled, it will appear. Respawn button is clickable and works.
  • When Death screen is disabled, respawn is immediate.
  • In both instances, ClientStatus packet will be sent.
• GameJoin.enable_respawn_screen packet field
  • When set to true enables death screen exactly as GameStateChange packet with EnableRespawnScreen option.
• DeathMessage packet sent on the first tick a client joined
  • Has no effect on the client.
• Respawn after receiving GameStateChange with WinGame reason
  • Works with both rolling the credits and immediate respawn options.

This PR adds Proxy Support.

TODO

• [x] Velocity Support
• [x] Bungeecord Support
• [x] Add Plugin Message API (Client Event)
• [x] VELOCITY_MODERN_FORWARDING_WITH_KEY_V2

Closes #39

[edit] This PR implements ExperienceBarUpdate and HealthUpdate packets.

I decided not to introduce a new field for Total Experience, health or hunger on Client, storing that data and conversion between Total Experience and level with xp bar would be handled downstream.

There are two new functions on Client, set_level and set_health_and_food. Their docs describe ranges of the arguments. It is ok to send these packets on the same tick player connected, that is why I chose not to defer sending them.

Setting total_xp has no effect on the score on death screen, so I have no idea what it does. There is a todo in set_level docs.

Tests

HealthUpdate

• Send packet on the same tick player connected
  • Outcome: packet can be sent on the same tick player connected (right after GameJoin packet)
• Send packet to player in creative mode
  • Outcome: works as expected, after changing gamemode back to survival, health bar was changed
• Send packet with health <= 0
  • Outcome: player dies. (Player is stuck now because respawn button does not work).
• Send packet with food <= 0, or food_saturation <= 0
  • Outcome: client does not crash, we can test and document this later when eating works.

ExperienceBarUpdate

• Send packet on the same tick player connected
  • Outcome: packet can be sent on the same tick player connected (right after GameJoin packet)
• Send packet to player in creative mode
  • Outcome: works as expected, after changing gamemode back to survival, xp bar was changed
• Send packet with negative total_xp
  • Outcome: client did not crash

Docs

• Documentation for the new helpers set_level and set_health_and_food rendered correctly.

Old:

Packets were tested manually.

API-wise, should these packets have a method on Client? If so, I will append this PR.

Also, it seems Set Experience allows to set fields inconsistently (for example as Total Experience = 0 and Level = 5). I couldn't find, if that could cause issues.

Generates a new translation_key.rs with all bundled translations. Closes #158.

Decided to split the translation keys into tree files, as the generated code spans over 30K lines. The files are translation_key_consts.rs, translation_key_enum.rs and translation_key_enum_display.rs.

Here's an example on how to use it:

use valence_protocol::translation_key::TranslationKey;

// with enum
Text::translate(TranslationKey::NarratorJoining, [])

// with constant
Text::translate(TranslationKey::Custom(NARRATOR_JOINING), [])

// feeling adventurous
Text::translate(TranslationKey::Custom("custom.translation_key".to_string()), [])

Can be reproduced with the combat example:

1. Connect two clients to the combat example
2. Disconnect one of them

thread '<unnamed>' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime', /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.2/src/runtime/context.rs:56:13
stack backtrace:
   0: rust_begin_unwind
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/core/src/panicking.rs:65:14
   2: core::panicking::panic_display
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/core/src/panicking.rs:139:5
   3: core::panicking::panic_str
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/core/src/panicking.rs:123:5
   4: core::option::expect_failed
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/core/src/option.rs:1876:5
   5: core::option::Option<T>::expect
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.2/src/runtime/context.rs:56:13
   6: tokio::runtime::context::time_handle::{{closure}}
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.2/src/runtime/context.rs:56:13
   7: std::thread::local::LocalKey<T>::try_with
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/std/src/thread/local.rs:446:16
   8: tokio::runtime::context::time_handle
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.2/src/runtime/context.rs:54:15
   9: tokio::time::driver::handle::Handle::current
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.2/src/time/driver/handle.rs:58:13
  10: tokio::time::driver::sleep::Sleep::new_timeout
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.2/src/time/driver/sleep.rs:260:22
  11: tokio::time::timeout::timeout
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.21.2/src/time/timeout.rs:79:27
  12: <valence::server::packet_controller::PlayPacketController as core::ops::drop::Drop>::drop
             at /home/jivvy/.cargo/git/checkouts/valence-a175964027d82956/43435b8/src/server/packet_controller.rs:218:30
  13: core::ptr::drop_in_place<valence::server::packet_controller::PlayPacketController>
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/core/src/ptr/mod.rs:491:1
  14: valence::client::Client<C>::handle_serverbound_packets
             at /home/jivvy/.cargo/git/checkouts/valence-a175964027d82956/43435b8/src/client.rs:911:9
  15: valence::server::do_update_loop::{{closure}}
             at /home/jivvy/.cargo/git/checkouts/valence-a175964027d82956/43435b8/src/server.rs:407:13
  16: <rayon::iter::for_each::ForEachConsumer<F> as rayon::iter::plumbing::Folder<T>>::consume
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.5.3/src/iter/for_each.rs:47:9
  17: <rayon::iter::map::MapFolder<C,F> as rayon::iter::plumbing::Folder<T>>::consume
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.5.3/src/iter/map.rs:239:19
  18: <rayon::iter::map::MapFolder<C,F> as rayon::iter::plumbing::Folder<T>>::consume
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.5.3/src/iter/map.rs:239:19
  19: <rayon::iter::filter_map::FilterMapFolder<C,P> as rayon::iter::plumbing::Folder<T>>::consume
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.5.3/src/iter/filter_map.rs:124:24
  20: rayon::iter::plumbing::Folder::consume_iter
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.5.3/src/iter/plumbing/mod.rs:179:20
  21: rayon::iter::plumbing::Producer::fold_with
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.5.3/src/iter/plumbing/mod.rs:110:9
  22: rayon::iter::plumbing::bridge_producer_consumer::helper
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.5.3/src/iter/plumbing/mod.rs:438:13
  23: rayon::iter::plumbing::bridge_producer_consumer::helper::{{closure}}
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.5.3/src/iter/plumbing/mod.rs:418:21
  24: rayon_core::join::join_context::call_a::{{closure}}
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/join/mod.rs:124:17
  25: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/core/src/panic/unwind_safe.rs:271:9
  26: std::panicking::try::do_call
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/std/src/panicking.rs:483:40
  27: std::panicking::try
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/std/src/panicking.rs:447:19
  28: std::panic::catch_unwind
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/std/src/panic.rs:137:14
  29: rayon_core::unwind::halt_unwinding
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/unwind.rs:17:5
  30: rayon_core::join::join_context::{{closure}}
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/join/mod.rs:141:24
  31: rayon_core::registry::Registry::in_worker_cold::{{closure}}::{{closure}}
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/registry.rs:468:21
  32: <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute::call::{{closure}}
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/job.rs:113:21
  33: <core::panic::unwind_safe::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/core/src/panic/unwind_safe.rs:271:9
  34: std::panicking::try::do_call
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/std/src/panicking.rs:483:40
  35: std::panicking::try
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/std/src/panicking.rs:447:19
  36: std::panic::catch_unwind
             at /rustc/bf15a9e5263fcea065a7ae9c179b2d24c2deb670/library/std/src/panic.rs:137:14
  37: rayon_core::unwind::halt_unwinding
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/unwind.rs:17:5
  38: <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/job.rs:119:38
  39: rayon_core::job::JobRef::execute
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/registry.rs:729:17
  40: rayon_core::registry::WorkerThread::execute
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/registry.rs:752:9
  41: rayon_core::registry::WorkerThread::wait_until_cold
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/registry.rs:729:17
  42: rayon_core::registry::WorkerThread::wait_until
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/registry.rs:703:13
  43: rayon_core::registry::main_loop
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/registry.rs:836:5
  44: rayon_core::registry::ThreadBuilder::run
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/registry.rs:55:18
  45: <rayon_core::registry::DefaultSpawn as rayon_core::registry::ThreadSpawn>::spawn::{{closure}}
             at /home/jivvy/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.9.3/src/registry.rs:100:20
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

It would be wonderful if it were possible to access every value in the game profile provided by Mojang/Velocity, so that custom values can be passed to the sub-server without the need for an external messenger.

• add GENERAL_SLOTS, HOTBAR_SLOTS, and OFFHAND_SLOT constants
• update the chest example so it compiles and runs
• add PLAYER_INVENTORY_SLOTS constant
• set dirty bit when replace_cursor_item is called
• update the default packet handler for ClickContainer to not crash when the player changes an open inventory

Test plan

1. run chest example - cargo r -r --example chest
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

This example generates terrain similar to the SkyGrid map by SethBling: https://www.planetminecraft.com/project/skygrid-survival-map/ .

BLOCK_TYPES: [BlockState, 547] is intended to be an array of all BlockStates listed as opaque in out/blocks.rs.

(Much of skygrid.rs is copied from terrain.rs.)

World Border

This PR implements packets and methods to do with world borders. World border is a wall defined by center point and diameter. It restricts client from going outside the border.

Implemented packets

• InitializeWorldBorder (this one was defined as WorldBorderInitialize, but unused)
• SetBorderCenter
• SetBorderLerpSize
• SetBorderSize
• SetBorderWarningDelay
• SetBorderWarningDistance

TODOs

I do not yet understand the behavior of portal_teleport_boundary field on InitializeWorldBorder. It seems to affect the shape of the border, sometimes making it rectangular instead of square, or making it disappear entirely.

I could not replicate the appearance of the warning screen when getting close to the border.

Discussion

Take this as a draft of the API. I considered two options, basic methods on Client for basic usecases (current state of PR) and copying packet API to the Client API. Is it acceptable to allow unusual usecases with manual send_packet only?

Fixes #115 Make it so blocks are place right e.g torches stay on walls and keep their rotation, logs keep their axis and banners their rotation when updated.