User Tools

Site Tools


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
Next revisionBoth sides next revision
gimpansor_worldgen_1.16.2 [2020/08/29 19:56] gimpansorgimpansor_worldgen_1.16.2 [2020/08/30 00:29] 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 RegistryKey<Biome> for most operations, since it will be stable even across world and datapack reloads+  * 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.     * 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.  +    * 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>)''+    * 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). +  * ''FabricBiomes#addSpawnBiome'' was removed, since this is now a property that can be set via Vanilla'''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.+  * 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 Registries ===== 
 + 
 +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 ''OreFeature'' under the ID ''minecraft:ore'' in ''Registry.Feature''
 +  * 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|}} 
  
gimpansor_worldgen_1.16.2.txt · Last modified: 2020/08/30 10:19 by gimpansor