Skip to content

Releases

v0.4.6

Choose a tag to compare

@github-actions github-actions released this 30 Oct 18:39

Full Changelog: v0.4.5...v0.4.6

v0.4.5

Choose a tag to compare

@github-actions github-actions released this 30 Oct 15:33

Full Changelog: v0.4.4...v0.4.5

v0.4.4

Choose a tag to compare

@github-actions github-actions released this 25 Oct 17:07

Full Changelog: v0.4.3...v0.4.4

v0.4.3

Choose a tag to compare

@github-actions github-actions released this 19 Oct 21:13

Full Changelog: v0.4.2...v0.4.3

v0.4.2

Choose a tag to compare

@github-actions github-actions released this 18 Oct 18:07

Full Changelog: v0.4.1...v0.4.2

v0.4.1

Choose a tag to compare

@github-actions github-actions released this 18 Oct 16:47

Full Changelog: v0.4.0...v0.4.1

v0.4.0

Choose a tag to compare

@github-actions github-actions released this 16 Oct 14:06

Full Changelog: v0.3.0...v0.4.0

v0.3.0

Choose a tag to compare

@github-actions github-actions released this 15 Sep 19:10

Full Changelog: v0.2.0...v0.3.0

v0.1.0

Choose a tag to compare

@wu-vincent wu-vincent released this 09 Sep 12:16

Version-aware C++ packet codecs for the Minecraft: Bedrock protocol, generated from a Python schema.

Bedrock's wire format moves between protocol versions: fields appear, packets get reordered, and whole packets migrate to BDS's Cereal serialization. This first release holds one schema covering thirteen network versions and a protoc-shaped compiler (bpc) that turns it into C++ types and serializers — one shape per version, so a consumer names the version it wants and gets a compile error if it asks for a field that era never had.

Coverage

All 235 packets of the Bedrock protocol, across:

protocol game version protocol game version
818 1.21.90 975 1.26.20
819 1.21.93 1001 1.26.30
827 1.21.100 2168 1.26.40
844 1.21.111 2192 1.26.50.27
859 1.21.120 2208 1.26.60.23
898 1.21.132
924 1.26.3
944 1.26.14

Wire shapes come from protocol-docs, names and C++ types from reverse-engineered BDS headers, and golden bytes from gophertunnel.

Using it

As a subproject — code generation runs during the build, so this needs uv on the consumer's machine:

add_subdirectory(bedrock-protocol)
target_link_libraries(my_target PRIVATE bedrock::protocol)

Or take a prebuilt install tree from the assets below and consume it with no Python at all:

find_package(bedrock-protocol CONFIG REQUIRED)
target_link_libraries(my_target PRIVATE bedrock::protocol)

Assets

asset
…-linux-x86_64-gcc13 install tree, GCC 13 / libstdc++
…-linux-x86_64-clang18-libcxx install tree, Clang 18 / libc++
…-windows-x86_64-msvc2022 install tree, MSVC 2022
…-src the emitted C++ next to the hand-written runtime — builds with CMake alone, no uv and no bpc

A static library carries its standard library's ABI, so the triple in the name is part of the contract: the libstdc++ build and the libc++ build are not interchangeable. Building from source or from the -src package avoids the question.

Requirements

CMake and a C++23 compiler. Building the schema from the DSL also needs uv; building from the -src package does not.

Verified

  • 988 tests over the generated codecs, round-tripping against goldens generated by running gophertunnel
  • 124 tests over the compiler itself
  • GCC 13 (libstdc++), Clang 18 (libc++) and MSVC 2022
  • the install tree resolved through find_package and linked from a standalone project, and the source package built with uv removed from PATH