Fabric Wiki

User Tools

Site Tools

Trace:
gimpansor_worldgen_1.16.2

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
gimpansor_worldgen_1.16.2 [2020/08/30 00:26] – gimpansorgimpansor_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 ======
  
Line 9: Line 11:
   * 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.   * 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.
  
-===== Worldgen Registered Objects =====+===== Worldgen Registries =====
  
 The following diagram shows various objects that participate in defining world generation, and where they are registered/defined. The following diagram shows various objects that participate in defining world generation, and where they are registered/defined.
Line 15: Line 17:
 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. 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.
  
-To illustrate this: +As an example:
  
-* Vanilla registers an instance of the class ''OreFeature'' under the ID ''minecraft:ore'' in ''Registry.Feature''. +  * Vanilla registers an instance of the class ''OreFeature'' under the ID ''minecraft:ore'' in ''Registry.Feature''. 
-* Vanilla then registers 21 configured features in ''BuiltInRegistry.CONFIGURED_FEATURE'' that reference ''minecraft:ore'', and configure it differently (for example ''minecraft:ore_iron'' to place iron ore)+  * Vanilla then registers 21 configured features in ''BuiltInRegistries.CONFIGURED_FEATURE'' that reference ''minecraft:ore'', and configure it differently (for example ''minecraft:ore_iron'' to 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.
  
 {{:tutorial:worldgen_uml.png|}} {{:tutorial:worldgen_uml.png|}}
  
 +===== 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 ''Registry'' or 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
  
gimpansor_worldgen_1.16.2.1598747219.txt.gz · Last modified: 2020/08/30 00:26 by gimpansor