Add Minecraft PC 26.2 data (protocol 776)

[DallasCarraher]

Summary

Registers Minecraft PC 26.2 (protocol 776), closing the gap tracked in #1197 and the stalled scaffold in #1219.

This is the 26.2-specific slice of #1287, pulled out so it can be reviewed and merged on its own:

• All 19 data/pc/26.2/*.json files (blocks, items, entities, recipes, commands, loot tables, language, protocol.json regenerated from proto.yml, etc.), taken verbatim from [Java] Fill data gaps from vanilla sources: 26.2, 1.13.1 palettes, 1.14.2, windows, commands, 1.9.1 #1287, sourced there from Mojang's 26.2 data generator reports/decompiled sources and cross-checked against a third-party extraction.
• data/pc/1.20.3/windows.json (new file, also from [Java] Fill data gaps from vanilla sources: 26.2, 1.13.1 palettes, 1.14.2, windows, commands, 1.9.1 #1287) adding the crafter_3x3 menu that's been missing from windows.json since 1.20.3, so 26.2's windows dataPath entry is accurate instead of falling back to the stale 1.16.1 file.
• data/pc/latest/proto.yml bumped from 26.1 to 26.2 with the 8 wire-format diffs (sessionId, onlineMode, team packet reorder, spectator_action rename, sulfur_cube slot component, particle registry additions, etc.).
• Registration: data/dataPaths.json, data/pc/common/versions.json, README.md.

Deliberately not included from #1287: the unrelated 1.13.1/1.14.2/1.9.1 fixes and the broader commands.json refresh for older already-released versions — those are separate concerns better reviewed on their own.

effects/enchantments/instruments are borrowed from 26.1 since those registries are unchanged in 26.2 (per #1287's own notes).

Test plan

• npm test in tools/js (mocha + ajv schema validation): 1887 passing, 1 pending, 0 failing
• npm run lint (standard): clean
• Live-tested against a real 26.2 server with mineflayer/node-minecraft-protocol

[DallasCarraher]

Live-tested this against a real vanilla 26.2 server (official Mojang server.jar, protocol 776, offline mode, verified sha1).

Protocol-level test (minecraft-protocol, using this branch's data via a node-minecraft-data submodule swap):

• TCP connect → login → 82 packets parsed, including a full chunk packet → 0 parse errors.
• Confirms protocol.json correctly decodes the real 26.2 wire format end to end.

mineflayer:
mineflayer@latest and prismarine-chunk@latest both hardcode their own per-major-version allowlists independent of minecraft-data (lib/version.js's testedVersions, and chunkImplementations.pc in prismarine-chunk). Both needed a one-line 26.2 entry (aliased to the same 1.18-family chunk impl 26.1 uses, since nothing in this PR changes the chunk section format) before mineflayer would even attempt a connection — expected, unrelated follow-up PRs in those repos once this lands.

With those two bumped locally, I also hit prismarine-physics@1.11.1 throwing No liquid gravity settings, have you made sure the liquid gravity features are up to date? — but this isn't 26.2-specific: independentLiquidGravity/proportionalLiquidGravity aren't defined in features.json for any version on current master, so this reproduces identically on 26.1 or 1.21.11 with the currently published prismarine-physics. Pre-existing cross-repo gap, not something this PR needs to fix.

Summary: the actual minecraft-data changes in this PR check out against a live server. The mineflayer-side blockers are separate, expected follow-ups in sibling repos.

[DallasCarraher]

Update: getting this working end-to-end against a real mineflayer bot (pathfinder, collectblock, pvp, tool, armor-manager) surfaced four downstream gaps in sibling repos — none blocking this PR itself, but each needed for a full 26.2 bot to actually work once this data lands. Opened fixes for all of them, each independently tested against this branch:

• PrismarineJS/prismarine-chunk#333 — chunk implementation mapping was missing for 26.2
• PrismarineJS/prismarine-physics#143 — proportionalLiquidGravity feature list was missing 26.2 (pre-existing gap, not 26.2-specific in cause — reproduces on 26.1 too with the currently published package)
• PrismarineJS/node-minecraft-protocol#1529 — server-side login success packet needed the new sessionId field
• PrismarineJS/mineflayer#4121 — 26.2 added to testedVersions (only mergeable once this PR ships in a release, since it gates support at require-time)

With all four applied locally on top of this branch: mineflayer's internal test suite passes 39/39 (1 pending) for 26.2, node-minecraft-protocol's full suite passes 6787/6789 (2 pre-existing unrelated failures, zero attributable to 26.2), and a live bot with the full plugin stack spawned and pathfound successfully against a real vanilla 26.2 server.

[extremeheat]

#1219 isn't stalled, it's the automatically generated boilerplate for supporting new version. One branch allows multiple people to work toward it vs needing one large PR. We can merge PRs toward that branch as there already PRs testing against it in node-minecraft-protocol and mineflayer CI wise

So we can likely point this PR against pc_26_2 branch

[extremeheat]

I updated pc_26_2 branch to latest master

Can you rebase this on that branch/cherry pick commits on new checkout of that branch to resolve conflict? Thanks

[DallasCarraher]

Done — rebased onto pc_26_2 and retargeted this PR's base branch there. Force-pushed the same branch rather than opening a new PR, so the history/comments stay put.

One thing worth flagging from the rebase: pc_26_2's scaffold protocol.json had the same sessionId/onlineMode fields already patched in (nice, matches what I'd found independently), but it's otherwise still the stale copy-of-26.1 scaffold — missing the other wire changes this PR adds (team packet reorder, spectator_action rename, sulfur_cube slot component, particle registry additions, etc.), all diffed against the real 26.2 sources and live-tested against a vanilla server. Since the two files overlapped on the same lines, git flagged it as a conflict rather than merging cleanly — resolved by taking this PR's complete protocol.json wholesale. Also had to deduplicate a leftover second "26.2" key in dataPaths.json that the auto-merge produced (one from the scaffold's minimal entry, one from this PR's full one) — kept this PR's complete entry.

Full test suite still green post-rebase: 1887 passing, 1 pending, 0 failing.

[VasilisDragon]

AI agent review — manually approved by Vasilis.

Reviewed 3833a145 against the PR base. Checked the changed protocol definitions and data against hash-verified vanilla 26.2 artifacts, executed selected vanilla codecs, and compared baseline/candidate decoding, encoding and loader output. The inline findings cover two wire-format issues and three entity/attribute data corrections. The earlier ItemStackTemplate concern is addressed at this revision.

Generation produced no drift, including a repeated candidate build. Existing tooling and packet tests retained failures reproduced on the base. Interpreted codec diagnostics needed a separate adapter for an existing NBT-registration typo. No live vanilla server testing was performed, and the selected cycle tests had no recorded packets.

[VasilisDragon]

AI agent review — manually approved by Vasilis.

These metadata keys need the new inherited fields. In 26.2, AbstractCubeMob extends AgeableMob, whose accessors occupy IDs 16 (baby) and 17 (age_locked). size moves to 18. SulfurCube then allocates max_fuse at 19 and from_bucket at 20.

Currently, a size update at ID 18 maps to max_fuse for sulfur_cube and has no metadata key for slime or magma_cube. Please update all three entries, preserving the accessor allocation order.

[DallasCarraher]

Confirmed and fixed. Decompiled the accessor definition order directly: AgeableMob.<clinit> defines DATA_BABY_ID then AGE_LOCKED (both booleans, indices 16/17 after the 16 inherited from Entity/LivingEntity/Mob), AbstractCubeMob.<clinit> defines one ID_SIZE (int, index 18), and SulfurCube.<clinit> defines MAX_FUSE (int) then FROM_BUCKET (boolean) — indices 19/20, in that order.

slime and magma_cube were missing baby/age_locked entirely, and sulfur_cube had from_bucket/max_fuse both mis-positioned and swapped. Fixed all three to ..., mob_flags, baby, age_locked, size, max_fuse, from_bucket. Pushed in 2003e22.

[DallasCarraher]

Addressed all five findings from the latest review (2003e22) — verified each independently by decompiling the real 26.2 server jar with CFR before fixing, rather than taking the review at face value:

1. packet_entity_teleport — the pc_26_2 rebase had also silently dropped pc/protocol: entity_teleport layout for 1.21.2+ (velocity, f32 rotation, relative flags) #1273's 1.21.2+ layout fix (same failure mode as the ItemStackTemplate regression from the last round). Restored; now matches packet_position's layout field-for-field, as expected.
2. packet_spectator_action.entityId — confirmed vanilla's OPTIONAL_VAR_INT is a raw sentinel varint with no presence byte, not protodef's standard option. Changed to optvarint (the existing alias already used for this exact pattern elsewhere).
3. entities.json slime/magma_cube/sulfur_cube — confirmed via SynchedEntityData.defineId call order in AgeableMob/AbstractCubeMob/SulfurCube bytecode. Added missing baby/age_locked, fixed sulfur_cube's swapped max_fuse/from_bucket.
4. bee dimensions — confirmed EntityTypes.BEE.sized(0.55f, 0.5f); was still 26.1's 0.7/0.6.
5. knockbackResistance attribute min — confirmed RangedAttribute(0.0, -2.0, 1.0); was 0.0.

Full test suite green throughout (1887 passing, 1 pending, 0 failing), and re-verified live connectivity against a real 26.2 server after each round of fixes.

[extremeheat]

Backport to prev relevant versions or preserve old naming

[Pix3lPirat3]

Heads-up: data/pc/26.2/blocks.json here has material: incorrect_for_wooden_tool on 108 blocks (ores, obsidian, metal blocks), which makes prismarine-block digTime() ~8x too slow for them - the bug #1307 fixes for 1.20.5-26.1.

It comes from PrismarineJS/minecraft-data-generator#77's 26.2 module lacking the fix from PrismarineJS/minecraft-data-generator#86. Regenerating once that lands, or applying the same incorrect_for_wooden_tool -> mineable/pickaxe mapping to those 108 blocks, would keep 26.2 from regressing.

[extremeheat]

Merging into 26.2 branch to remove PR congestion

[VasilisDragon]

One remaining follow-up for pc_26_2: could we regenerate the embedded login registries from 26.2? loginPacket.json is unchanged from 2003e226, which I tested in the earlier review.

Vanilla 26.2's Enchantment.DIRECT_CODEC rejects eight entries: bane_of_arthropods, channeling, impaling, looting, lunge, power, punch and smite. They still use older entity-predicate structures. For bane_of_arthropods, changing just the two predicate keys from type to minecraft:entity_type makes it decode and match the official resource. The other entries need their current structures too. Source: EntityPredicate and registered subpredicate names.

All 43 official enchantment resources passed the same harness and registry context. This is inherited stale data, not a regression from the latest fixes. NMP uses these registries by default for servers; these were native-codec checks, not a live vanilla-client connection.