Custom Biome and Dimension API

[Xernium]

What changed?

Since the early 1.16 snapshots the client has had limited capabilites to interface with server-defined custom dimensions and later 1.16 releases also custom biomes.
Now 1.17 added datapacks that allow users to customize the world generation, and it's only fitting that this functionality is also provided through the API.

What can these do?

The client has a dimension-type and biome-type registry that can be customized by the server without the need of mods.
This allows the server to customize the way the client interacts with the world and how it behaves.

Examples

• A nether without the hell world fog
• A fluid dimension without a water level
• A world with a different world height range

Technical stuff:

The Dimension registry that is sent to the client has this format
https://github.com/VelocityPowered/Velocity/blob/dev/1.1.0/proxy/src/main/java/com/velocitypowered/proxy/connection/registry/DimensionData.java
A full dimension registry dump from 1.16 can be found here: https://paste.gg/p/KennyTV/ad46ef552c6443cc808385f060564550 cc Kenny

Please note:

• This data is sent to the client upon Login and can not be changed or updated until the client re-joins the server or gets reset*
• The client does not require the vanilla biomes or dimension types to function
• The client requires at least one valid dimension type and one valid biome type

(* This is likely to break proxies like Bungeecord or Velocity)
The server also provides a list of world names to the client, and together with a few additional attributes and a dimension type as defined before they make up a client's perception of the world.

This additional information can be seen here:
https://github.com/VelocityPowered/Velocity/blob/dev/1.1.0/proxy/src/main/java/com/velocitypowered/proxy/connection/registry/DimensionInfo.java

What do we need?

• Internal changes to fit this on network-level
• API to allow usage of the new options from both biome and dimension types
• API to allow custom world profiles as seen in datapacks
• A persistent data tag for worlds to store extended generation information
• Modifications to the world/dimension loader found in Spigot

Gotchas

• Since Spigot/Bukkit does not interface with this logic it will be hard to get to work without breaking functionality.
• A lot of internal functionality will need to be exposed
• We need a new extended data storage to keep the additional world info
• Take it with a grain of salt that the API will need to either have special support form proxies to reload clients or it will have to have users re-log before working correctly

[JakeNijssen]

This would require the nuking of the Biome enums, which I'm 10000% for. But it would also break compatibility with spigot. So I assume this will be done once Paper hardforks from spigot.

[electronicboy]

Ideal goal is to maintain this API at the side of the current one for a deprecation period, custom biomes is 100% something which needs to be done, and I'd much rather provide things time to migrate vs just a hard break one random day

I think that a big issue here is that it relies on a proper lifecycle to work, and would screw with stuff like reload, so there are some errs there, but I think that if we ever want to expose modern MC features to plugins

[toddharrison]

In addition to an API for handling custom biomes and dimensions, could we get paper to load dimensions specified in datapacks rather than ignoring them? Currently having to rely on plugins, like https://www.spigotmc.org/resources/1-16-custom-dimensions.83731/, but this hard breaks every update.

[Xernium]

@toddharrison this would fall under "A persistent data tag for worlds to store extended generation information" and "Modifications to the world/dimension loader found in Spigot"