Quick Nav


Back To Top

Overview

Oreverhaul allows you to completely customize your ore generation and distribution, to massively increase the importance of trains and provide the option of forcing exploration for specific ore types or better fields. (Note: as of 0.17 vanilla does some level of both distance-based richness and distance tiering for crude and uranium, but both are limited in effect and the tiering only applies to those two ores).

Background

Oreverhaul grew out of my attempts in late 2016 to require venturing ever further from spawn for successively higher tier ores, and make it so that ore richness in the starting area was poor enough to force expansion as soon as possible, without the risk of making any early-game ores not available nearby or making finding a specific ore type difficult to find. I tried RSO at first, but it lacked type-specific spawning control, and its "increasingly low per-chunk chance at higher distances" meant finding long-distance ores would have been very tedious. As a result, I started creating Oreverhaul, which has these capabilities and more.

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.

Biters

To mesh with the ore generation changes, as well as to allow for the potential of forcing the player into conflict with biters to get increasingly high-tier ores, Oreverhaul can also redesign the placement and nature of biter nests, such that they grow increasingly large - and unit choices increasingly powerful - with increasing distance. As such, nests near the spawn will be single isolated spawners, and rarely spitters; with increasing distance, spitters may appear, as can worms of increasing size, and the nests will become clusters. By a thousand tiles away, these can include dozens of spawners, half of which are spitters, and equally many worms, including many big or behemoth ones (Oreverhaul actually used to create a green worm before one was added to vanilla in 0.17).

Like with ore placement, the spawner generation system has "vanilla with modification pass" and "overhaul" modes, and has much the same advantages and caveats for both.

Configuration

Oreverhaul is extremely configurable, both in terms of toggling specific features as well as controlling numerical scaling factors and assignments. These settings are so extensive that they cannot cleanly be used inside the mod settings system; many consist of tables of values, or have extensive explanation, neither of which is compatible with the mod settings interface.

As a result, configuration of Oreverhaul is done by editing the config file in the mod with a text editor, either directly with an archive program or by unpacking the zip and editing the resultant .lua file. These settings will take effect as soon as you reload the save; a game restart is not necessary.

This settings process means that in multiplayer, each player must have an identical copy of the configuration file; for that, the modpack creator (ie whoever sets up the pack and all the settings) should edit the config file and distribute that to the other players, who can just drop it into their mod zip files (overwriting the original). Do not make a habit of sharing the entire mod file, as this will cause versioning issues and will in the long term result in settings being lost as you update mods.

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:
{
sulfur = 0.6
}
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:
{
sulfur = 0.75
}
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

Downloads

Via Factorio Mod Portal