feather-rs / feather

A Minecraft server implementation in Rust
Apache License 2.0
2.58k stars 142 forks source link

Update to 1.18 #514

Open Iaiao opened 2 years ago

Iaiao commented 2 years ago

Update to 1.18

Status

Description

This PR adds 1.18 (and 1.18.1) support, multiworld and multidimension handling (not fully implemented and tested because we don't have portals yet, but changing EntityDimension component should work) as entities with components Dimensions, WorldName, and WorldPath, whede Dimensions is just a Vec<Dimension>, and Dimension is like old World that contains chunks, blocks, etc., full rewrite of generators in rust (except for blockstate generator, it was already written in rust), moved feather-blocks to libcraft-blocks because those were just different implementations of one thing, refactors biome logic, now there's a Arc<BiomeList> resource that is initialized at startup from worldgen json files extracted from vanilla server (probably should be changed to Rc<BiomeList>) that maps numerical IDs to biome identifiers and other information (temperature, particles, music, etc.), implements anvil format version 2865, also implements global palette serialiation/deserialization (#445), creates constants/ directory with to easily update to newer minecraft versions (changes version strings in ping packet, brand packet, protocol version, anvil version, data generators version, etc.), and adds support for varying height and negative y coordinate. Information about dimension height is taken from .json file of that dimension. Chunk-relative coordinates start with y=0, world-relative coordinates start with y=<min y>. Readable trait for Chunk Data and Chunk Light packets is currently not fully implemented because it's up to client to know how many chunk sections does the packet contain. Also fixes a few bugs and typos that I encountered during development.

What is left:

Good luck reviewing >100,000 lines of diff :)

Related issues

Closes #505 Closes #459 Fixes #445

Checklist

Defman commented 2 years ago

What's the difference between world and dimension?

Iaiao commented 2 years ago

In vanilla, each world has 3 dimensions: Overworld, Nether and The End. There are plugins that manage multiple worlds on a single spigot server, and they're popular, then why not to add it with built-in support? Also, I thought that the client has support for servers with multiple worlds because the Respawn and JoinGame packets had "world_name" and "dimension_codec" fields, and a note "is world_name resolving the same-dimension issue?", but it turned out that they both mean dimensions.

Defman commented 2 years ago

In vanilla, each world has 3 dimensions: Overworld, Nether and The End. There are plugins that manage multiple worlds on a single spigot server, and they're popular, then why not to add it with built-in support? Also, I thought that the client has support for servers with multiple worlds because the Respawn and JoinGame packets had "world_name" and "dimension_codec" fields, and a note "is world_name resolving the same-dimension issue?", but it turned out that they both mean dimensions.

Can we not just treat each dimension as a separate world, why do we need to group dimensions into worlds?

Schuwi commented 2 years ago

Can we not just treat each dimension as a separate world, why do we need to group dimensions into worlds?

If you enter a nether portal it has to know which dimension to send you to for example. How would it know which nether to send you to without grouping into worlds?

Plecra commented 2 years ago

That's a relationship between two dimensions, it doesn't need to be represented as a hierarchy. Any dimension that has a PortalDestination(WorldId) component could handle it without all the extra structure.

comblock commented 2 years ago

Any update on this? Also, how does the 1.19 release impact this pull request?

Supermath101 commented 2 years ago

This is amazing, but maybe next time break it into a few smaller and easier to manage PRs.

Or, you could follow this guide and split the main commit into a bunch of smaller commits. That way you don't need to manage a dozen or so PRs, but still enable reviewers to do a git diff for each segment of the overall changes.