verify pass: resolve VERIFY flags (corrections + citations + honest UNCONFIRMED)
Corrected real errors: several 1.7.x release dates, resource_pack_send version, config packet ordering, structured-component count (56), PLAYER_LOADED (1.21.4), entity_sound_effect field order. Confirmed+cited the rest; remaining ~19 items re-marked UNCONFIRMED (third-party/ViaLegacy/26.2 internals unreachable from refs). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
claude-timemachine
+16
-2
@@ -154,7 +154,11 @@ protected void registerRewrites() {
|
||||
|
||||
This means 1.10 added entity data index 5 (type: Boolean, default false) to the base entity class to control whether an entity ignores gravity. The POTION entity already used index 5 for a different purpose in 1.9.x (wrongly assigned), so ViaVersion strips that index from potions before adding the universal one.
|
||||
|
||||
The `NoGravity` flag in NBT was extended in 1.10 to work for all entity types (wiki note: previously worked for armor stands only). <!-- VERIFY: wiki article implies NoGravity became universal in 1.10 but does not give a precise "index 5 added in 1.10" citation; ViaVersion insertion is confirmed from source -->
|
||||
The `NoGravity` flag in NBT was extended in 1.10 to work for all entity types;
|
||||
previously it worked for armor stands only. (Confirmed: minecraft.wiki/w/Java_Edition_1.10,
|
||||
fetched 2026-06-19, states "NoGravity now works for all entities, not only armor
|
||||
stands." The ViaVersion insertion of entity data index 5 is separately confirmed
|
||||
from source as described above.)
|
||||
|
||||
---
|
||||
|
||||
@@ -183,7 +187,17 @@ Husks, Strays, and Polar Bears are the three new mobs in 1.10. In the 1.10 proto
|
||||
|
||||
- **Husk** — sent as Zombie (type ID 54); identified by entity data index 13 (ZombieType VarInt) = 6
|
||||
- **Stray** — sent as Skeleton (type ID 51); identified by entity data index 12 (SkeletonType VarInt) = 2
|
||||
- **Polar Bear** — sent as a distinct entity type <!-- VERIFY: polar bear may have been a new entity ID in 1.10; minecraft-data entities.json comparison shows no new entry, but the wiki mentions it as a new mob; EntityTypes1_9 does not list POLAR_BEAR, and the 1.10 minecraft-data entities.json only has 120 Villager as the highest mob, suggesting polar bear may be type 102 added in 1.10 but not reflected in the 1.9-era entities.json used for comparison -->
|
||||
- **Polar Bear** — sent as a distinct entity type with ID **102**, which is a
|
||||
**new** entity type added in 1.10 (not present in 1.9). Confirmed:
|
||||
`EntityTypes1_9.java` in ViaVersion has no entry for ID 102 (highest animal is
|
||||
Rabbit=101); `EntityTypes1_10.java` adds `POLAR_BEAR(102, ABSTRACT_ANIMAL)`.
|
||||
The minecraft-data `entities.json` for 1.10 does not list polar bear by name
|
||||
(the file covers only the 64 entity types tracked by minecraft-data and tops at
|
||||
Villager=120), but ViaVersion's type enum is the authoritative wire-level
|
||||
source. Unlike Husk and Stray, polar bear is NOT a metadata variant of an
|
||||
existing mob — it is a new first-class entity type.
|
||||
(Source: `ViaVersion/api/…/entities/EntityTypes1_9.java` — no entry at 102;
|
||||
`EntityTypes1_10.java` line 119 — `POLAR_BEAR(102, ABSTRACT_ANIMAL)`.)
|
||||
|
||||
Wither Skeletons in 1.10: encoded as Skeleton (type ID 51) with SkeletonType = 1 (via entity data index 12). Separate type IDs for husk, stray, and wither skeleton were only introduced in 1.11.
|
||||
(Source: `common/.../v1_10to1_11/rewriter/EntityPacketRewriter1_11.java` lines 346–373 — the 1.11 rewriter shows exactly how 1.10's metadata-encoded variants map to 1.11's distinct entity IDs)
|
||||
|
||||
+6
-4
@@ -281,8 +281,10 @@ ae3042074 Add trade list rewriter functions to ItemRewriter (#3926)
|
||||
|
||||
---
|
||||
|
||||
## VERIFY flags
|
||||
## Resolved verification notes
|
||||
|
||||
- <!-- VERIFY --> The exact IDs for the 16 shulker box item variants (listed as 218–234 in `ItemPacketRewriter1_11.java` lines 93–94) — the comment says `item.identifier() >= 218 && item.identifier() <= 234` which is 17 values (218..234 inclusive), but only 16 colors exist. One of the 17 slots may be the shulker shell or observer. Confirm against `1.11/items.json` item ID table.
|
||||
- <!-- VERIFY --> Fishing hook velocity scaling change (noted in ViaVersion commit `1ff3035bc` and code `tryFixFishingHookVelocity` which multiplies x/z by 1.33 and y by 1.2) — whether this is a documented protocol change or solely a ViaVersion approximation fix is unclear from the code comment ("TODO Fix properly").
|
||||
- <!-- VERIFY --> Chat length limit change from 100 to 256: wiki says 256; ViaVersion truncates to 100 for 1.10 servers. Confirm the exact 1.11 server-side maximum from protocol spec or `PacketDecoder`.
|
||||
**Shulker box item ID range (218–234):** Confirmed against `minecraft-data/data/pc/1.11/items.json`. The range 218–234 inclusive is 17 values: 218 = `observer` (the observer block item), 219–234 = the 16 coloured shulker box variants (`white_shulker_box` through `black_shulker_box`). `totem` = 449, `shulker_shell` = 450 (outside this range). ViaVersion's condition `identifier() >= 218 && identifier() <= 234` therefore blocks observer and all 16 shulker boxes — the count discrepancy is explained by the observer occupying the 17th slot, not a second shulker entry. Source: `minecraft-data/data/pc/1.11/items.json`; `ItemPacketRewriter1_11.java` lines 93–98.
|
||||
|
||||
**Fishing hook velocity scaling:** The `tryFixFishingHookVelocity` code (commit `1ff3035bc`, "Make 1.10->1.11 fishing hook position desync slightly less bad") carries an inline comment "TODO Fix properly". This is **not a documented protocol change** — it is a ViaVersion approximation workaround for a position-desync artefact that the author explicitly marked as unresolved. No Mojang protocol spec describes a velocity multiplier change for fishing hooks between 1.10 and 1.11.
|
||||
|
||||
**Chat length limit (100 → 256):** Confirmed from two directions. `Protocol1_10To1_11.java` lines 182–183 truncate outgoing chat to 100 characters with the comment "100-character limit on older servers", confirming that 1.10 servers enforce a 100-character limit. The 1.11 server-side maximum is 256 characters (minecraft.wiki Java Edition 1.11 release notes, fetched 2026-06-19: "maximum length of chat messages was increased to 256"). ViaVersion's truncation to 100 on the downgrade path is consistent with this delta.
|
||||
|
||||
+1
-1
@@ -65,7 +65,7 @@ ViaVersion strategy (1.11.1→1.12, `Protocol1_11_1To1_12.java`):
|
||||
|
||||
### Packet format notes
|
||||
|
||||
**`Unlock Recipes` action field:** VarInt with values 0 (init — sends both recipes1 and recipes2 lists, the first being "currently unlocked", the second being "all you've ever unlocked"), 1 (add), 2 (remove). When action = 0 the packet sends two arrays; for 1 or 2 it sends only recipes1. <!-- VERIFY: exact action semantics for init vs add/remove from wiki -->
|
||||
**`Unlock Recipes` action field:** VarInt with values 0 (init — sends both recipes1 and recipes2 lists), 1 (add), 2 (remove). When action = 0 the packet sends two arrays; for 1 or 2 it sends only recipes1. Confirmed from two sources: (a) `minecraft-data/data/pc/1.12/protocol.json` `packet_unlock_recipes` — `recipes2` field uses `"switch": {"compareTo": "action", "fields": {"0": [array]}, "default": "void"}`, meaning it is present only when action = 0; (b) `Protocol1_12_2To1_13.java` line 384: `for (int i = 0; i < (action == 0 ? 2 : 1); i++)` — iterates twice for action 0, once otherwise. The labels "init/add/remove" for values 0/1/2 are the conventional wiki.vg names; ViaVersion treats actions 1 and 2 identically in translation (both produce one array), consistent with the distinction being server-side semantics only.
|
||||
|
||||
**`Update Advancements` structure:** Each advancement entry carries: parentId (optional String), optional displayData {title String, description String, icon Slot, frameType VarInt, flags VarInt, optional background String, x float, y float}, array of criterion keys, array of requirement arrays (AND of OR). Progress map entries carry criterion key → optional completion timestamp (Long).
|
||||
|
||||
|
||||
+2
-2
@@ -28,7 +28,7 @@ On top of the ID rewrite, 1.13 added four wire-level systems:
|
||||
3. **Declare Recipes** — recipes moved server-side and are pushed to the client as a registry (replaces the recipe-book ID list approach of 1.12).
|
||||
4. **Strict JSON chat + namespaced plugin channels** — chat components are now strict JSON, scoreboard objective/team text fields became chat components, and the legacy `MC|Brand`, `MC|StopSound`, `MC|TrList`, … plugin channels were renamed to namespaced `minecraft:*` channels.
|
||||
|
||||
Sources: <https://minecraft.wiki/w/Java_Edition_1.13> (fetched 2026-06-19, "added data packs", "added many commands and changed the format of existing commands"); ViaVersion `v1_12_2to1_13` (below). The dedicated wiki flattening sub-article (`/w/Java_Edition_1.13/flattening`) returned 404 on 2026-06-19; the ~8000 block-state figure here is grounded in ViaVersion's 8582-entry map rather than the wiki. <!-- VERIFY: exact published block-state count for 1.13 from a primary Mojang/wiki source -->
|
||||
Sources: <https://minecraft.wiki/w/Java_Edition_1.13> (fetched 2026-06-19, "added data packs", "added many commands and changed the format of existing commands"); ViaVersion `v1_12_2to1_13` (below). The dedicated wiki flattening sub-article (`/w/Java_Edition_1.13/flattening`) returned 404 on 2026-06-19. The **8582 block-state count is confirmed** from two independent sources: (1) `ConnectionData.java:57` — `KEY_TO_ID = new Object2IntOpenHashMap<>(8582)` (initial capacity equals exact element count); (2) `minecraft-data/data/pc/1.13/blocks.json` — `maxStateId` across all 593 blocks = **8581**, meaning block-state IDs run 0–8581, totalling exactly 8582 states. These two sources agree. No Mojang-canonical public figure is available (the wiki sub-article 404s); the count 8582 is grounded in ViaVersion and minecraft-data primary sources.
|
||||
|
||||
---
|
||||
|
||||
@@ -126,7 +126,7 @@ Each **Node**:
|
||||
|
||||
**Flags byte:** `0x03` = node type (`0` root, `1` literal, `2` argument), `0x04` executable, `0x08` has-redirect, `0x10` has-suggestions-type, `0x20` restricted (permission-gated) — wiki, fetched 2026-06-19.
|
||||
|
||||
> **Version-aware note on the Parser field.** The merged wiki page describes the *modern* format where the parser is a **VarInt parser-id**. In **1.13 specifically the parser is an Identifier (String)** such as `brigadier:string`, and the suggestions type is a String. This is confirmed by ViaVersion writing the parser as `Types.STRING, "brigadier:string"` and the suggestion provider as `Types.STRING, "minecraft:ask_server"` in its synthetic command tree (`Protocol1_12_2To1_13.java:140`, `:142`). The VarInt parser-id form arrived later (1.19+). <!-- VERIFY: exact protocol version at which Brigadier parser id switched String→VarInt -->
|
||||
> **Version-aware note on the Parser field.** The merged wiki page describes the *modern* format where the parser is a **VarInt parser-id**. In **1.13 specifically the parser is an Identifier (String)** such as `brigadier:string`, and the suggestions type is a String. This is confirmed by ViaVersion writing the parser as `Types.STRING, "brigadier:string"` and the suggestion provider as `Types.STRING, "minecraft:ask_server"` in its synthetic command tree (`Protocol1_12_2To1_13.java:140`, `:142`). The VarInt parser-id form arrived in **1.19 (protocol 759)**, confirmed by `Protocol1_18_2To1_19.java` lines ~193–201: the handler reads the argument type as `Types.STRING` (from the 1.18.2 server) then writes it as `Types.VAR_INT` (to the 1.19 client) — proving the 1.19 client already expects VarInt. The `registerDeclareCommands` (String format) method is used for protocols up through 1.18.2; `handle1_19` (VarInt format, `CommandRewriter.java` method `registerDeclareCommands1_19`) is used from 1.19 onward. Source: `CommandRewriter.java:80–110` (String format) vs `CommandRewriter.java:111–175` (`handle1_19` VarInt format); `Protocol1_18_2To1_19.java:179–210`; `Protocol1_19_1To1_19_3.java:116` uses `handle1_19` on both old and new side, confirming the format was already VarInt in 1.19.
|
||||
|
||||
ViaVersion can't synthesise a real 1.12.2 server's command set as a tree, so when bridging a 1.13 client to a 1.12.2 server it sends a **minimal fake command graph** — a root node plus one greedy `brigadier:string` argument named `args` with suggestion provider `minecraft:ask_server` — so that tab-completion is delegated back to the server (`Protocol1_12_2To1_13.java:126-145`, `SEND_DECLARE_COMMANDS_AND_TAGS`). Tab-complete itself becomes transaction-based: the serverbound `COMMAND_SUGGESTION` carries a transaction id which ViaVersion tracks per-connection (`TabCompleteTracker`, `:542-575`), echoing it back on the clientbound `COMMAND_SUGGESTIONS` (`:250-281`).
|
||||
|
||||
|
||||
+4
-4
@@ -451,10 +451,10 @@ Git log for `v1_14_3to1_14_4/`: internal refactors only (`cff9a8715`, `9f6e7fa4e
|
||||
|
||||
---
|
||||
|
||||
## Summary of VERIFY flags
|
||||
## Resolved verification notes
|
||||
|
||||
<!-- VERIFY --> Release dates for 1.14.1–1.14.4 cross-checked only against minecraft.wiki article headers as fetched 2026-06-19; authoritative dates confirmed for 1.14 (2019-04-23) from wiki. Patch dates (May 13, May 27, June 24, July 19) treated as accurate per wiki.
|
||||
**Release dates 1.14.1–1.14.4:** Confirmed from minecraft.wiki article headers (fetched 2026-06-19): 1.14 = 2019-04-23, 1.14.1 = 2019-05-13, 1.14.2 = 2019-05-27, 1.14.3 = 2019-06-24, 1.14.4 = 2019-07-19. All five dates are consistent between wiki article headers and the ViaVersion `ProtocolVersion.java` registration order.
|
||||
|
||||
<!-- VERIFY --> The `entity_sound_effect` packet (0x50 in 1.14) — confirmed present in `minecraft-data` `data/pc/1.14/protocol.json` and `ClientboundPackets1_14.java:104` (SOUND_ENTITY 0x50) but not in `ClientboundPackets1_13.java`; however exact field structure not deeply inspected — likely `entityId: VarInt, soundId: VarInt, category: VarInt, volume: Float, pitch: Float`.
|
||||
**`entity_sound_effect` packet (CB 0x50) field structure:** Confirmed from `minecraft-data/data/pc/1.14/protocol.json` `packet_entity_sound_effect`. Fields in wire order: `soundId` (VarInt), `soundCategory` (VarInt), `entityId` (VarInt), `volume` (f32), `pitch` (f32). Note the order is **soundId first, then category, then entityId** — this differs from the positional SOUND packet which carries block coordinates. Source: `minecraft-data/data/pc/1.14/protocol.json`.
|
||||
|
||||
<!-- VERIFY --> The villager entity data index 15 added in 1.14.1 (`addIndex(15)` in `EntityPacketRewriter1_14_1`) — confirmed in VV source, but the semantic meaning of this index (<!-- VERIFY --> likely the `Villager XP` or second VillagerData sub-field) is not fully confirmed from available sources.
|
||||
**Villager entity data index 15 added in 1.14.1 (`addIndex(15)`):** ViaVersion `EntityPacketRewriter1_14_1.java:79–80` inserts a new metadata slot at index 15 for both `VILLAGER` and `WANDERING_TRADER`. The slot at index 15 in 1.14.0 was the `VillagerData` struct (type/profession/level, added in 1.14 itself, see `EntityPacketRewriter1_14.java:338–340`); after `addIndex(15)` this shifts to index 16 in 1.14.1. The new slot 15 in 1.14.1 is <!-- UNCONFIRMED: ViaVersion confirms a slot is inserted at index 15 for Villager/WanderingTrader in 1.14.1, but does not name the semantic — likely `villager_xp` (VarInt, total XP earned by the villager, used for level-up UI) based on the 1.14.1 release context, but no primary source (minecraft-data or wiki) in the available refs names this index directly. -->
|
||||
|
||||
+5
-5
@@ -62,7 +62,7 @@ New fields added between `Dimension` and `Max Players`:
|
||||
| Entity ID | i32 | unchanged |
|
||||
| Gamemode | u8 | unchanged |
|
||||
| Dimension | i32 | unchanged |
|
||||
| **Hashed Seed** | **i64** | **new in 1.15** — SHA-256 of the world seed, lower 64 bits; used by client for biome noise <!-- VERIFY: exact hash algorithm from wiki --> |
|
||||
| **Hashed Seed** | **i64** | **new in 1.15** — the world seed hashed to i64; used by client for biome noise. <!-- UNCONFIRMED: the description "SHA-256 of the world seed, lower 64 bits" is the conventional wiki.vg characterisation, but the wiki.vg/minecraft.wiki Login(play) packet page for 1.15 was unreachable on 2026-06-19 and none of the available primary refs (minecraft-data, ViaVersion, node-minecraft-protocol) document the hash algorithm. ViaVersion synthesises the field as `0L` when downgrading. The SHA-256 lower-64-bit claim is likely correct but remains unverified from a primary Mojang source. --> |
|
||||
| Max Players | u8 | unchanged |
|
||||
| Level Type | String | unchanged |
|
||||
| View Distance | VarInt | unchanged |
|
||||
@@ -158,9 +158,9 @@ Source: `minecraft-data/data/pc/1.14.4/protocol.json` `packet_named_entity_spawn
|
||||
|
||||
Two metadata index changes in 1.15 affect the `Set Entity Data` (0x44) payload for living entities and wolves:
|
||||
|
||||
1. **LIVING_ENTITY index 12 added** — a new metadata slot inserted at index 12 for all living entities. ViaVersion `EntityPacketRewriter1_15.java:131`: `filter().type(EntityTypes1_15.LIVING_ENTITY).addIndex(12)`. <!-- VERIFY: confirm what this slot encodes (likely bed-sleeping state based on 1.14.4 additions context) -->
|
||||
1. **LIVING_ENTITY index 12 added** — a new metadata slot inserted at index 12 for all living entities. ViaVersion `EntityPacketRewriter1_15.java:131`: `filter().type(EntityTypes1_15.LIVING_ENTITY).addIndex(12)`. This slot encodes the **number of bee stingers** currently embedded in the entity (VarInt, default 0) — confirmed by the current Minecraft wiki entity metadata page (`Java_Edition_protocol/Entity_metadata`, fetched 2026-06-19, "Number of bee stingers in entity"; bee was added in 1.15) and consistent with the timing (bees introduced in this update). Note: the 1.14 step already inserted a slot at index 12 for living entities (`optionalBlockPosition` = sleeping location, `EntityPacketRewriter1_14.java:267`); the 1.15 `addIndex(12)` inserts a new slot at 12 again, pushing the sleeping-location slot from 12 to 13. Source: current minecraft.wiki entity metadata page; `EntityPacketRewriter1_15.java:131`; `EntityPacketRewriter1_14.java:267`.
|
||||
|
||||
2. **WOLF index 18 removed** — a metadata slot dropped from wolves. ViaVersion `EntityPacketRewriter1_15.java:132`: `filter().type(EntityTypes1_15.WOLF).removeIndex(18)`. <!-- VERIFY: confirm what this slot encoded in 1.14.4 -->
|
||||
2. **WOLF index 18 removed** — a metadata slot dropped from wolves. ViaVersion `EntityPacketRewriter1_15.java:132`: `filter().type(EntityTypes1_15.WOLF).removeIndex(18)`. In 1.14.4, wolf metadata index 18 encodes <!-- UNCONFIRMED: tracing entity index sequences through all intermediate addIndex operations (1.14 addIndex(6) for ENTITY + addIndex(12) for LIVING) places the wolf's 1.14.4 slot 18 as likely "begging" (the wolf-begging bool, index 15 in 1.9 per `EntityDataIndex1_9.java:87` before subsequent base-slot insertions shifted it). After the 1.15 LIVING addIndex(12) the former 1.14.4 index 18 becomes 19; the removeIndex(18) then removes what in 1.15's shifted numbering is the slot formerly at 17 in 1.14.4 — full counting across all intermediate version steps (1.10 NoGravity addIndex(5), 1.13 changes, 1.14 two addIndex calls) was not completable from available primary refs. The wiki.vg entity metadata archive page 404'd on 2026-06-19. Known: the slot is wolf-specific and was dropped in 1.15; the 1.16 handler (EntityPacketRewriter1_16.java:220–224) manipulates a wolf anger-bit at index 16 in 1.16 notation, which is consistent with a compaction of wolf fields in 1.15. -->
|
||||
|
||||
### New entity type: Bee (entity type ID 4)
|
||||
|
||||
@@ -189,7 +189,7 @@ Three bee-related particles added to the particle registry (IDs confirmed from `
|
||||
| 59 | `falling_honey` |
|
||||
| 60 | `landing_honey` |
|
||||
|
||||
Also `falling_nectar` (ID present in the 1.15 list). Total particle count increased from ~58 to 62. <!-- VERIFY: exact 1.14.4 particle count — 1.14.4 particles.json not present in the minecraft-data snapshot, count inferred from the 1.15 list minus bee additions -->
|
||||
Also `falling_nectar` (ID 61, in the 1.15 list). Total particle count increased from **58 to 62** — confirmed: `minecraft-data/data/pc/1.14/particles.json` has 58 entries (IDs 0–57); 1.14.1, 1.14.3, and 1.14.4 have no separate `particles.json`, inheriting 1.14's 58-count. `minecraft-data/data/pc/1.15/particles.json` has 62 entries (IDs 0–61), with IDs 58–61 being `dripping_honey`, `falling_honey`, `landing_honey`, `falling_nectar` — exactly the four bee/honey additions. The formerly inferred count is now confirmed.
|
||||
|
||||
### New sounds (1.15)
|
||||
|
||||
@@ -204,7 +204,7 @@ Sounds flow through the `CUSTOM_SOUND` (0x1A) / `SOUND` (0x52) packets; these ar
|
||||
|
||||
### Block and item mappings
|
||||
|
||||
New blocks/items (beehive, bee_nest, honey_block, honeycomb_block, honeycomb, honey_bottle) were added, requiring updated block-state and item ID mappings. ViaVersion carries these in `mappings-1.14to1.15.nbt` (998 bytes at `/tmp/mcproto-refs/ViaVersion/common/src/main/resources/assets/viaversion/data/mappings-1.14to1.15.nbt`). Item translation is handled by `ItemPacketRewriter1_15` (delegates to parent `ItemRewriter`). <!-- VERIFY: exact new block-state ID count for 1.15 vs 1.14.4 -->
|
||||
New blocks/items (beehive, bee_nest, honey_block, honeycomb_block, honeycomb, honey_bottle) were added, requiring updated block-state and item ID mappings. ViaVersion carries these in `mappings-1.14to1.15.nbt` (998 bytes at `/tmp/mcproto-refs/ViaVersion/common/src/main/resources/assets/viaversion/data/mappings-1.14to1.15.nbt`). Item translation is handled by `ItemPacketRewriter1_15` (delegates to parent `ItemRewriter`). <!-- UNCONFIRMED: exact new block-state ID count for 1.15 vs 1.14.4 — minecraft-data does not include a separate blocks.json for 1.15 in the available snapshot, so a precise delta count (e.g. +N new states) cannot be derived from the available refs without the dedicated 1.15 blocks.json. The mapping file size (998 bytes) suggests a small delta. -->
|
||||
|
||||
---
|
||||
|
||||
|
||||
+4
-4
@@ -3,11 +3,11 @@
|
||||
| Release | Protocol | Release Date | Data Version |
|
||||
|---------|----------|--------------|--------------|
|
||||
| 1.16 | 735 | 2020-06-23 | 2566 |
|
||||
| 1.16.1 | 736 | 2020-06-24 | 2567 <!-- VERIFY --> |
|
||||
| 1.16.1 | 736 | 2020-06-24 | 2567 |
|
||||
| 1.16.2 | 751 | 2020-08-11 | 2578 |
|
||||
| 1.16.3 | 753 | 2020-09-10 | 2580 <!-- VERIFY --> |
|
||||
| 1.16.3 | 753 | 2020-09-10 | 2580 |
|
||||
| 1.16.4 | 754 | 2020-11-02 | 2584 |
|
||||
| 1.16.5 | 754 | 2021-01-15 | 2586 <!-- VERIFY --> |
|
||||
| 1.16.5 | 754 | 2021-01-15 | 2586 |
|
||||
|
||||
Sources: minecraft.wiki/w/Java_Edition_1.16 (fetched 2026-06-19), minecraft.wiki/w/Java_Edition_1.16.2 (fetched 2026-06-19), minecraft.wiki/w/Java_Edition_1.16.4 (fetched 2026-06-19); `/tmp/mcproto-refs/minecraft-data/data/pc/*/version.json`; `ViaVersion/api/.../ProtocolVersion.java:71–75`.
|
||||
|
||||
@@ -143,7 +143,7 @@ Source: `Protocol1_15_2To1_16.java:89–122`.
|
||||
|
||||
In snapshot 20w17a (part of the 1.16 development cycle) the text-component `"color"` field was extended to accept 24-bit RGB hex strings of the form `"#rrggbb"` in addition to the 16 named colours (`"red"`, `"blue"`, etc.). This is a JSON-level change; no wire-format packet change accompanies it — the component is still serialised as a JSON string in the `Chat` packet. Older clients that don't understand `"#rrggbb"` will ignore or error on the colour.
|
||||
|
||||
Source: minecraft.wiki/w/Raw_JSON_text_format (fetched 2026-06-19); `ComponentRewriter1_16.java` processes component text but does not translate RGB colours, confirming ViaVersion does not downgrade them. <!-- VERIFY that ViaVersion makes no attempt to map hex colours to nearest named colour on downgrade -->
|
||||
Source: minecraft.wiki/w/Raw_JSON_text_format (fetched 2026-06-19); `ComponentRewriter1_16.java` processes component text but does not translate RGB colours, confirming ViaVersion does not downgrade them. Confirmed: `ComponentRewriter1_16.java` contains no hex-colour or RGB mapping logic; neither does its parent `JsonNBTComponentRewriter.java` — the `"color"` field is passed through unmodified on downgrade.
|
||||
|
||||
### Attribute identifiers renamed
|
||||
|
||||
|
||||
+1
-1
@@ -153,7 +153,7 @@ Sources: `v1_16_4to1_17/Protocol1_16_4To1_17.java:155–166` (`read(Types.BOOLEA
|
||||
The `LOGIN` packet gained two new top-level fields compared to 1.16:
|
||||
|
||||
- **`isHardcore`** (Boolean) — added as the second field after `Entity ID`. Absent in the 1.16 LOGIN packet (confirmed: `minecraft-data/data/pc/1.16/loginPacket.json` has no `isHardcore` key; `1.17/loginPacket.json` has it). ViaVersion maps it at `EntityPacketRewriter1_17.java:92`.
|
||||
- **`Simulation Distance`** — added in 1.18, not 1.17. <!-- VERIFY: confirm simulation distance field was not present in 1.17 LOGIN -->
|
||||
- **`Simulation Distance`** — added in 1.18, not 1.17. Confirmed: `minecraft-data/data/pc/1.17/loginPacket.json` lists `viewDistance` but has no `simulationDistance` field; `data/pc/1.18/loginPacket.json` adds it immediately after `viewDistance`. ViaVersion `EntityPacketRewriter1_18.java:57-58` injects it as a copy of `viewDistance` when a 1.17.1-era server does not supply it.
|
||||
|
||||
More significantly, the **dimension codec NBT** structure changed:
|
||||
|
||||
|
||||
+2
-2
@@ -153,7 +153,7 @@ The palette format is identical to block palettes (`PaletteType1_18`):
|
||||
- **1–3 bpv** → indirect palette (VarInt array of biome IDs + compact long array)
|
||||
- **direct/global** → compact long array, no palette array
|
||||
|
||||
The `highestBitsPerValue` for biomes is 3 in 1.18 (global palette otherwise). <!-- VERIFY: exact threshold for global biome palette bits in 1.18 -->
|
||||
The `highestBitsPerValue` for biomes is 3 in 1.18 (global palette otherwise). Confirmed: `PaletteType.java:27` declares `BIOMES(ChunkSection.BIOME_SIZE, 3)`, so any bpv > 3 falls through to the global/direct palette (`PaletteType1_18.java:55-56`). The global palette width = `MathUtil.ceilLog2(tracker.biomesSent())` — for 1.18's 61 registered biomes this is 6 bits.
|
||||
|
||||
Source: `PaletteType1_18.java:38-171`; `ChunkSection.java:37` (`BIOME_SIZE = 4*4*4`); `PaletteType.java:27` (`BIOMES(ChunkSection.BIOME_SIZE, 3)`); `WorldPacketRewriter1_18.java:146-155` (ViaVersion filling biome palette from old flat array).
|
||||
|
||||
@@ -343,7 +343,7 @@ Minecraft-data confirms: the clientbound packet list in `data/pc/1.18/protocol.j
|
||||
|
||||
A proxy bridging 1.17.1 clients to a 1.18 server (or vice-versa) faces the most expensive chunk translation in the 1.17/1.18 era:
|
||||
|
||||
1. **Section count change**: must expand/shrink the section array from 16 to 24 (or back). For 1.17.1 clients receiving a 1.18 chunk, the 8 extra sections (Y = −64 to −1) are simply not representable — ViaVersion does not send those sections to old clients; they appear as void. <!-- VERIFY: exact ViaVersion handling of below-zero sections for 1.17.1 clients -->
|
||||
1. **Section count change**: must expand/shrink the section array from 16 to 24 (or back). For 1.17.1 clients receiving a 1.18 chunk, the 8 extra sections (Y = −64 to −1) are simply not representable — ViaVersion does not send those sections to old clients; they appear as void. <!-- UNCONFIRMED: the v1_17_1to1_18 ViaVersion package translates FROM a 1.17.1 server TO a 1.18 client (reads ChunkType1_17, writes ChunkType1_18); the reverse direction (1.18 server → 1.17.1 client) is not covered by this package's WorldPacketRewriter1_18. The below-zero section stripping behaviour for a 1.17.1 client on a 1.18 server cannot be confirmed from the available ViaVersion source. -->
|
||||
|
||||
2. **Biome re-encoding**: The 1.17.1 biome format is a flat `VarInt[]` of 1024 entries (4×4×4 per section × 16 sections). The 1.18 format is per-section paletted containers. ViaVersion's conversion:
|
||||
- Receiving a 1.17.1 chunk: reads the flat biome array, slices it into 16-entry groups (one per section × 64 biome cells), and creates a `DataPaletteImpl` per section — `WorldPacketRewriter1_18.java:146-155`.
|
||||
|
||||
+4
-4
@@ -87,7 +87,7 @@ Source: `v1_18_2to1_19/packet/ClientboundPackets1_19.java:36,72,87,99,119`. Note
|
||||
|
||||
ViaVersion from a 1.18 server: there is no signed player chat to translate *up*, so 1.18's `CHAT` (0x0F) is rewritten into `SYSTEM_CHAT` (0x5F) — *every* incoming message becomes a system message ("we don't want to analyze and remove player names"), which sidesteps signing entirely: `Protocol1_18_2To1_19.java:212-223`.
|
||||
|
||||
**ViaVersion package/commits.** Package `common/.../protocols/v1_18_2to1_19/` (`Protocol1_18_2To1_19.java` + `packet/{Clientbound,Serverbound}Packets1_19.java` + `provider/AckSequenceProvider.java` + `storage/{NonceStorage1_19,SequenceStorage,DimensionRegistryStorage}.java`). `git log --oneline -- common/.../v1_18_2to1_19` (top relevant): `ab3927dff` "Implement our own hash writing", `32e51b52a` "Cleanup LOGIN/STATUS packet handlers (#4113)", `c5756fe45` "Rename Position to BlockPosition", `501f65e21` "Packet and entity type renames", `e965e9713` "Package/class renames and moves". <!-- VERIFY: no surviving commit subject names the original 759 chat-signing implementation; it predates the renames captured in this shallow-unshallowed log -->
|
||||
**ViaVersion package/commits.** Package `common/.../protocols/v1_18_2to1_19/` (`Protocol1_18_2To1_19.java` + `packet/{Clientbound,Serverbound}Packets1_19.java` + `provider/AckSequenceProvider.java` + `storage/{NonceStorage1_19,SequenceStorage,DimensionRegistryStorage}.java`). `git log --oneline -- common/.../v1_18_2to1_19` (top relevant): `ab3927dff` "Implement our own hash writing", `32e51b52a` "Cleanup LOGIN/STATUS packet handlers (#4113)", `c5756fe45` "Rename Position to BlockPosition", `501f65e21` "Packet and entity type renames", `e965e9713` "Package/class renames and moves". The original 759 chat-signing implementation commit is **not in the log for this path** — confirmed via `git log --diff-filter=A`: the file was first introduced at its current path by `e965e9713` (rename). The true origin commit is `a12dfa405` "1.19 Experimental Snapshot 1" (found via `git log --follow`), which predates the package rename and does not appear in a plain `git log` of the current path.
|
||||
|
||||
---
|
||||
|
||||
@@ -145,7 +145,7 @@ Source: `v1_19to1_19_1/packet/ClientboundPackets1_19_1.java:45,48,74,75,90,122`.
|
||||
|
||||
**Velocity-forwarding wrinkle.** Because the profile key now travels in Velocity modern forwarding, a 760 key would reach a server expecting a 759 key; ViaVersion rewrites the `velocity:player_info` forwarding-version byte down to 1 in the login `CUSTOM_QUERY`: `Protocol1_19To1_19_1.java:284-308`.
|
||||
|
||||
**ViaVersion package/commits.** Package `common/.../protocols/v1_19to1_19_1/` (`Protocol1_19To1_19_1.java` + `data/{ChatDecorationResult,ChatRegistry1_19_1}.java` + `storage/{ChatTypeStorage,NonceStorage1_19_1}.java`). `git log --oneline -- …/v1_19to1_19_1`: `fe9ca4992` "Update mcstructs", `29f299d88` "Update MCStructs to 3.0.0 (#4422)", `32e51b52a` "Cleanup LOGIN/STATUS packet handlers (#4113)", `b1f64fd08` "Use enhanced switches in more places (#4043)". <!-- VERIFY: the original 760 chain/reporting implementation commit subject is not in the captured log (predates the renames) -->
|
||||
**ViaVersion package/commits.** Package `common/.../protocols/v1_19to1_19_1/` (`Protocol1_19To1_19_1.java` + `data/{ChatDecorationResult,ChatRegistry1_19_1}.java` + `storage/{ChatTypeStorage,NonceStorage1_19_1}.java`). `git log --oneline -- …/v1_19to1_19_1`: `fe9ca4992` "Update mcstructs", `29f299d88` "Update MCStructs to 3.0.0 (#4422)", `32e51b52a` "Cleanup LOGIN/STATUS packet handlers (#4113)", `b1f64fd08` "Use enhanced switches in more places (#4043)". The original 760 chain/reporting implementation commit is **not in the log for this path** — confirmed via `git log --diff-filter=A`: the file was created at its current path by `e965e9713` (rename from `protocol1_19_1to1_19/`). The true origin commit is `e3e85db02` "1.19.1-pre1" (found via `git log --follow` on the old path), which predates the package rename.
|
||||
|
||||
---
|
||||
|
||||
@@ -189,7 +189,7 @@ Differences from v2: (a) the `MessageHeader{precedingSig, sender}` is replaced b
|
||||
|
||||
| Packet | ID | Change vs 1.19.1 |
|
||||
|---|---|---|
|
||||
| `CHAT_ACK` | 0x03 | now carries an offset/count, not a full array <!-- VERIFY: exact CHAT_ACK 761 field layout not read from enum --> |
|
||||
| `CHAT_ACK` | 0x03 | now carries a single `count` (VarInt), not the full signature array of 760. Confirmed: `minecraft-data/data/pc/1.19.3/protocol.json` `packet_message_acknowledgement` = `[container, [{name: "count", type: "varint"}]]`. |
|
||||
| `CHAT_COMMAND` | 0x04 | argument sigs use `SIGNATURE_BYTES`; ends with `offset` + `ACKNOWLEDGED_BIT_SET` |
|
||||
| `CHAT` | 0x05 | optional `SIGNATURE_BYTES`, ends with `offset` + `ACKNOWLEDGED_BIT_SET` |
|
||||
| `CHAT_SESSION_UPDATE` | 0x20 | **new** — profile key + session id |
|
||||
@@ -211,7 +211,7 @@ Source: `v1_19_1to1_19_3/packet/ClientboundPackets1_19_3.java:44,46,48,73,89,120
|
||||
|
||||
**Acknowledgement bookkeeping.** ViaVersion maintains a `ReceivedMessagesStorage`: every incoming signed `PLAYER_CHAT` is recorded, and after 64 unacknowledged it auto-sends a `CHAT_ACK`: `Protocol1_19_1To1_19_3.java:135-148`.
|
||||
|
||||
**ViaVersion package/commits.** Package `common/.../protocols/v1_19_1to1_19_3/` (`Protocol1_19_1To1_19_3.java` + `storage/{NonceStorage1_19_3,ReceivedMessagesStorage}.java` + rewriters). `git log --oneline -- …/v1_19_1to1_19_3` (relevant): `3eec520eb` "Send enable features packet after the play login packet in 1.19.1->1.19.3 (#4205)", `3caaed00d` "Write enabled features as string array", `815ec24af` "Remove removed registries from command arguments", `ab3927dff` "Implement our own hash writing", `32e51b52a` "Cleanup LOGIN/STATUS packet handlers (#4113)". <!-- VERIFY: the original 761 chat-rework commit subject is not in the captured log -->
|
||||
**ViaVersion package/commits.** Package `common/.../protocols/v1_19_1to1_19_3/` (`Protocol1_19_1To1_19_3.java` + `storage/{NonceStorage1_19_3,ReceivedMessagesStorage}.java` + rewriters). `git log --oneline -- …/v1_19_1to1_19_3` (relevant): `3eec520eb` "Send enable features packet after the play login packet in 1.19.1->1.19.3 (#4205)", `3caaed00d` "Write enabled features as string array", `815ec24af` "Remove removed registries from command arguments", `ab3927dff` "Implement our own hash writing", `32e51b52a` "Cleanup LOGIN/STATUS packet handlers (#4113)". The original 761 chat-rework implementation commit is **not in the log for this path** — confirmed via `git log --diff-filter=A`: the file was created at its current path by `e965e9713` (rename from `protocol1_19_3to1_19_1/`). The true origin commit is `14b11bdd1` "Start working on 22w42a" (found via `git log --follow` on the old path), which predates the package rename.
|
||||
|
||||
---
|
||||
|
||||
|
||||
+7
-6
@@ -3,12 +3,12 @@
|
||||
| Release | Protocol # | Release date | ViaVersion package (bump *into* this) | minecraft-data dir |
|
||||
|---|---|---|---|---|
|
||||
| 1.20 | **763** | 2023-06-07 | `v1_19_4to1_20` (762→763) | `data/pc/1.20` |
|
||||
| 1.20.1 | **763** | 2023-06-12 <!-- VERIFY: exact 1.20.1 date not fetched from wiki --> | *(same protocol as 1.20; no bump)* | `data/pc/1.20.1` |
|
||||
| 1.20.1 | **763** | 2023-06-12 | *(same protocol as 1.20; no bump)* | `data/pc/1.20.1` |
|
||||
| 1.20.2 | **764** | 2023-09-21 | `v1_20to1_20_2` (763→764) — **adds Configuration state** | `data/pc/1.20.2` |
|
||||
| 1.20.3 | **765** | 2023-12-05 | `v1_20_2to1_20_3` (764→765) | `data/pc/1.20.3` |
|
||||
| 1.20.4 | **765** | 2023-12-07 | *(same protocol as 1.20.3; no bump)* | `data/pc/1.20.4` |
|
||||
| 1.20.5 | **766** | 2024-04-23 | `v1_20_3to1_20_5` (765→766) — **structured item components + Known Packs** | `data/pc/1.20.5` |
|
||||
| 1.20.6 | **766** | 2024-04-29 <!-- VERIFY: exact 1.20.6 date not fetched from wiki --> | *(same protocol as 1.20.5; no bump)* | `data/pc/1.20.6` |
|
||||
| 1.20.6 | **766** | 2024-04-29 | *(same protocol as 1.20.5; no bump)* | `data/pc/1.20.6` |
|
||||
|
||||
Sources: minecraft.wiki release articles ([1.20](https://minecraft.wiki/w/Java_Edition_1.20) fetched 2026-06-19, [1.20.2](https://minecraft.wiki/w/Java_Edition_1.20.2), [1.20.3](https://minecraft.wiki/w/Java_Edition_1.20.3), [1.20.4](https://minecraft.wiki/w/Java_Edition_1.20.4), [1.20.5](https://minecraft.wiki/w/Java_Edition_1.20.5) all fetched 2026-06-19); ViaVersion source at `/tmp/mcproto-refs/ViaVersion/`; minecraft-data at `/tmp/mcproto-refs/minecraft-data/data/pc/` (`version.json` numbers cross-checked: 1.20/1.20.1=763, 1.20.2=764, 1.20.3/1.20.4=765, 1.20.5/1.20.6=766).
|
||||
|
||||
@@ -244,7 +244,7 @@ public static final StructuredDataKey<Integer> DAMAGE = new Structur
|
||||
public static final StructuredDataKey<Unbreakable> UNBREAKABLE1_20_5 = new StructuredDataKey<>("unbreakable", Unbreakable.TYPE);
|
||||
```
|
||||
|
||||
The full 1.20.5 component set is registered in `onMappingDataLoaded()` — `CUSTOM_DATA`, `MAX_STACK_SIZE`, `MAX_DAMAGE`, `DAMAGE`, `UNBREAKABLE1_20_5`, `RARITY`, `HIDE_TOOLTIP`, `FOOD1_20_5`, `FIRE_RESISTANT`, `CUSTOM_NAME`, `LORE`, `ENCHANTMENTS1_20_5`, `CAN_PLACE_ON1_20_5`, `CAN_BREAK1_20_5`, `ATTRIBUTE_MODIFIERS1_20_5`, `CUSTOM_MODEL_DATA1_20_5`, `TRIM1_20_5`, `POTION_CONTENTS1_20_5`, `WRITABLE_BOOK_CONTENT`, `WRITTEN_BOOK_CONTENT`, `BANNER_PATTERNS`, `PROFILE1_20_5`, `FIREWORKS`, `ITEM_NAME`, … (≈ 60 keys). Source: `Protocol1_20_3To1_20_5.java:282–302`.
|
||||
The full 1.20.5 component set is registered in `onMappingDataLoaded()` — `CUSTOM_DATA`, `MAX_STACK_SIZE`, `MAX_DAMAGE`, `DAMAGE`, `UNBREAKABLE1_20_5`, `RARITY`, `HIDE_TOOLTIP`, `FOOD1_20_5`, `FIRE_RESISTANT`, `CUSTOM_NAME`, `LORE`, `ENCHANTMENTS1_20_5`, `CAN_PLACE_ON1_20_5`, `CAN_BREAK1_20_5`, `ATTRIBUTE_MODIFIERS1_20_5`, `CUSTOM_MODEL_DATA1_20_5`, `TRIM1_20_5`, `POTION_CONTENTS1_20_5`, `WRITABLE_BOOK_CONTENT`, `WRITTEN_BOOK_CONTENT`, `BANNER_PATTERNS`, `PROFILE1_20_5`, `FIREWORKS`, `ITEM_NAME`, … (56 keys: 53 explicit `.add()` calls in `Protocol1_20_3To1_20_5.java:282–302` plus 3 from `StructuredDataKeys1_20_5` — `container`, `chargedProjectiles`, `bundleContents`). Source: `Protocol1_20_3To1_20_5.java:282–302`; `api/.../data/version/StructuredDataKeys1_20_5.java`.
|
||||
|
||||
**Downgrade to NBT (the proxy-critical bit):** to serve a 1.20.3 (765) client, ViaVersion converts the typed component map *back* into the old-style `tag` NBT compound. That entire reverse mapping lives in `rewriter/StructuredDataConverter.java` (a large per-component switch importing every `…item.data.*` class). The forward/back item handling is wired through `BlockItemPacketRewriter1_20_5` + `ComponentRewriter1_20_5`. Source: `v1_20_3to1_20_5/rewriter/StructuredDataConverter.java` (class at `:74`), `Protocol1_20_3To1_20_5.java:78,88`.
|
||||
|
||||
@@ -351,10 +351,11 @@ A 766 client will wait for `SELECT_KNOWN_PACKS` before finalising its registries
|
||||
|
||||
---
|
||||
|
||||
## VERIFY flags
|
||||
## Verification notes
|
||||
|
||||
- `<!-- VERIFY -->` Exact release dates for **1.20.1** (used 2023-06-12) and **1.20.6** (used 2024-04-29) were not fetched from the wiki in this pass — only the protocol-bumping releases' dates were confirmed from minecraft.wiki articles. Numbers (763 / 766 respectively) are confirmed from minecraft-data `version.json`.
|
||||
- The 1.20.5 structured-component **count (~60 keys)** is an approximation from reading the `onMappingDataLoaded()` filler chain (`Protocol1_20_3To1_20_5.java:282–302`); the precise canonical count per Mojang's registry is unconfirmed here.
|
||||
- **1.20.1 release date (2023-06-12):** CONFIRMED — minecraft.wiki/w/Java_Edition_1.20.1 infobox, fetched 2026-06-19. Protocol 763 confirmed from minecraft-data `version.json`.
|
||||
- **1.20.6 release date (2024-04-29):** CONFIRMED — minecraft.wiki/w/Java_Edition_1.20.6 infobox, fetched 2026-06-19. Protocol 766 confirmed from minecraft-data `version.json`.
|
||||
- **1.20.5 structured-component count (~60 keys):** The `onMappingDataLoaded()` filler chain in `Protocol1_20_3To1_20_5.java:282–302` makes 53 explicit `.add(StructuredDataKey.*)` calls, plus `.add(VersionedTypes.V1_20_5.structuredDataKeys().keys())` which adds 3 more (`container`, `chargedProjectiles`, `bundleContents` from `StructuredDataKeys1_20_5.java`) — total **56 keys** in ViaVersion's registry. The "~60" approximation is slightly high; corrected to 56. (Mojang's canonical count may differ if any keys are omitted from ViaVersion's tracking; the ViaVersion count is the best available source here.)
|
||||
|
||||
## Sources
|
||||
|
||||
|
||||
+3
-2
@@ -122,7 +122,7 @@ Relatively lightweight protocol bump — no new packet types, primarily field ch
|
||||
- **`LEVEL_PARTICLES`:** `always_show` boolean field added after `override_limiter`. VV writes `false` for it when translating down. [VV `Protocol1_21_2To1_21_4.java:registerPackets()` `replaceClientbound(LEVEL_PARTICLES)`]
|
||||
- **`PLAYER_INFO_UPDATE`:** `PROFILE_ACTIONS_ENUM` → `1_21_4` variant (adds "show hat" action). VV writes `true` by default. [VV `Protocol1_21_2To1_21_4.java:registerPackets()`]
|
||||
- **Item components:** `CUSTOM_MODEL_DATA` → `1_21_4` (format extended), `TRIM` → `1_21_4`.
|
||||
- **`PLAYER_LOADED` serverbound:** Added (0x2A in 1.21.5 but arrives at 768→769 boundary). <!-- VERIFY exact version introduced -->
|
||||
- **`PLAYER_LOADED` serverbound:** Added at protocol **769 (1.21.4)** — `ServerboundPackets1_21_4.java` includes it at 0x2A, and `EntityPacketRewriter1_21_4.java:63` cancels it downward (`protocol.cancelServerbound(ServerboundPackets1_21_4.PLAYER_LOADED)`), confirming 769 is the introduction boundary. It is not present in the 1.21.2 (768) serverbound enum (0x2A there is `RECIPE_BOOK_CHANGE_SETTINGS`). In 1.21.5 it shifts to 0x2A in the new numbering (`ServerboundPackets1_21_5.java:64`). Source: ViaVersion `v1_21_2to1_21_4/rewriter/EntityPacketRewriter1_21_4.java:63`, `v1_21_2to1_21_4/packet/ServerboundPackets1_21_4.java:64`, `v1_21to1_21_2/packet/ServerboundPackets1_21_2.java` (no PLAYER_LOADED entry).
|
||||
- VV does NOT add a `ChunkLoadTracker` for 1.21.4 clients — Mojang fixed the rendering bug in this release. [VV `Protocol1_21To1_21_2.java:init()` comment]
|
||||
|
||||
---
|
||||
@@ -263,7 +263,8 @@ All existing IDs shift up accordingly — packet count goes from 134 (0x85) in 7
|
||||
`DEBUG_SAMPLE_SUBSCRIPTION` serverbound changed: from a single `type: varint` to a list `count: varint` + per-entry `registry_id: varint`. VV maps the new `DEDICATED_SERVER_TICK_TIME` subscription (id=0) back to the old `TICK_TIME` type (0). [VV `Protocol1_21_7To1_21_9.java:registerServerbound(DEBUG_SAMPLE_SUBSCRIPTION)`]
|
||||
|
||||
#### `SET_DEFAULT_SPAWN_POSITION`
|
||||
<!-- VERIFY: field format change in 773 vs 772 — VV entity rewriter references this packet but full diff not extracted -->
|
||||
|
||||
In **773 (1.21.9)** this packet gained two new fields: a **dimension identifier** (string) prepended before the block position, and a **pitch float** appended after the yaw float. ViaVersion's handler reads `BLOCK_POSITION1_14`, gets the current dimension from `tracker(wrapper.user()).currentWorld()`, writes `GLOBAL_POSITION` (dimension string + block position), passthroughs the yaw float, then writes `pitch=0F`. Old format (≤ 772): `BlockPosition + float yaw`; new format (773+): `String dimension + BlockPosition + float yaw + float pitch`. Source: `v1_21_7to1_21_9/rewriter/EntityPacketRewriter1_21_9.java:80–90`; `GlobalBlockPositionType.java` (dimension written as string before position).
|
||||
|
||||
---
|
||||
|
||||
|
||||
+49
-22
@@ -12,27 +12,33 @@
|
||||
|---|---|---|---|
|
||||
| 1.7.2 | 4 | 2013-10-25 | — |
|
||||
| 1.7.3 | 4 | 2013-10-26 | yes, with 1.7.2 |
|
||||
| 1.7.4 | 4 | 2013-12-09 <!-- VERIFY exact date --> | yes, with 1.7.2–3 |
|
||||
| 1.7.5 | 4 | 2014-02-26 <!-- VERIFY exact date --> | yes, with 1.7.2–4 |
|
||||
| 1.7.4 | 4 | 2013-12-10 | yes, with 1.7.2–3 |
|
||||
| 1.7.5 | 4 | 2014-02-26 | yes, with 1.7.2–4 |
|
||||
| 1.7.6 | **5** | 2014-04-09 | **incompatible** with 1.7.2–5 |
|
||||
| 1.7.7 | **5** | 2014-04-10 <!-- VERIFY exact date --> | yes, with 1.7.6 |
|
||||
| 1.7.8 | **5** | 2014-06-16 <!-- VERIFY exact date --> | yes, with 1.7.6–7 |
|
||||
| 1.7.9 | **5** | 2014-06-16 <!-- VERIFY exact date --> | yes, with 1.7.6–8 |
|
||||
| 1.7.7 | **5** | 2014-04-09 | yes, with 1.7.6 |
|
||||
| 1.7.8 | **5** | 2014-04-11 | yes, with 1.7.6–7 |
|
||||
| 1.7.9 | **5** | 2014-04-14 | yes, with 1.7.6–8 |
|
||||
| 1.7.10 | **5** | 2014-06-26 | yes, with 1.7.6–9 |
|
||||
|
||||
Sources:
|
||||
- minecraft.wiki `/w/Java_Edition_1.7.2` (fetched 2026-06-19) — release date, protocol 4, Netty rewrite
|
||||
- minecraft.wiki `/w/Java_Edition_1.7.4` (fetched 2026-06-19) — release date 2013-12-10 (pre-release was 2013-12-09; full release differs)
|
||||
- minecraft.wiki `/w/Java_Edition_1.7.5` (fetched 2026-06-19) — release date 2014-02-26, protocol 4 confirmed
|
||||
- minecraft.wiki `/w/Java_Edition_1.7.6` (fetched 2026-06-19) — release date 2014-04-09, protocol 5 confirmed
|
||||
- minecraft.wiki `/w/Java_Edition_1.7.7` (fetched 2026-06-19) — release date 2014-04-09, protocol 5 confirmed
|
||||
- minecraft.wiki `/w/Java_Edition_1.7.8` (fetched 2026-06-19) — release date 2014-04-11, protocol 5 confirmed
|
||||
- minecraft.wiki `/w/Java_Edition_1.7.9` (fetched 2026-06-19) — release date 2014-04-14, protocol 5 confirmed
|
||||
- minecraft.wiki `/w/Java_Edition_1.7.10` (fetched 2026-06-19) — release date 2014-06-26, protocol 5, compatibility note
|
||||
- `/tmp/mcproto-refs/minecraft-data/data/pc/1.7/version.json` — `{"version":5,"minecraftVersion":"1.7.10","majorVersion":"1.7"}`
|
||||
|
||||
The protocol-version page on minecraft.wiki (fetched 2026-06-19) listed all of
|
||||
1.7.2–1.7.10 as protocol 4; the per-version pages for 1.7.6 and 1.7.10
|
||||
individually confirm protocol 5, and the minecraft-data canonical record for
|
||||
`1.7.10` is version 5. The per-version pages are the higher-fidelity source;
|
||||
<!-- VERIFY --> the exact boundary (whether 1.7.2–1.7.5 = 4 and 1.7.6–1.7.10 = 5
|
||||
is consistent with the protocol-version list being incomplete/erroneous for the
|
||||
1.7 range).
|
||||
`1.7.10` is version 5. The per-version pages are the higher-fidelity source.
|
||||
The split is confirmed: 1.7.2–1.7.5 = protocol 4; 1.7.6–1.7.10 = protocol 5.
|
||||
The protocol-version list page is incomplete/erroneous for the 1.7 range.
|
||||
(Sources: minecraft.wiki per-version articles for 1.7.6 and 1.7.10, fetched 2026-06-19;
|
||||
`minecraft-data/data/pc/1.7/version.json`.)
|
||||
|
||||
---
|
||||
|
||||
@@ -126,14 +132,22 @@ Key changes at the wire level:
|
||||
`packet_named_entity_spawn` (Play 0x0C S→C) already carried a `data` array of
|
||||
property `{name, value, signature}` triples in the minecraft-data 1.7 schema
|
||||
— this is the textures property bag that carries the signed skin URL.
|
||||
<!-- VERIFY --> whether this field was added in 1.7.2 or specifically in 1.7.6
|
||||
(it is present in the 1.7.10 protocol.json which covers protocol 5).
|
||||
<!-- UNCONFIRMED: the data[] property array is present in the 1.7.10 protocol.json
|
||||
(protocol 5) but minecraft-data has no separate schema for protocol 4 (1.7.2–1.7.5),
|
||||
so we cannot determine from local sources whether this field was present in 1.7.2
|
||||
or was added in 1.7.6. The signed-URL skin overhaul in 1.7.6 makes 1.7.6 the more
|
||||
likely introduction point, but no protocol-4 protocol.json exists to diff against. -->
|
||||
- **Name-change infrastructure**: Server-side preparation for player name
|
||||
changing (actual service launched 2015-02-04). No packet-schema change, but
|
||||
UUID-keyed identity was reinforced.
|
||||
- **Per-server resource pack option**: `packet_resource_pack_send` <!--
|
||||
VERIFY --> exact packet ID / whether this is a new Play packet in protocol 5 or
|
||||
re-uses an existing custom\_payload channel.
|
||||
- **Per-server resource pack option**: The 1.7.6 UI change ("per-server resource
|
||||
pack" option with prompt/enabled/disabled modes) was a client UI feature, not a
|
||||
new Play packet. `packet_resource_pack_send` does **not** appear in the 1.7
|
||||
protocol.json — it was added in 1.8 as Play CB 0x48. The 1.7.6 feature
|
||||
operated through the existing client options flow, not a new wire packet.
|
||||
(Source: `/tmp/mcproto-refs/minecraft-data/data/pc/1.7/protocol.json` play.toClient
|
||||
mapper — no resource_pack_send entry; 1.8 protocol.json play.toClient 0x48 =
|
||||
"resource_pack_send".)
|
||||
- The 1.7.6 client was incompatible with 1.7.2–1.7.5 servers (confirmed by
|
||||
minecraft.wiki 1.7.6; fetched 2026-06-19), making the protocol-5 boundary
|
||||
hard.
|
||||
@@ -179,8 +193,13 @@ No S→C packets in this state.
|
||||
Notes:
|
||||
- No Login Compression packet (0x03) — that is a 1.8 addition.
|
||||
- `publicKey` and `verifyToken` use **i16** (signed 16-bit) as the length
|
||||
prefix, not VarInt; this is a known 1.7 quirk that 1.8 also retains
|
||||
<!-- VERIFY --> exact format change in 1.8 if any.
|
||||
prefix, not VarInt. **1.8 changed both** to VarInt-prefixed buffers (both
|
||||
S→C Encryption Request and C→S Encryption Response / sharedSecret). This was
|
||||
confirmed to be a 1.8 change by comparing `packet_encryption_begin` in both
|
||||
`protocol.json` files: 1.7 uses `{"countType":"i16"}`, 1.8 uses
|
||||
`{"countType":"varint"}` for all four buffer fields across both directions.
|
||||
(Source: `minecraft-data/data/pc/1.7/protocol.json` and
|
||||
`minecraft-data/data/pc/1.8/protocol.json` login.toClient + login.toServer.)
|
||||
- `uuid` in Login Success is transmitted as a **string** (hyphenated UUID text),
|
||||
not as two i64 fields — that encoding came later.
|
||||
|
||||
@@ -325,8 +344,12 @@ Source: `protocol.json` `types.position_iii` / `position_isi` / `position_ibi`.
|
||||
The client-to-server Player Position packets include a `stance` field (f64)
|
||||
representing the player's eye height offset above their feet (typically `y + 1.62`).
|
||||
The server uses this for hitbox calculations. The `stance` field was **removed in
|
||||
1.8** when the server began computing it server-side.
|
||||
<!-- VERIFY --> exact removal version.
|
||||
1.8** when the server began computing it server-side. Confirmed: `packet_position`
|
||||
and `packet_position_look` in `minecraft-data/data/pc/1.7/protocol.json` contain
|
||||
`stance:f64`; the same packets in `data/pc/1.8/protocol.json` do not — the field
|
||||
is entirely absent. Removal version: 1.8 (protocol 47).
|
||||
(Source: `minecraft-data/data/pc/1.7/protocol.json` and `data/pc/1.8/protocol.json`
|
||||
play.toServer `packet_position` field lists.)
|
||||
|
||||
### Plugin Message channel data length
|
||||
In 1.7, `packet_custom_payload` (both directions) uses an **i16** length prefix
|
||||
@@ -420,12 +443,12 @@ detail.
|
||||
|---|---|---|
|
||||
| Framing | VarInt length + VarInt ID | Same in 1.8+ |
|
||||
| Compression | None | Login Compression added in 1.8 (0x03 Login packet) |
|
||||
| Encryption | RSA-1024 key exchange, AES/CFB8 shared secret, verifyToken — same mechanism as 1.8+ | i16 length prefix on `publicKey`/`verifyToken` buffers (vs VarInt in later versions <!-- VERIFY -->) |
|
||||
| Encryption | RSA-1024 key exchange, AES/CFB8 shared secret, verifyToken — same mechanism as 1.8+ | i16 length prefix on `publicKey`/`verifyToken` buffers; changed to VarInt in 1.8 (confirmed from `packet_encryption_begin` in both `protocol.json` files) |
|
||||
| Entity IDs in Play | Mix of i32 and VarInt (e.g. `entity_destroy` uses i32 array, `animation` uses VarInt) | Standardised to VarInt in 1.8 |
|
||||
| Position encoding | Three separate i32/i16/u8 fields | Packed 64-bit Position type added in 1.8 |
|
||||
| Slot NBT | `compressedNbt` (zlib-compressed) | Uncompressed NBT after 1.8 |
|
||||
| Player stance | Client sends `stance` (f64) in position packets | Removed in 1.8 |
|
||||
| Login Success UUID | String (hyphenated text) | Two i64 fields in 1.16+ <!-- VERIFY exact version --> |
|
||||
| Login Success UUID | String (hyphenated text) | Binary UUID (two i64 fields) from 1.16 (confirmed: `ClientboundBaseProtocol1_16.java` in ViaVersion overrides `passthroughUUID` to use `Types.UUID` instead of `Types.STRING`; `ClientboundBaseProtocol1_7.java` uses `Types.STRING`) |
|
||||
| Player List Item | Simple {name, online, ping} per-packet | Replaced with action-tagged packet in 1.8 |
|
||||
| Chunk format | zlib-compressed section bitmask + addBitMap; separate MapChunkBulk for multi-chunk | Restructured in 1.9 |
|
||||
|
||||
@@ -439,8 +462,12 @@ Velocity modern forwarding uses a **Login Plugin Request / Response** exchange i
|
||||
the Login state (added in 1.13). 1.7 clients do not support Login Plugin
|
||||
messages; a Velocity-in-modern-mode proxy cannot forward 1.7 clients without a
|
||||
ViaLegacy bridge that intercepts the Login Plugin exchange on behalf of the 1.7
|
||||
client. <!-- VERIFY --> exact Velocity behaviour when a 1.7 client hits a
|
||||
modern-forwarding backend.
|
||||
client. <!-- UNCONFIRMED: exact Velocity behaviour (disconnect vs handshake failure
|
||||
vs silent passthrough) when a 1.7 client hits modern-forwarding without ViaLegacy.
|
||||
ViaVersion source in the ref set does not include Velocity's login-plugin handler,
|
||||
and no Velocity source is present in /tmp/mcproto-refs/. Known to require ViaLegacy
|
||||
to intercept the Login Plugin exchange; what Velocity does without it is not
|
||||
verifiable from local refs. -->
|
||||
|
||||
---
|
||||
|
||||
|
||||
+9
-5
@@ -182,7 +182,7 @@ Both 1.7 and 1.8 use the same sentinel-terminated metadata loop structure:
|
||||
- End of stream signalled by byte `0x7F` (127).
|
||||
- Entry values by type: 0=i8, 1=i16, 2=i32, 3=f32, 4=string, 5=slot, 6={x:i32,y:i32,z:i32}, 7={pitch:f32,yaw:f32,roll:f32}.
|
||||
|
||||
The type table is identical in both versions (verified from `entityMetadataItem` in both `protocol.json` files). However, the set of actual metadata indices and their meanings changed for several entity types in 1.8 to accommodate new entity properties (guardians, rabbits, armor stands). <!-- VERIFY: specific index changes for new 1.8 entities -->
|
||||
The type table is identical in both versions (verified from `entityMetadataItem` in both `protocol.json` files). However, the set of actual metadata indices and their meanings changed for several entity types in 1.8 to accommodate new entity properties (guardians, rabbits, armor stands). <!-- UNCONFIRMED: per-entity metadata index assignments for new 1.8 entities are not enumerated in minecraft-data protocol.json (which only defines the loop encoding format, not per-entity index semantics); ViaVersion's EntityDataIndex1_9.java covers 1.8→1.9 index mapping but does not provide a standalone 1.8 per-entity index table. Wiki or source-level game data would be needed. -->
|
||||
|
||||
The container types `entityMetadata` and `entityMetadataItem` in 1.8's `protocol.json` are structurally identical to 1.7 — confirming that the metadata **encoding format** did not change between protocol 5 and 47; the changes were in which indices are used, not the framing.
|
||||
|
||||
@@ -212,7 +212,7 @@ The per-section data layout in 1.8 encodes blocks as **block-state IDs** — a s
|
||||
|
||||
The `addBitMap` field and the separate metadata nibble plane are gone entirely. Block state IDs are the canonical 1.8+ block representation: e.g., oak log facing north is a single integer distinct from oak log facing east, rather than `id=17, meta=4` vs `id=17, meta=0`.
|
||||
|
||||
The `Multi Block Change` record format reflects this too: in 1.7, each record packed `{metadata:4bits, blockId:12bits}` in one i16 plus a separate `y:u8` and `{x:4bits,z:4bits}` nibble. In 1.8, each record is `{horizontalPos:u8, y:u8, blockId:varint}` where `blockId` is the full block-state ID. <!-- VERIFY: exact 1.8 per-section binary layout (block-state 16-bit vs varint) from wiki source -->
|
||||
The `Multi Block Change` record format reflects this too: in 1.7, each record packed `{metadata:4bits, blockId:12bits}` in one i16 plus a separate `y:u8` and `{x:4bits,z:4bits}` nibble. In 1.8, each record is `{horizontalPos:u8, y:u8, blockId:varint}` where `blockId` is the full block-state ID (confirmed from `packet_multi_block_change` in `minecraft-data/data/pc/1.8/protocol.json` — `{"countType":"varint"}` for blockId). For chunk section data (per-block encoding inside the `chunkData` buffer), the 1.8 format stores block-state IDs as 16-bit little-endian shorts per block (4096 × 2 bytes per section); this is not expressible in the minecraft-data schema level and the local ref set contains no authoritative source for the per-section layout. <!-- UNCONFIRMED: chunk section per-block encoding (16-bit shorts vs other) — no local source; web.archive.org fetch unavailable. -->
|
||||
|
||||
---
|
||||
|
||||
@@ -365,11 +365,11 @@ Source: `minecraft-data/data/pc/1.8/protocol.json` packet mapper sections. ViaVe
|
||||
|
||||
**Compression negotiation at the proxy.** A proxy operating in front of a 1.8+ server must intercept `Set Compression` (login 0x03) from the backend and decide whether to relay, modify, or suppress it. The compression threshold may differ between the proxy's own connection to the client and the proxy-to-server leg. BungeeCord and Velocity both intercept this packet and re-issue their own `Set Compression` to the client with their own threshold, then maintain separate compression state for each half of the connection.
|
||||
|
||||
**Position type translation.** Any proxy accepting 1.7 clients and forwarding to a 1.8+ server must translate between the old triple-i32/i16 position types and the new packed `i64` `position` type for every block-coordinate field (spawn_position, bed, block_change, block_action, block_break_animation, update_sign, tile_entity_data, open_sign_entity, world_event, and on the serverbound side: block_dig, block_place, update_sign). <!-- VERIFY: completeness of this list against actual ViaLegacy implementation -->
|
||||
**Position type translation.** Any proxy accepting 1.7 clients and forwarding to a 1.8+ server must translate between the old triple-i32/i16 position types and the new packed `i64` `position` type for every block-coordinate field (spawn_position, bed, block_change, block_action, block_break_animation, update_sign, tile_entity_data, open_sign_entity, world_event, and on the serverbound side: block_dig, block_place, update_sign). <!-- UNCONFIRMED: completeness of this list against actual ViaLegacy implementation — ViaLegacy source is not present in the ref set (/tmp/mcproto-refs/ contains only ViaVersion which handles 1.8+). The list was derived from the protocol.json diff of all fields using position_iii/position_isi/position_ibi types, which is likely complete but not cross-checked against ViaLegacy's actual packet handlers. -->
|
||||
|
||||
**block_change metadata removal.** A 1.7-to-1.8 translator must combine the 1.7 `{type:varint, metadata:u8}` pair into a single 1.8 block-state VarInt on `block_change`, and split in the reverse direction.
|
||||
|
||||
**Stance removal.** The 1.7 serverbound `position` packet had a `stance:f64` field (eye-height offset for collision) that was removed in 1.8. A proxy bridging 1.7→1.8 must strip this field; a 1.8→1.7 bridge must synthesise it (typically `y + 1.62`). <!-- VERIFY: exact stance calculation -->
|
||||
**Stance removal.** The 1.7 serverbound `position` packet had a `stance:f64` field (eye-height offset for collision) that was removed in 1.8 (confirmed from protocol.json diff). A proxy bridging 1.7→1.8 must strip this field; a 1.8→1.7 bridge must synthesise it (commonly cited as `y + 1.62` for the default player eye height). <!-- UNCONFIRMED: the `y + 1.62` synthesis constant is widely cited in community protocol documentation but is not present in the ViaVersion source set (ViaVersion handles 1.8+, not 1.7↔1.8 bridging); ViaLegacy source would be authoritative but is not available in the ref set. -->
|
||||
|
||||
**Player Info restructure.** The flat single-player `player_info` from 1.7 (`playerName, online, ping`) was replaced in 1.8 with the action-based multi-player structure. Proxies doing tab-list passthrough must understand the 1.8 structure.
|
||||
|
||||
@@ -381,7 +381,11 @@ Source: `minecraft-data/data/pc/1.8/protocol.json` packet mapper sections. ViaVe
|
||||
|
||||
All 1.8.x patches share **protocol 47**. Patch releases addressed server-side exploits (combat, enchantment mechanics, item duplication), server crash vectors, and connectivity bugs but made **no wire-format changes**. A 1.8 client connects to a 1.8.9 server without negotiation issues, and vice versa.
|
||||
|
||||
<!-- VERIFY: confirm no sub-version made any packet format change (all share protocol 47 per minecraft-data version.json which keys on majorVersion "1.8") -->
|
||||
Confirmed: all 1.8.x releases share protocol 47. The minecraft-data `version.json`
|
||||
for the 1.8 majorVersion slot records `{"version":47,"minecraftVersion":"1.8.8"}`,
|
||||
and the minecraft-data schema keys the entire 1.8 family to a single `protocol.json`
|
||||
with no sub-version splits — consistent with zero wire-format changes across the
|
||||
patch line. (Source: `minecraft-data/data/pc/1.8/version.json`.)
|
||||
|
||||
---
|
||||
|
||||
|
||||
+8
-2
@@ -66,7 +66,7 @@ The table below lists every 1.8 packet by name, its 1.8 ID, and what happened to
|
||||
| `entity_teleport` | 0x18 | `entity_teleport` | 0x4A | renumbered; position changed from Int×(1/32) to Double; +on-ground Boolean |
|
||||
| `entity_head_rotation` | 0x19 | `entity_head_rotation` | 0x34 | renumbered |
|
||||
| `entity_status` | 0x1A | `entity_status` | 0x1B | renumbered |
|
||||
| `attach_entity` | 0x1B | `attach_entity` | 0x3A | renumbered; leash Boolean field removed (1.9 uses `set_passengers` for riding) <!-- VERIFY: leash field drop --> |
|
||||
| `attach_entity` | 0x1B | `attach_entity` | 0x3A | renumbered; leash Boolean field removed in 1.9 (1.7/1.8 had `leash:bool`; 1.9 `attach_entity` has only `entityId:i32` + `vehicleId:i32`); riding now handled by `set_passengers` (0x40). (Confirmed from `packet_attach_entity` in `minecraft-data/data/pc/1.8/protocol.json` vs `data/pc/1.9/protocol.json`.) |
|
||||
| `entity_metadata` | 0x1C | `entity_metadata` | 0x39 | renumbered; metadata format revised (new EntityDataTypes1_9) |
|
||||
| `entity_effect` | 0x1D | `entity_effect` | 0x4C | renumbered |
|
||||
| `remove_entity_effect` | 0x1E | `remove_entity_effect` | 0x31 | renumbered |
|
||||
@@ -216,7 +216,13 @@ The 1.8 `map_chunk_bulk` (0x26) packet is gone; all chunk data is sent as indivi
|
||||
- Sections are length-prefixed in a single VAR_INT-prefixed byte array.
|
||||
- Block light and sky light are appended per section directly after palette+data.
|
||||
- Biome array (256 bytes) follows all sections for full-chunk packets.
|
||||
- No embedded block-entity NBT (that arrives in a separate `tile_entity_data` 0x09 packet or via `FakeTileEntities` during translation). <!-- VERIFY: exact 1.9 wire layout vs wiki -->
|
||||
- No embedded block-entity NBT (confirmed: `packet_map_chunk` in
|
||||
`minecraft-data/data/pc/1.9/protocol.json` has fields `x, z, groundUp, bitMap,
|
||||
chunkData` only — no `blockEntities` array; that field was added in 1.9.4 /
|
||||
protocol 110 and is present in `data/pc/1.9.4/protocol.json`). Block entity
|
||||
data arrives via separate `tile_entity_data` (0x09) packets or is synthesised
|
||||
by ViaVersion's `FakeTileEntities` when translating 1.9 chunks for 1.9.3+
|
||||
clients.
|
||||
|
||||
Source: `ViaVersion/api/src/main/java/com/viaversion/viaversion/api/type/types/chunk/ChunkType1_9_1.java`.
|
||||
|
||||
|
||||
+11
-11
@@ -3,11 +3,11 @@
|
||||
| Version | Protocol | Data Version | Release Date |
|
||||
|---|---|---|---|
|
||||
| 26.1 | 775 | 4786 | 2026-03-24 |
|
||||
| 26.1.1 | 775 | 4788 | <!-- VERIFY exact date --> |
|
||||
| 26.1.2 | 775 | 4790 | <!-- VERIFY exact date --> |
|
||||
| 26.1.1 | 775 | 4788 | 2026-04-01 |
|
||||
| 26.1.2 | 775 | 4790 | 2026-04-09 |
|
||||
| 26.2 | 776 | 4903 | 2026-06-16 |
|
||||
|
||||
Sources: minecraft.wiki/w/Java_Edition_26.1 (fetched 2026-06-19), minecraft.wiki/w/Java_Edition_26.2 (fetched 2026-06-19), minecraft-data `protocolVersions.json` (`/tmp/mcproto-refs/minecraft-data/data/pc/common/protocolVersions.json`), ViaVersion `ProtocolVersion.java:96` (`/tmp/mcproto-refs/ViaVersion`).
|
||||
Sources: minecraft.wiki/w/Java_Edition_26.1 (fetched 2026-06-19), minecraft.wiki/w/Java_Edition_26.1.1 (fetched 2026-06-19), minecraft.wiki/w/Java_Edition_26.1.2 (fetched 2026-06-19), minecraft.wiki/w/Java_Edition_26.2 (fetched 2026-06-19), minecraft-data `protocolVersions.json` (`/tmp/mcproto-refs/minecraft-data/data/pc/common/protocolVersions.json`), ViaVersion `ProtocolVersion.java:96` (`/tmp/mcproto-refs/ViaVersion`).
|
||||
|
||||
---
|
||||
|
||||
@@ -225,7 +225,7 @@ The `dimension_type` registry entry gains `has_ender_dragon_fight` (computed fro
|
||||
**Pack formats:** Resource pack 88.0, Data pack 107.1.
|
||||
**Minimum Java:** Java SE 25 (unchanged).
|
||||
|
||||
> **Source note:** The ViaVersion clone (`/tmp/mcproto-refs/ViaVersion`) predates 26.2 — no `v26_1to26_2` package exists in the local ref. Protocol 776 is confirmed from minecraft-data `protocolVersions.json` (entry `{'minecraftVersion': '26.2', 'version': 776, 'dataVersion': 4903}`) and minecraft.wiki/w/Java_Edition_26.2 (fetched 2026-06-19). The packet-level diff below is from wiki sources only. <!-- VERIFY once ViaVersion ships v26_1to26_2 -->
|
||||
> **Source note:** The ViaVersion clone (`/tmp/mcproto-refs/ViaVersion`) predates 26.2 — no `v26_1to26_2` package exists in the local ref. Protocol 776 is confirmed from minecraft-data `protocolVersions.json` (entry `{'minecraftVersion': '26.2', 'version': 776, 'dataVersion': 4903}`) and minecraft.wiki/w/Java_Edition_26.2 (fetched 2026-06-19). The packet-level diff below is from wiki sources only. All 776 protocol claims in this section remain wiki-sourced and should be re-verified against ViaVersion `v26_1to26_2` once that package ships.
|
||||
|
||||
### Headline gameplay changes (mc-wiki, fetched 2026-06-19)
|
||||
|
||||
@@ -234,12 +234,12 @@ The `dimension_type` registry entry gains `has_ender_dragon_fight` (computed fro
|
||||
- **Sulfur Cube mob**: passive mob with 12 archetypes (`regular`, `bouncy`, `slow_bouncy`, `fast_flat`, `slow_flat`, `light`, `fast_sliding`, `slow_sliding`, `high_resistance`, `sticky`, `explosive`, `hot`). Physics properties driven by absorbed blocks; can absorb TNT to become explosive.
|
||||
- **Music Disc "Bounce"**: by fingerspit.
|
||||
- **`/unpublish` command**: disconnects the integrated (LAN) server.
|
||||
- **Friends List**: in-game friend request management system. <!-- VERIFY wire-level packet -->
|
||||
- **Friends List**: in-game friend request management system. <!-- UNCONFIRMED: wiki describes the feature as integrating with existing chat/presence mechanisms but does not document new packet types for it; no ViaVersion source available for 776 to confirm wire-level implementation -->
|
||||
- **Vulkan 1.2 renderer** (experimental): optional renderer with automatic OpenGL fallback.
|
||||
|
||||
### Protocol changes in 776
|
||||
|
||||
Sources: minecraft.wiki/w/Java_Edition_26.2 (fetched 2026-06-19). No ViaVersion source available for this bump. All protocol claims in this section are wiki-only. <!-- VERIFY -->
|
||||
Sources: minecraft.wiki/w/Java_Edition_26.2 (fetched 2026-06-19). No ViaVersion source available for this bump. All protocol claims in this section are wiki-only and should be reverified against ViaVersion `v26_1to26_2` once available.
|
||||
|
||||
#### New entity attributes
|
||||
|
||||
@@ -267,19 +267,19 @@ Five new entity attributes registered server-side and sent in `UPDATE_ATTRIBUTES
|
||||
|
||||
#### World generation feature renames
|
||||
|
||||
`pointed_dripstone` feature type renamed to `speleothem`; `dripstone_cluster` renamed to `speleothem_cluster`. Impacts `LEVEL_CHUNK_WITH_LIGHT` structural data for affected chunk regions. <!-- VERIFY if this touches the wire format or only server-side gen -->
|
||||
`pointed_dripstone` feature type renamed to `speleothem`; `dripstone_cluster` renamed to `speleothem_cluster`. <!-- UNCONFIRMED: wiki documents these as world-generation feature-type renames; whether they affect any wire-format fields (e.g. feature-type IDs embedded in chunk data) cannot be confirmed from wiki or ViaVersion source alone — likely server-side gen only, but ViaVersion v26_1to26_2 source needed to verify -->
|
||||
|
||||
#### New density function
|
||||
|
||||
`minecraft:interval_select`: threshold-based density function selector. Server-side only (world generation); not directly in the play protocol. <!-- VERIFY -->
|
||||
`minecraft:interval_select`: threshold-based density function selector. Server-side only (world generation); not directly in the play protocol. <!-- UNCONFIRMED: described as a worldgen density function on the wiki; no evidence of wire presence, but cannot be definitively excluded without ViaVersion source -->
|
||||
|
||||
#### Predicate restructuring
|
||||
|
||||
Entity predicate `type` field renamed to `minecraft:entity_type`; new `minecraft:entity_tags` sub-predicate. Affects datapack commands and any packets that embed predicates (e.g. `COMMANDS` argument types). <!-- VERIFY exact packet impact -->
|
||||
Entity predicate `type` field renamed to `minecraft:entity_type`; new `minecraft:entity_tags` sub-predicate. Wiki confirms the predicate restructuring but does not specify which packets carry the changed predicate format. <!-- UNCONFIRMED: packet impact (e.g. whether `COMMANDS` argument node serialization changed) not verifiable from wiki alone; ViaVersion v26_1to26_2 source required -->
|
||||
|
||||
#### Chunk section changes
|
||||
|
||||
<!-- VERIFY: unknown whether 26.2 changes the chunk section format vs 26.1. The ViaVersion source is absent; assume format is identical to 26.1 (non-air + fluid count shorts + block/biome palettes) unless wiki or ViaVersion indicates otherwise. -->
|
||||
<!-- UNCONFIRMED: wiki does not document any chunk section wire format change in 26.2; format is assumed identical to 26.1 (non-air-block count short + fluid count short + block palette + biome palette). Cannot confirm without ViaVersion v26_1to26_2 source or packet capture. -->
|
||||
|
||||
#### Particle additions
|
||||
|
||||
@@ -332,7 +332,7 @@ The ViaVersion ref predates 26.2. Expected translation requirements (from wiki a
|
||||
- New game event `bounce` can be suppressed without client-visible impact.
|
||||
- Entity predicate restructuring may affect `COMMANDS` packet argument types.
|
||||
|
||||
<!-- VERIFY all 776 proxy notes once ViaVersion v26_1to26_2 ships -->
|
||||
All items above are derived from wiki analysis only; reverify against ViaVersion `v26_1to26_2` once that package ships.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user