Design

This page contains notes and ideas related to the design of Custom Ore Generation.

Biome Sets

Design

Currently, we can restrict distributions to specific biomes with the <Biome> tag. Specifying long lists of biomes becomes tedious, and we often need to rely on inheritance and in the worst case copy-and-paste. These lists grow very long when attempting to support mods that add biomes, such as Biomes o’ Plenty. We propose to address this issue with the addition of a <BiomeSet> tag that defines a set of biomes. Its children would include <Biome> elements, other <BiomeSet> elements, and elements that select biomes by different criteria. To match a set, a biome would need to be one of the biomes in the set, match a child set, or would satisfy all biome selectors. If no biomes are listed, or a selector is omitted, the wildcard is assumed. The types of selectors might include:

• Any number of <BiomeType> elements specifying biome dictionary terms (all must be satisfied),
• type attribute specifying one biome type as a convenience,
• minTemperature=/=maxTemperature attributes bounding the temperature,
• minRainfall=/=maxRainfall attributes bounding the rainfall,
• minHeight=/=maxHeight attributes bounding the height range (completely within).

<BiomeType> would also support inheritance through its inherits attribute, and that is key to allowing distributions to share common biome set definitions.

Another convenience would be biome exclusions. Rather than specify all possible biomes except the one that needs to be excluded, we could simply indicate the exclusions. This could be problematic, because it is impossible to predict new types of biomes that the user might add. However, we need this for defining sets. Without it, we only have the union operation. With it, we have set subtraction. The user can implement intersection by combining union and subtraction.

Examples

Assume we want to select only continental, non-mountainous biomes. We could list the types of biomes to include, as below:

<BiomeSet>
  <BiomeSet type="forest"/>
  <BiomeSet type="plains"/>
  <BiomeSet type="desert"/>
  <BiomeSet type="swamp"/>
  <BiomeSet type="jungle"/>
  <BiomeSet type="frozen"/>
  <BiomeSet type="beach"/>
  <Biome name="river"/>
</BiomeSet>

Note that we need to include river specifically, because the water type would include ocean. It is unfortunate that there is no type distinguishing oceans from rivers. Also, the frozen ocean is included by the frozen type, but if we leave it off, we lose Ice Plains and Ice Mountains (why do these not use the plains and mountains terms?).

Instead, we could use the height restrictions to exclude oceans and extreme hills.

<BiomeSet minHeight="-0.5" maxHeight="1.3"/>

But that is too promiscuous and would include things like mushroom island and nether biomes.

So we need to exclude those. One way is by listing all valid biomes, like so:

<BiomeSet minHeight="-0.5">
  <BiomeSet type="forest"/>
  <BiomeSet type="plains"/>
  <BiomeSet type="desert"/>
  <BiomeSet type="swamp"/>
  <BiomeSet type="jungle"/>
  <BiomeSet type="frozen"/>
  <BiomeSet type="beach"/>
  <BiomeSet type="water"/>
</BiomeSet>

But this is still wrong, because it will bring in nether biomes listed as forest, like BOP’s Nether Garden. These could be excluded by a separate <Dimension> tag that limits to the Overworld. Or we could switch to using exclusions like so:

<BiomeSet name="OtherDimensions">
  <BiomeSet type="nether"/>
  <BiomeSet type="end"/>
</BiomeSet>
<BiomeSet minHeight="-0.5">
  <Exclude>
    <BiomeSet inherits="OtherDimensions"/>
    <BiomeSet type="mushroom"/>
  </Exclude>
</BiomeSet>

Dimension tag

A <Dimension> tag could limit a distribution to a given dimension, like <Biome> does for biomes. This would require either an id, name, isSurface, or symbol attribute. If a <Dimension> tag is not specified, then wildcard is assumed. Note that the wildcard means every world, including Mystcraft dimensions, which might be undesirable. To support different settings depending on the dimension, this could have <Setting> elements as its children. This is probably simpler in many cases to using inheritance.

Mystcraft integration

The original COG supported the original Mystcraft design, where symbols were added in some quantity to a book, and distributions were sensitive to the symbol count, through expressions. Now that Mystcraft books are written according to a grammar, with modifier symbols, etc, it has become more complicated. The <Dimension symbol””>= tag will apply a distribution to an age with that symbol. Child <Settings> elements should have expressions that consider modifiers on the symbol.