Pages

main/Sample Child Configurations

Here you can find basic samples for hierarchical config files, using combinations of worldConstraints, worldExclusions, biomeExclusions and biomeConstraints. When processing an area, the plugin will locate the config file on the deepest branch possible in the hierarchy, inheriting and overriding settings along the way.

Sample: Common ores in a world, rare ores in another, any other worlds using vanilla generation

config.yml

Plugin:
     [...]
    # being placed in the root config, the constraints represent global plugin constraints
    worldConstraints: [RareWorld, CommonWorld]
    # same goes for exclusions
    biomeExclusions: [HELL, SKY] 
    childConfigurations: [config_rare.yml, config_common.yml]    
     [...]
OreSpawner:
    oreDistribution:
        COAL_ORE:
          [<extra vein settings>]
          # 0.0 will have the effect of cleaning the ore, but its generation will be skipped
          amountPercentage:0.0
        IRON_ORE:
          [<extra vein settings>]
          amountPercentage:0.0
        GOLD_ORE:
          [<extra vein settings>]
          amountPercentage:0.0
        DIAMOND_ORE:
          [<extra vein settings>]
          amountPercentage:0.0
        [<continue with the rest of the ores>]

config_common.yml

Plugin:
    worldConstraints: [CommonWorld]
OreSpawner:
    oreDistribution:
        COAL_ORE:
          # override the parent setting
          amountPercentage:0.35
        IRON_ORE:
          amountPercentage: 0.18
        [...]

config_rare.yml

Plugin:
    worldConstraints: [RareWorld]
OreSpawner:
    oreDistribution:
        DIAMOND_ORE:
          amountPercentage: 0.05
        GOLD_ORE::
          amountPercentage: 0.1
        [...]


It is important to remember that even though you don't want COV to generate in a specific combination of world and biome, but you still want to clean the ore generated by the standard block populators (whichever they might be), COV can help here by cleaning it up for you but bypassing its ore generation stage. You can achieve this by setting an amountPercentage of 0.0 for all the ores you wish to be cleaned up.

Allowing it to generate though for specific zones, it's just a matter of overriding the amountPercentage value alone. All the other vein settings will get inherited from the parent config.

Sample: COV generation throughout, but deserts in all the worlds will only have diamonds and, for a world named MyCustomWorld, coal is not available under the oceans and gold is found at a higher altitude in jungles


config.yml:

Plugin:
  [...]
  childConfigurations: [non_desert.yml]  
  # global biome exclusions
  biomeExclusions: [HELL, SKY] 
  [...]
OreSpawner:
  [...]
  oreDistribution:
    DIAMOND_ORE:
      [<diamond veins specific settings>]
    [<no other types of ore defined here>]


non_desert.yml:

Plugin:
  biomeExclusions: [DESERT]
  childConfigurations: [custom_world_oceans.yml, custom_world_jungles.yml]  
OreSpawner:
  oreDistribution:
    [<fully define all your ore veins here, with the exception of diamonds>]


custom_world_oceans.yml: 

Plugin:
  worldConstraints: [MyCustomWorld]
  biomeConstraints: [OCEAN, FROZEN_OCEAN]
OreSpawner:
  oreDistribution:
    # override some settings for coal, everything else is going to be inherited
    COAL_ORE:
      amountPercentage: 0.0


custom_world_jungles.yml: 

Plugin:
  worldConstraints: [MyCustomWorld]
  biomeConstraints: [JUNGLE, JUNGLE_HILLS]
OreSpawner:
  oreDistribution:
    #  override some settings for gold, everything else is going to be inherited
    GOLD_ORE:
      maxLevel: 160


When it comes to processing the desert biome, the plugin has to stick to the ore vein definitions in the root config, as every other config branch is blocked.
For everything else, it will move into non_desert.yml, where it's going to read the rest of the vein definitions, combining them with the diamond veins in the root. It will either stay here and use these settings, or move forward and pick the jungle or the ocean specific configs, depending on the biome it's currently processing in, overriding the settings inherited from the parent config.

As you can see, the golden rule is to design from common settings and move towards specifics.