Skip to content

Add protocol data for Minecraft 26.1.2 (protocol 775)#1184

Open
Siigari wants to merge 2 commits into
PrismarineJS:masterfrom
Siigari:add-26.1.2-protocol
Open

Add protocol data for Minecraft 26.1.2 (protocol 775)#1184
Siigari wants to merge 2 commits into
PrismarineJS:masterfrom
Siigari:add-26.1.2-protocol

Conversation

@Siigari
Copy link
Copy Markdown

@Siigari Siigari commented May 10, 2026

Summary

  • Adds packet ID mappings for Minecraft Java Edition 26.1.2 (protocol version 775)
  • Packet IDs extracted from the official server jar using java -DbundlerMainClass=net.minecraft.data.Main -jar server-26.1.2.jar --reports
  • Protocol definitions adapted from 1.21.4 with packet name remapping to match 26.x naming scheme (~150 renamed packets across all phases)

What changed between 1.21.x and 26.1.2

Mojang renamed most packets in the 26.x versioning transition:

  • teleport_confirm -> accept_teleportation
  • spawn_entity -> add_entity
  • block_change -> block_update
  • chat_message -> chat
  • settings -> client_information
  • ...and ~145 more

All packet IDs shifted due to new packets being inserted. This data maps the new IDs to the new names with protocol definitions carried forward from 1.21.4.

Verification

A mineflayer bot successfully:

  • Connects to a 26.1.2 server (offline mode)
  • Completes login handshake
  • Completes configuration phase
  • Enters play state
  • Persists (no timeout)
  • Sends chat commands

Extraction method

The --reports flag on the official server jar dumps all packet name-to-protocol_id mappings. This method can be automated for future versions, eliminating the manual mapping work that has historically blocked version support updates.

Notes

  • Some packet field structures have changed between 1.21.4 and 26.1.2. The protocol definitions carry forward 1.21.4 field layouts, which works for connection/persistence but may cause parse errors on individual packets with changed fields (e.g., recipe_book_add, spawn_position).
  • A follow-up PR with corrected field structures (extracted from decompiled source) would complete full gameplay support.

Siigari added 2 commits May 9, 2026 23:44
Packet ID mappings extracted from the official 26.1.2 server jar using
the --reports flag. Protocol definitions adapted from 1.21.4 with
packet name remapping to match the new naming scheme introduced in 26.x.

Verified: mineflayer bot successfully connects, persists, and sends
chat commands to a 26.1.2 server using this data.

Includes:
- protocol.json: full packet definitions for all phases
- version.json: version 775, release type
- dataPaths.json: version entry pointing to new data

Co-Authored-By: Siigari <djriot@gmail.com>
Fix CI: version was in dataPaths.json but missing from versions.json.
def9a2a4 added a commit to def9a2a4/BlockShips that referenced this pull request May 11, 2026
…ersion yet

The mineflayer test bot crashes on 26.1.2 with "unsupported protocol
version: 26.1.2" because minecraft-protocol/minecraft-data haven't
added protocol mappings for the new Minecraft versioning scheme yet.

See failing run:
https://github.com/def9a2a4/BlockShips/actions/runs/25650786286/job/75288572862

For 26.x, CI now runs a server-startup-only test (new Makefile target)
that verifies the server starts and BlockShips loads without errors,
skipping the bot integration tests. All 1.21.x versions still run the
full bot test suite.

Depends on upstream support:
- PrismarineJS/minecraft-data#1184
- PrismarineJS/node-minecraft-protocol#1481
do-tlin pushed a commit to do-tlin/minecraft-data that referenced this pull request May 12, 2026
Siigari's PR PrismarineJS#1184 left status.toClient.packet and status.toServer.packet
with empty mappings={} and fields={} — meaning mineflayer can't dispatch
packet ID 0x00 (status response) to packet_server_info parser.

Symptom: bot's pre-connect ping_server() fails with 'Chunk size is 156
but only 1 was read; partial packet: {"name":0}'. Then LoginGuard
flags 'Server is under maintenance' and bot exits.

Status protocol is stable across MC versions (1.7 through 26.1.2 inclusive)
so backfill from 1.21.11 is safe:
  toClient: 0x00=server_info, 0x01=ping → packet_server_info / packet_ping
  toServer: 0x00=ping_start, 0x01=ping → packet_ping_start / packet_ping
do-tlin pushed a commit to do-tlin/minecraft-data that referenced this pull request May 12, 2026
…+ initialize_border

Siigari's PR PrismarineJS#1184 defined packet_X type schemas but left their
play.toClient dispatch table entries NULL. Bot's protodef parses
the wire bytes as raw varint name (e.g. {name:133}) instead of
running through the proper schema → 'Chunk size X but only Y was
read' warnings → eventual parse-cascade disconnect (PrismarineJS#53).

Fix is dispatch-only — packet schemas were already defined:
  0x2b (43)  -> initialize_world_border -> packet_initialize_world_border
  0x7f (127) -> set_ticking_state       -> packet_set_ticking_state
  0x80 (128) -> step_tick               -> packet_step_tick
  0x85 (133) -> recipe_book_add         -> packet_recipe_book_add

This matches the same pattern we already used to fix status phase
dispatch (commit f5bd970). 15 more packet types remain orphan-
dispatched; we'll add as they manifest during smoke.
do-tlin pushed a commit to do-tlin/minecraft-data that referenced this pull request May 12, 2026
MC 26.1.2 ClientboundSetTimePacket (per javap inspection of bundled
server jar):
  - gameTime: long
  - clockUpdates: Map<Holder<WorldClock>, ClockNetworkState>

Siigari's PR PrismarineJS#1184 carries 1.21.x layout {age, time, tickDayTime}
which doesn't match — parser stops at 18 bytes of 34-byte packet,
leaving stream misaligned and cascading parse errors.

Fix: parse gameTime (only field mineflayer's time.js consumes after
PR #3879 patch), consume remaining clockUpdates Map as opaque
restBuffer. Bot loses per-clock dayTime granularity (no day/night
awareness) but doesn't disconnect. WorldClock registry deserialization
is v3 deferred.

This is the same pattern Mojang uses for other complex structures
that PrismarineJS hasn't yet schema'd — buffer + consumer-side parse.
do-tlin added a commit to do-tlin/minecraft-data that referenced this pull request May 12, 2026
…fix LpVec3 + use_entity

Replaces our Siigari-PR-PrismarineJS#1184-derived protocol.json with mneuhaus's
PR PrismarineJS#1186 (PrismarineJS#1186,
head bc0c595, opened 2026-05-12, 49 mineflayer external tests passing).

ROOT CAUSE (bytecode-verified 2026-05-12):
- MC 26.1.2 server-26.1.2.jar contains new class net/minecraft/network/LpVec3.class
- ClientboundSetEntityMotionPacket.STREAM_CODEC <clinit>+8 reads via
  net/minecraft/world/phys/Vec3.LP_STREAM_CODEC → BootstrapMethods table
  cites LpVec3.read/write
- Our prior schema mistyped packet_entity_velocity.velocity,
  packet_spawn_entity.velocity, and packet_use_entity.location as vec3i16
  (3 × i16 = 6 bytes, notch-quantized) when wire format is actually
  LpVec3 (variable-length bit-packed with scale bits + continuation
  flag + optional VarInt extension)
- Byte-coincident wire size (6 bytes minimum LpVec3) → packet parses
  without PartialReadError but values are garbage → mineflayer applies
  garbage to bot.entity.velocity → physics integration → "10× knockback
  catapult" symptom (bot launched 60+ blocks, dies on fall)

FIX (this commit):
- packet_entity_velocity.velocity: vec3i16 → lpVec3
- packet_spawn_entity.velocity: vec3i16 → lpVec3
- packet_use_entity: rewritten (entityId + hand + location: lpVec3 +
  usingSecondaryAction)
- Many adjacent shapes updated to match upstream-canonical 26.1.2 schema
- Codec (lpVec3.js) already in node-minecraft-protocol@1.66.0; no new
  protodef type needed

Spec: docs/superpowers/specs/2026-05-12-mc26-protocol-schema-audit-design.md

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants