Design

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

Surface height

Users want a way to generate based on the surface height. The primary complication is that we need to generate structures in the void, prior to chunk generation (otherwise, we need to back-fill chunks, eww). Thus, we need to guess the height. For vanilla generation, we can obtain the biome and then average its min/max height. ATG gives us access to the actual height value.

Two use cases for considering surface height:

• Scaling the height of generation
• Restricting/weighting generation

Linear scaling idea

We could think of the distribution height as a linear function of the surface height: y = ms + b. Both m and b could be random variables, i.e., each would be a <Setting>.

We could introduce an attribute heightOrigin that would take the values “bedrock” (default), “sealevel” or “surface”. The existing height setting would serve as the offset, b, and existing behavior would be preserved. The new setting “HeightScale” would represent m and take the place of the current 0-1 fractional height hack.

This would generate at 8-12 above the midway point to the surface.

<HeightOrigin>surface</HeightOrigin>
<Setting name="HeightScale" avg="0.5"/>
<Setting name="MotherlodeHeight" avg="10" range="2"/>

Simple scaling

Another idea is to define a simple scale from the randomly chosen height setting to the actual generation height. For example, the current expressions of the form “:=32/64*dimension.groundLevel” would be specified by:

<ScaleHeight from='64' to='sealevel'>

And that could be the default. For surface-relative height, use “surface” as the to attribute. The from attribute would default to “64”. The following will scale the height and frequency from the “64” scale to the surface height:

<ScaleHeight to='surface' withFrequency='true'>

Mystcraft integration

Simple

There are two simple and important integration points:

• Disabling COG-based generation when DenseOres is active.
• Incorporating COG-based generation into the instability calculation.

Complex

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.

We need a mapping between COG and Mystcraft semantics. Certain (marked) distributions (usually a preset) will be manifested as noun symbols, supporting these modifiers:

• Ore block (repeat to increase relative weight)
• Biome (repeat to increase relative weight)
• Option (including frequency and size)

Modifying a distribution would be equivalent to extending it in a config file: everything is inherited and then overridden by symbols.

A distribution (preset) is represented by a symbol if it has a child <MystcraftSymbol>. The old name and displayName attributes should probably be taken from the distribution (which does yet support displayName). The new <MystcraftSymbol> element will have these attributes/children:

• rarity: a value in [0,1], indicating how common a symbol is in treasure and trading,
• tradeable: indicates whether villagers will trade with the item,
• firstTradeItem: name/id of first trade item; if not specified, Mystcraft chooses,
• secondTradeItem: name/id of second trade item; only allowed if firstTradeItem is specified.
• suffix: the last word of the symbol; all distribution symbols will start with the words Control and Ore, with the third word depending on the type of distribution (Substitute: Change, Cluster: Tradition, Veins: Flow, Cloud: Entropy).

Marked COG options would be represented as a symbol, with the effect depending on the type:

• Boolean: Modifier toggles the default.
• Discrete: One modifier per value.
• Continuous: Default value multiplied/divided by repeating the modifier.

If an option symbol is given as a modifier of a distribution symbol, the option is only changed in the scope of that distribution. An option can also act as a noun on its own, in which case it is set globally. The options will begin with the words: Control, Ore, Question. The last word is given by the word attribute of the <MystcraftSymbol> element and would default to the option name. The frequency option would have the word Possibility, while the size would have Growth.

Blocking defaults: There will be a blocking symbol (Control, Ore, Inhibit, Contradict) that will have two functions:

• Blocking preceding distributions for a particular ore (as a modifier),
• Inverting the effect of an option (as a modifier), i.e., divide instead of multiply.

This helps limit the instability in the world.

We should integrate with Mystcraft ore block instability mechanic, so that increased ore density results in decreased stability.

The DenseOres symbol should disable COG generation for the dimension.

We should verify that the terrain symbols are manifested in existing attributes like world.type and world.isSurface.

Adjacency-based Replacement

Extend <Replaces> to add the attributes above, below, north, south, west and east. They will be block descriptors that restrict on the type of block one space over in the given direction. This would allow things like placing a block on a surface (e.g., rock below, air above), or ensuring that an ore deposit is hidden in stone.

Block sets

Like the biome sets, except define a set of block descriptors. The <BlockSet> elements could be referenced from distributions using <ReplaceSet> and <OreBlockSet>.