Module minetest_protocol::wire::types
source · Expand description
Minetest data types used inside of Commands / Packets.
Derive macros MinetestSerialize and MinetestDeserialize are used to produce ser/deser methods for many of the structs below. The order of the fields inside the struct determines the order in which they are serialized/deserialized, so be careful modifying anything below. Their serialized representation must stay the same.
NOTE: The derive macros currently do not work on structs with generic parameters.
TODO(paradust): Having an assert!-like macro that generates Serialize/Deserialize errors instead of aborts may be helpful for cleaning this up.
Structs
- This is the way ADD_PARTICLESPAWNER is serialized. It seems to be an older version of ParticleParameters
- An array of items with no specified length. The length is determined by buffer end.
- An array of items with a u8 length prefix
- An array of items with a u16 length prefix
- An array of items with a u32 length prefix
- Binary data preceded by a U16 size
- Binary data preceded by a U32 size
- BlockPos addresses a node within a block It is equivalent to (16*z + y)*16 + x, where x,y,z are from 0 to 15.
- Rust String’s must be valid UTF8. But Minetest’s strings can contain arbitrary binary data. The only way to store arbitrary bytes is with something like Vec
, which is not String-like. This provides a String-like alternative, that looks nice in debug output. - This corresponds to GenericCAO::Initialize in minetest
- The default serialization is used for single nodes. But for transferring entire blocks, MapNodeBulk is used instead.
- This has a special serialization, presumably to make it compress better. Each param is stored in a separate array.
- This is the send format used by SendSpawnParticle See ParticleParameters::serialize
- Corresponds to std::wstring in C++ land
Enums
- This is serialized as part of a combined ‘flags’ field on ServerParticleTexture, so it doesn’t implement the methods on its own.