This is an old revision of the document!

Changes from 1.16.1

Biomes have become immutable data classes
Instead of using Biome objects, you now have to use RegistryKey<Biome> for most operations, since it will be stable even across world and datapack reloads
- This means that any custom data you previously attached to your Biome subclass can no longer be attached directly to Biome objects, since Vanilla will serialize and deserialize Biome objects to copy them using their codecs, you could in theory attach custom data by extending the Codec, but this would mean this data would be attached to every Biome.
- What you can do instead is maintain an IdentityHashMap<RegistryKey<Biome>, YourCustomData> in your mod, and query the custom data based on the biome's key.
- The key of a biome must be obtained via the DynamicRegistryManager of the current world, ClientWorld and ServerWorld offer a convenience method for this called method_31081 (currently unnamed), which retrieves the key of the biome at a given BlockPos, although you can also do this yourself via world.getRegistryManager().get(Registry.BIOME_KEY).getKey(<the_biome_variable>).
FabricBiomes#addSpawnBiome was removed, since this is now a property that can be set via Vanilla's Biome.Builder (see SpawnSettings.Builder#playerSpawnFriendly).
Parent Biomes are gone and now hardcoded in AddHillsLayer#field_26727 based on their raw ids. Since the mapping is from unmodified biome → modified biome, there's no real point in exposing this to mods, because there can only be _one_ modified biome for each unmodified one.