The following applies to 1.16.2 at the time this is written.
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
DynamicRegistryManagerof the current world,
ServerWorldoffer 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
FabricBiomes#addSpawnBiomewas removed, since this is now a property that can be set via Vanilla's
- Parent Biomes are gone and now hardcoded in
AddHillsLayer#field_26727based 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.
The following diagram shows various objects that participate in defining world generation, and where they are registered/defined.
The general rule of thumb is that
Registry will contain objects that contain some form of custom code, while BuiltInRegistry contains built-in data objects that mostly reference code objects from an associate Registry by ID and sometimes add configuration data.
As an example:
- Vanilla registers an instance of the class
OreFeatureunder the ID
- Vanilla then registers 21 configured features in
minecraft:ore, and configure it differently (for example
minecraft:ore_ironto place iron ore)
For use in an actual world, all data objects from
BuiltInRegistries will be copied by value into a new
DynamicRegistryManager and may be overridden by JSON files in enabled data packs.
Registering Custom Worldgen
You should register your custom worldgen in the following order in your mod initializer:
- Register all of your custom code (feature, structure feature, etc.) into
Registryor using a specific API (i.e. see fabric-api for structures)
- Register all of your data such that referenced code or data is already registered
- Register configured features and configured structures before using them in biomes for example
- Use the Fabric biome API to insert your custom biomes into vanilla generation of the overworld, nether and the end as needed
- Register your custom configured features and structures for insertion into other biomes using the Fabric biome API