Java 1.21.3 Support

[GroobleDierne]

Fixes #929, #928

TODO:

• [x] Protocol
  • [x] packet_recipe_book_add
  • [x] packet_craft_recipe_response should be similar to previous one
  • [x] Fix Slot & SlotComponent types
  • [x] packet_declare_recipes
• [x] entities.json (waiting on minecraft-data-generator)
• [x] tints.json is likely incorrect

[rom1504]

Can you point missing files to 1.21.1 for now

[rom1504]

Let's open an nmp and mineflayer PRs using this

[rom1504]

nmp and mineflayer PRs

https://github.com/PrismarineJS/node-minecraft-protocol/pull/1347 https://github.com/PrismarineJS/mineflayer/pull/3489

fail due to wrong protocol as expected

[rom1504]

see https://github.com/extremeheat/extracted_minecraft_data/pulls as a source of info for the protocol

[rom1504]

https://github.com/extremeheat/extracted_minecraft_data/pull/13.patch

[GroobleDierne]

see https://github.com/extremeheat/extracted_minecraft_data/pulls as a source of info for the protocol

I'm using yarn because some files failed to decompile in extremheat's repository. Anyway, I'll stop here for tonight.

[rom1504]

https://github.com/PrismarineJS/node-minecraft-protocol/actions/runs/11543601911/job/32356083688 now passing but still some packet errors

[GroobleDierne]

https://github.com/PrismarineJS/node-minecraft-protocol/actions/runs/11543601911/job/32356083688 now passing but still some packet errors

I still need to implement one or two server-bound packets and the Slot type is messed up which causes quite a lot of packets to throw errors sometimes. I'm also stuck with the unlock_recipes packet, @extremeheat could you take a look at it?

[rom1504]

https://github.dev/extremeheat/extracted_minecraft_data/pull/15 can help

[extremeheat]

I did some work on the protocol, still some work to do:

• Recipe changes (recipe_book_add/remove/etc.) not yet handled
• SlotComponent type needs fixes, likely back to 1.20.5
• Backport some fixes to 1.20.5
• Added new registryEntryHolder and registryEntryHolderSet types to correspond to the Holder and HolderSet types inside minecraft (ref) to replace usage of the arrayWithLengthOffset type
  • holderSet work by writing a varint to the stream, n, and 0 means "read one [string] entry" and non-zero n, means read an array of 1+n entries of data from the stream
  • holder work by writing a varint to the stream, n, and 0 means "read one [varint] entry" set to n+1 and non-zero means read an array of n entries of data from the stream
  • usage example (not yet implemented) to write a varint, n, and then either a varint or EntityMetadataWolfVariant:

    if wolf_variant: ["registryEntryHolder", {
    "base": { name: "variantId", type: "varint" },
    "otherwise": { name: "variantData", type: "EntityMetadataWolfVariant" }
    }]

• using the bitflags type implemented in bedrock-protocol to make the flags easier than tracking individual bits

  ["bitflags", {
    "type": "u32",
    "flags": ["x", "y", "z", "yaw", "pitch", "dx", "dy", "dz", "yawDelta"]
  }]

[MrBruz]

@GroobleDierne For 'registryDataIsMandatory', 'version' needs to be changed to 'versions'

[GroobleDierne]

@GroobleDierne For 'registryDataIsMandatory', 'version' needs to be changed to 'versions'

Thx

[GroobleDierne]

Now only recipes related packets seem to be missing for protocol support

[GroobleDierne]

I'll try debugging them later today

[rom1504]

Hey, please remove registries.json file from this PR and put it in its own PR. I think we need a lot more work on it to include in mc data

[rom1504]

Also let's review https://github.com/GroobleDierne/minecraft-data/pull/2

[GroobleDierne]

Hey, please remove registries.json file from this PR and put it in its own PR. I think we need a lot more work on it to include in mc data

I realised that if the client and server share the same minecraft:core pack version (communicated through SelectKnowPacks), the server only needs to send every key from every registries. So my current plan is to implement this in p-registry, as for most registries, mc-data already has the data to generate the keys. In the long term, we must add some fields to the existing schemas and create new ones too.

[GroobleDierne]

After a looooooot of debugging, I figured out the bug was just in front of my eyes in the registryHolderSet decoding code and not in the protocol definition :face_holding_back_tears: