gimpansor_worldgen_1.16.2
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
gimpansor_worldgen_1.16.2 [2020/08/29 19:53] – created gimpansor | gimpansor_worldgen_1.16.2 [2020/08/30 10:19] (current) – gimpansor | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | The following applies to 1.16.2 at the time this is written. | ||
+ | |||
====== Changes from 1.16.1 ====== | ====== Changes from 1.16.1 ====== | ||
* Biomes have become immutable data classes | * Biomes have become immutable data classes | ||
+ | * Instead of using Biome objects, you now have to use '' | ||
* 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. | * 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< | + | * What you can do instead is maintain an '' |
- | * 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 | + | * The key of a biome must be obtained via the '' |
- | * Instead of using Biome objects, you now have to use RegistryKey< | + | * '' |
- | * FabricBiomes# | + | * Parent Biomes are gone and now hardcoded in '' |
- | * Parent Biomes are gone and now hardcoded in AddHillsLayer# | + | |
+ | ===== Worldgen Registries ===== | ||
+ | |||
+ | The following diagram shows various objects that participate in defining world generation, and where they are registered/ | ||
+ | |||
+ | The general rule of thumb is that '' | ||
+ | |||
+ | As an example: | ||
+ | |||
+ | * Vanilla registers an instance of the class '' | ||
+ | * Vanilla then registers 21 configured features in '' | ||
+ | |||
+ | For use in an actual world, all data objects from '' | ||
+ | |||
+ | {{: | ||
+ | |||
+ | ===== 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 '' | ||
+ | - 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 | ||
gimpansor_worldgen_1.16.2.1598730802.txt.gz · Last modified: 2020/08/29 19:53 by gimpansor