Generation
With Oreverhaul installed, all ores are sorted into successive "tiers", roughly corresponding to their place on the techtree. Each tier is assigned a minimum distance from spawn where it can appear, and as such more advanced ores will require increasingly far-flung outposts to acquire them. Additionally, the richness of the patches starts abysmally low near spawn, but increases rapidly with distance, with patches a few hundred tiles out being of ten times higher yield, and a thousand tiles away being another twenty times on top of that. Additionally, the patches themselves grow somewhat larger, meaning they can support more miners and yield better total yield per unit time.
A sample ore distribution with vanilla ores + sulfur. Note the increasing richness and size, and how each ore aside from the basic four only spawns at a set minimum distance, based on its tier. (Click or open in new tab to see full size.)
Sample distribution with Bob's mods, where the greater diversity in ores makes the tiering even more clear.
There are two generation modes in Oreverhaul. The first simply edits ores already placed by the native game autoplace specifications, deleting "too close to spawn" ores to enforce distance tiering and editing richnesses on a per-tile basis. This mode leaves the ore generation "feeling" mostly vanilla, but cannot apply all the normal effects of distance - for example patches growing in size with increasing distance - and because of the increasingly strict deletion behavior nearer the spawn, can result in the total amount of ore being unexpectedly low. Additionally, due to the possibility of overlapping ore patches of which Oreverhaul deletes one ore, this can result in some strange ore field geometries.
The second generation mode, the default, completely replaces the autoplace-based ore generation, and places ore patches explicitly, based on the set of ores which can spawn at that distance. This has no issues with ore amounts or placement irregularities, and is much more flexible and reliable, but is slightly less vanilla-feeling, and is marginally more expensive to generate. Additionally, with this mode selected, the "preview" feature in the map settings is no longer accurate for ore placement, and all ore-related map generation settings in the menu (size, frequency, richness) are entirely ignored.
Configuration Settings
The following is the full list of the configuration settings, pulled directly from the code repository:
oreTierDistances
Type: Table
Current Default Value:
{
tier0 = 0,
tier1 = 40,
tier2 = 200,
tier3 = 500,
tier4 = 1000,
tier5 = 2000
}
Reasonably self-explanatory. How far (in tiles) must you travel before tier N ores begin to generate? You can also set all tier distances to zero to effectively disable tiering.
oreTiers
Type: Table
Current Default Value:
{
coal = 0,
iron-ore = 0,
copper-ore = 0,
stone = 0,
ground-water = 0,
tin-ore = 1,
lead-ore = 1,
quartz = 1,
nickel-ore = 2,
silver-ore = 2,
crude-oil = 2,
lithia-water = 2,
zinc-ore = 2,
sulfur = 2,
cobalt-ore = 3,
bauxite-ore = 3,
gold-ore = 3,
gem-ore = 3,
rutile-ore = 4,
tungsten-ore = 4,
uraninite = 5,
fluorite = 5,
uranium-ore = 5,
thorium-ore = 5
}
Which ores fit in what tier. Anything not in this list is entirely ignored (deleted and not generated). Adding custom ores is entirely supported; use their internal names. Any specified ore that does not exist is ignored for generation but logged. BobMod ores configured with input from Bobingabout, and so should be reasonably fitting for his progression. AngelOres not included by default since their processing (more advanced resources based on processing the same ore type) is fundamentally incompatible with a distance tiering system. Add them if desired, but there is little point in doing so.
starterOres
Type: Table
Current Default Value:
{
coal = 4,
iron-ore = 7,
copper-ore = 4,
stone = 2
}
Ores that MUST be present near the center. Numerical values are their relative weights (since not all are of equal need in the early game).
ignoredOres
Type: List
Current Default Value:
[geothermal]
Ores unaffected by custom distribution; usually things that have their own gen code that should not be tampered with (eg biome specific, certain patterns, etc).
redoOrePlacement
Type: Single Value
Current Default Value:
true
redoSpawnerPlacement
Type: Single Value
Current Default Value:
true
Should a custom ore/spawner placement algorithm be used, instead of just deleting/modifying preplaced ore tiles? This helps clean up the otherwise messy (eg removing one half of an ore patch due to it lying on a tier boundary) and often balance-unfriendly generation. Additionally, vanilla ore gen does not have rules like "bigger patches further out", so that sort of mechanic will not apply with this disabled. Many settings have no effect if this is disabled.
richnessScaling
Type: Single Value
Current Default Value:
true
Should richness scaling be enabled? If not, richness is flat across the map.
richnessFactors
Type: Table
Current Default Value:
Add or modify entries here to add flat richness multipliers by ore type. Unspecified ores default to one. Some ores - notably liquids - are ignored in favor of internal code. No ore has this by default (that I know of).
radiusFactors
Type: Table
Current Default Value:
Add or modify entries here to add flat ore patch size multipliers by ore type. Unspecified ores default to one. No effect on liquids. Some clamping is applied to avoid tiny ore patches (clamped at starter area size). In the base game, stone has a penalty (equivalent to assigning a value of 0.67); this is removed by default since it is usually irritating. Only meaningful if ore generation override is ENABLED.
antiBias
Type: Table
Current Default Value:
{
sulfur = 0.8,
stone = 0.3
}
At a given distance, there is a set of ores which are permitted for generation (determined by distance gating). When an ore patch is to be generated, one entry in that list is selected. Normally every ore is equally likely to generate, being randomly selected from that set; this option allows you to reduce the overall frequency of certain ores (those patches may become something else). Anti-biasing triggers a "reroll" of the ore if the first selection has a corresponding value; it may select the same ore again (with the same chance as before), Anti-biasing is applied once per patch only; even if the new ore is the same as the old one, it will NOT reroll again, nor will it do anything if the new ore also has an anti-bias. The numerical effect of an anti-bias on a certain ore, assuming N possible ores, and an anti-bias of 'f', is a chance reduction from 1/N to (1/N)-((1/N)*f*(1-1/N)). So, for example, if sulfur is one of eight candidate ores, and has a 25% anti-bias, one quarter of the sulfur gets "rerolled", 7/8ths of which becomes something other than sulfur, or a total reduction of 0.125*0.25*0.875. Only meaningful if ore generation override is ENABLED, and does not apply to the start area. Anti-biases must be between zero and one. Values outside this range will at best have no effect and at worst cause serious issues.
oreMixinSeed
Type: Single Value
Current Default Value:
0
spawnerMixinSeed
Type: Single Value
Current Default Value:
0
These values are mixed into the world seed for ore/spawner generation, so you can keep terrain/biome/etc while choosing a new ore/spawner distribution. Mixins of 0 have no effect.
offsetX
Type: Single Value
Current Default Value:
0
offsetY
Type: Single Value
Current Default Value:
0
Raw offsets for the entire oregen pattern, in case you have terrain you like "off center" but would like to move the ore or spawner patches to effectively move the starting area.
oreTierDistanceFactor
Type: Single Value
Current Default Value:
1
How much to flat-scale the distance gating (Ore Tier Distances).
oreRichnessDistanceFactor
Type: Single Value
Current Default Value:
1
A base scaling for the distance-richness curve. At 2, you need to travel 2x as far for the same richness boost.
oreDistanceFactor
Type: Single Value
Current Default Value:
1
How much to flat-scale the distance gating (Ore Tier Distances) AND richness curve. Basically the above two options combined.
oreSizeDistanceFactor
Type: Single Value
Current Default Value:
1
How much to flat-scale the ore patch size distance scaling. Values larger than one "compress" the scaling, values less than one (but more than zero) expand it, all by that corresponding factor.
spawnerDistanceFactor
Type: Single Value
Current Default Value:
1
Like the above, but for spawners (base size, worm tier, etc).
minSpawnerDistance
Type: Single Value
Current Default Value:
400
How close the innermost spawners can be. Unaffected by the scaling factors.
spawnerClustering
Type: Single Value
Current Default Value:
1
Spawner clustering, aka how much (relative to default) spawners should allow themselves to generate in "nests" of many spawners as opposed to isolated. Only meaningful if spawner generation override is ENABLED.
oreRichnessScalingFactor
Type: Single Value
Current Default Value:
2.5
A multiplier for the base rate of richness scaling.
flatRichnessFactor
Type: Single Value
Current Default Value:
1
A flat-rate multiplier for richness.
orePatchChanceFactor
Type: Single Value
Current Default Value:
1
A flat-rate multiplier for ore patch chance per chunk. Higher means more ore patches (not recommended above base settings unless you have a world with little space for ore); lower means patches are rarer. Be careful in an environment with many ores, lest you make hunting for a specific ore type painful. Only meaningful if ore generation override is ENABLED.
plateauRichness
Type: Single Value
Current Default Value:
false
Does the richness plateau at an internally calculated distance, or does it keep growing forever? Note that this can create ore patches with billions of ore if set to false.
spawnerScaling
Type: Single Value
Current Default Value:
true
Spawner Scaling (making spawners "tier up" with distance); Only meaningful if spawner generation override is DISABLED, as the feature is built into the override.
spawnerRateFactor
Type: Single Value
Current Default Value:
1
Flat-rate spawner chance multiplier. Only meaningful if spawner generation override is ENABLED.
clearSmallPatches
Type: Single Value
Current Default Value:
true
Should small (few-tile) ore patches (usually the result of ore deletion) be cleaned up? Only meaningful if ore generation override is DISABLED, as the override generation does not have this issue.
orePatchCondensationStart
Type: Single Value
Current Default Value:
1.4
orePatchCondensationEnd
Type: Single Value
Current Default Value:
2
These values (N1, N2) will make ore patches N times larger but 2N times rarer at the minimum and maximum distances. Intermediate distances are interpolated. Only meaningful if ore generation override is ENABLED. Be warned that excessive patch size (above ~3.2) will cause ore patch cutoffs, as the ore patches become greater than 3x3 chunks in size, and the generation algorithm, for performance reasons, does not model a 5x5 chunk area.
richnessPerOre
Type: Single Value
Current Default Value:
true
If false, richness is a global parameter shared by all ores, so at the same distance, explicit multipliers notwithstanding, iron, tin, gold, and uranium and so on will have the same richness. If true, each ore starts its richness curve "fresh" from when it first appears. So if ore A appears at distance X and B at distance Y, the richnesses would be equal at N blocks from X or Y respectively.
nestHealthFactor
Type: Single Value
Current Default Value:
10
Should spawners be made more durable? This helps discourage clearing large swathes of land of biters, encouraging more defences rather than just "kill everything on the map". Not strictly worldgen, but does dovetail with it.
retrogenOreDistance
Type: Single Value
Current Default Value:
-1
retrogenSpawnerDistance
Type: Single Value
Current Default Value:
-1
Should retrogeneration be enabled, and if so, at what minimum radius from the center? A value of "-1" Disables it entirely; >= 0 enables it with that minimum distance. May not be MP compatible. Obviously causes lag spikes.
retrogenOreSet
Type: Single Value
Current Default Value:
Which ores to retrogen, if the ore retrogen is enabled. Make empty for "all".
enforceSpawnerTieringForBuiltBases
Type: Single Value
Current Default Value:
true
Should newly-built enemy bases have the distance (worm size, spawner type, etc) restrictions and distance scaling forcibly applied? Helpful if you have a nice clear ore patch then get a spitter nest plopped on it four hours into the game. No performance impact unless your biters are expanding more aggressively than AIs in a game of Civilization on the Deity difficulty (and if that is the case, you need a lot more than this to help you). Does not affect already-built bases, and tapers off as the evolution factor rises (100% effect at evo 0, 0% at evo 1).
expensiveRecipeMultiplier
Type: Single Value
Current Default Value:
1.5
expensiveTechMultiplier
Type: Single Value
Current Default Value:
1.125
If a save is using expensive recipe or technology mode, all ore richnesses are multiplied by this, so as to reduce the chance of becoming 'stranded' without the resources with which to build/research trains. Combine with each other, as well as other difficulty-based multipliers if applicable. Must be positive, and is generally advised to be >1, since making harder recipes have *less* ore nearly guarantees stranding.
Source Code
The source code for Oreverhaul can be found here:
GitHub