1.20.3

[zml2008]

This is a branch to gather work on supporting features and representation changes from Minecraft 1.20.3.

Relevant changelogs:

• 23w40a
• 23w42a

[zml2008]

So, my current thought for handling version differences is, we should have a 'feature flag' system, where things like 'emit legacy hover event' or 'emit uuid as ints' vs 'emit uuid as string' are toggleable options. We'd need to produce presets for compatibility with different game versions, plus probably a 'latest' and 'most compatible' levels.

Should this be game versions? Then how do we handle snapshots?

Alternately, we could mark these revisions by:

• datapack versions
• protocol versions
• data versions

Thoughts on what makes most sense?

[KingOfSquares]

So, my current thought for handling version differences is, we should have a 'feature flag' system, where things like 'emit legacy hover event' or 'emit uuid as ints' vs 'emit uuid as string' are toggleable options. We'd need to produce presets for compatibility with different game versions, plus probably a 'latest' and 'most compatible' levels.

Should this be game versions? Then how do we handle snapshots?

Alternately, we could mark these revisions by:

• datapack versions
• protocol versions
• data versions

Thoughts on what makes most sense?

I think using the protocol version is a good idea, seems like the most precise number and easiest to map to any point in releases/snapshots etc.. To my knowledge Bedrock uses the same system right(for protocol versions)? In case the bedrock serialiser or other bedrock specific stuff ever makes it in here

[zml2008]

We still need to implement:

• [ ] handling for the type field
• [ ] NBT component serialization (or DFU integration)
• [ ] matching the strictness of Vanilla serialization

but I think it's worth merging this as-is just to have published snapshots that others can depend on.