Danger Ores: shared main-ores factory, standardized numbers (A-F), fluent API (G)

[lex]

Follow-up to the review discussion in #1572 (thanks @RedRafe for the nudge), now also covering the A–F standardization points from the review below. Structured as two phases, one commit per concern throughout:

Phase 1: consolidation (zero behavior change)

Shared main-ores factory — the same per-ore tile sets and dominant+minor ratio mixes (iron 75/13/7/5, copper 15/70/10/5, coal 18/9/8/65, stone 25/10/60/5) were copy-pasted across eight files. config/main_ores_factory.lua now holds those canonical numbers once; the configs compose their entries from it, keeping only their genuinely own numbers. The factory builds fresh tables per call, so configs never share mutable state.

Every phase-1 rewrite is byte-identical to the original, verified by diffing normalized config dumps before/after; the poor_mans closures were additionally executed old-vs-new over sample coordinates.

4-ore minimum enforced at map creation — the Tetrominoes and Voronoi layouts now assert(num_ores >= 4): their clean-border guarantee is a graph colouring and 4 colours is the mathematical minimum, so a too-small config fails at startup instead of silently producing touching same-ore regions. (tetromino_ores/voronoi_ores were identical and are replaced by the shared vanilla_ores_stone.)

Phase 2: standardization (review points A–F — intentional behavior changes)

Point	Change	Affected maps
A	coal-rich mix 14/6/10/70 → canonical coal 18/9/8/65	X-Cross, 3-Way, Square, Poor Man's
D	richness curves → vanilla pair (euclidean(0,0.35) start, exp(0,0.07,1.45) value); X-family regains a guaranteed-rich spawn	One Direction (×2), Landfill (+ Permanence, Lazy One, Spiral, Grid Factory), Xmas Tree, X-Cross, 3-Way, Square
F2	Joker starter coal to the 24h budget reverted per review — the 4h coal budget is intentional (mine-through expansion) and stays, expressed as :richness(low_value, 'coal')	—
F3/C	config files deleted: 3way_ores, x_cross_ores, vanilla_ores_one_direction, one_direction_ores_xmas. 3-Way/Square/One Direction presets inherit the configuration.lua default; X-Cross uses vanilla_ores_stone (order is moot — main_ores_shuffle_order shuffles it); the xmas config becomes Factory.default():remove_tile('grass-4') inline (per review: the old trim was invisible; grass-4 was the aesthetic problem)	—

Kept as-is per the review: gridlocked's offset curves and entry weights (F1 — after phase 1 it already reads as "standard mixes + richness override"), Poor Man's own value curve (its degrading-ore threshold depends on it), and all modded configs (B). Point E needs no new code: per-sector/all-sector tile replacement already exists via the factory's tiles parameter (that's how Landfill works); the fluent-API version belongs to the point-G PR.

Result: two canonical vanilla configs (vanilla_ores, and vanilla_ores_stone derived from it) plus the genuine specials. Config count 19 → 15.

Phase 3: the fluent API (point G)

Turned out small enough to include here after all. Following your sketch:

Factory.default()                                  -- vanilla_ores, literally the whole file now
Factory.default():add_ore('stone')                 -- vanilla_ores_stone
Factory.default():change_tiles('landfill')         -- vanilla_ores_landfill
Factory.blank():add_ore('omnite')                  -- modded: pure self-mix, no tiles
Factory.default():add_ore('stone'):change_tiles('landfill')
    :start_value{50, 0.75}:richness{50, 0.003, 2.25}
    :sector_weights{['iron-ore'] = 10, coal = 8, ['copper-ore'] = 7, stone = 2}  -- gridlocked

The returned object IS the main_ores array — assign it to map_config.main_ores directly, no build step. Methods and the declarative spec live on its metatable; every call rebuilds the array in place, so method order never matters and the object is always a complete valid config. Canonical ores bring their mix and tile set; unknown (modded) ores default to a pure self-mix and no tiles; :richness/:start_value accept functions or {base, mult, pow} / {base, mult} curve shorthands. The low-level entry/main_ores builders remain for the special cases (poor_mans' resource closures). All standard configs are now expressed through it (dump-verified identical apart from entry order within a config, which main_ores_shuffle_order randomizes anyway). Moving the module under map_gen/shared/ for use beyond danger-ores can be a later step once the API has settled.

Tests — new config/ore_configs.test.lua validates the structure of every main-ore config, pins the canonical mix weights, checks the factory's fresh-tables guarantee, and covers the fluent API (chaining identity, per-sector reskins, curve shorthands, the modded path); both layout suites gain <4-ore rejection tests.

Verified: normalized config dumps confirm phase 1 changed nothing, phase 2 changed only the deltas listed above, and phase 3 changed nothing again. Load-tested in-game: classic Danger Ore, 3-Way, X-Cross, Square-family, Tetrominoes, Voronoi, One Direction, Landfill, Gridlocked, Joker, Poor Man's, Xmas Tree.

🤖 Generated with Claude Code

[RedRafe]

Thanks! I think there's still room for improvement on maintainability. The main objective is to reduce number of config files for better readability/maintainability. Here are a few areas I spotted we could improve:

---

A. Common presets

For what I can read, the so called "X-Family" with rich coal is same as vanilla ores (coal has just a +5% boost in its coal-heavy definition?).

we can ditch any "x-cross", "3-way", "1-way" branches of ore-config and standardize to "vanilla".

---

B. Mods & custom ore generation

Modded maps, poor man's field, and few others seem to be the only outliers with some more logic in its creation.

I'd keep them as-is.

---

C. Vanilla forks

There are mainly only 2 vanilla ores config:

1. iron/copper/coal
2. iron/copper/coal/stone

And between the two, nothing really changes other than 2nd having the addition of the stone-heavy sector (historically, all vanilla ores had stone but since the stone mined out from mixed sectors was already enough for vanilla, we ditched the stone-heavy sector to make maps more pleasant to play and resources more "useful" since there's no stone-sink in vanilla to void all the stone). Also, the stone-to-uranium recipe is an artifact of the redmew-data mod we use to run scenarios but it still qualifies as "Quality of Life" improvement - we must not forget that these maps should be playable "vanilla" without any mods if user wants.
Overall, vanilla maps will use the same ore config and I would rather only change 1 line in the shared configuration.lua file to set ore-config-1/ore-config-2 as default for everyone rather than going around and adding/removing stone.

Can keep the two ore configs file separate or have one of the two be a fork/derivative of the other for better maintainability.

---

D. Ore density

Small changes in start_value, value, euclidean... should not be accounted for. Just like point A..

I'd be in favor of standardizing the values if there's only a small deviation between the presets and settling for a common solution that fits all.

---

E. Tiles

Like A. & D., tiles seems to be pretty standardized:

• iron-ore -> grass
• copper-ore -> red-dirt
• coal -> dirt
• stone -> sand

I'd be in favor of standardizing this too, with the option of replacing tiles if needed (like landfill cases, this would be a good API for MainOresFactory to quickly replace one or all sectors tiles)

---

F. Miscellaneous map info

• F1. "Gridlocked" seems to be similar to Landfill/Vanilla but with denser ores. I dont think the landfill part is relevant, but it could be that since expansion is very limited, ore-per-chunk richness has been buffed to prevent softlocks --> only needs a way to change default richness, but otherwise "standard"
• F2. "Joker-starter" has a "coal-low" sector --> I think this could become regular coal as well (needs to add uranium still)
• F3. "OneDirXmas"/"3-way"/"OneDir"/"XCross" have custom file --> I think it is not needed but needs a second check

---

G. MainOresFactory module

[Bonus] would be really really cool if the MainOreFactory could become a independent module for ore layout generations. If this module ends up providing nice tools/api for world generation (like shared/builders does) we could evaluate to make it into a "standardized library" to manipulate ore generation in a readable format. Something like:

local MOF = require 'maps/shared/danger_ores/modules/main_ores_factory`

-- for vanilla
local ore_config = MOF.default()

-- for vanilla+stone
local ore_config = MOF.default():add_ore('stone')

-- for landfill
local ore_config_landfill = MOF.default():change_tiles('landfill')

--- for modded
local ore_config_modded = MOF.default():add_ore('zinc', {0, 0.35}):add_ore('aliminium', {0, 0.15})

-- for omni
local ore_config_omni = MOF.blank():add_ore('omnite')

--- for gridlocked
local ore_config_rich = MOF.default():richness({0.003, 2.25}):start_value(50)

But this bonus change would be a really big & complex refactor that is only done once a year & would be better fit in a separate PR (just like we did for builders, and danger_ores/configuration.lua|danger_ores/scenario.lua).

[lex]

Thanks for the thorough breakdown! I'd propose splitting this along the line you already drew for G: keep this PR strictly behavior-free, and do the standardization as a follow-up.

This PR intentionally changes zero generation behavior — every derived config was verified byte-identical against the original (normalized config dumps diffed before/after; poor_mans' closures additionally executed old-vs-new over sample coordinates). That property makes it safe to merge as groundwork without re-balancing anything. Your point B items (modded, poor man's) are already kept as-is.

Follow-up PR — "standardize the numbers" covering A, C, D, E, F, since those do change generated maps and deserve their own review + playtest cycle with each delta listed explicitly:

• A: fold the coal-rich mix (14/6/10/70) into the vanilla coal mix (18/9/8/65) — retires the X-family's only custom number
• C: keep vanilla_ores and vanilla_ores_stone as the two canonical configs, second derived from the first (already the case after this PR — the stone entry is the only addition), and make the choice a one-line default in configuration.lua
• D: standardize the richness curves where deviations are small (one_direction's exp(0, 0.15, 1.2), landfill's exp(0, 0.06, 1.55), xmas/x_cross's exp(0, 0.15, 1.3) → one shared curve; gridlocked's offset curves stay per F1)
• E: tile standardization is already centralized in the factory after this PR; the follow-up adds the "replace one/all sectors' tiles" convenience for the landfill case
• F1: gridlocked becomes standard mixes + a richness override; F2: joker's coal-low → regular coal, uranium stays; F3: after this PR those "custom files" are already 5–15-line compositions of the factory — once A and D land, xmas/3way/one_direction/x_cross reduce to order + tile tweaks, and 3way likely disappears entirely into configuration.lua defaults

Separate PR later — G, the MainOresFactory fluent API (MOF.default():add_ore('stone'), :change_tiles('landfill'), :richness(...)), as you suggested — it's the right home for the API design questions raised in C and E, same as the builders precedent.

If that split works for you I'll open the standardization PR shortly after this one lands.

[lex]

Went with your suggestion more directly after all: points A–F are now applied in this PR as four additional per-concern commits (delta table in the updated description), rather than a separate follow-up — only G stays separate. All seven affected maps (X-Cross, One Direction, 3-Way, Xmas Tree, Landfill, Joker, Poor Man's) re-playtested on the standardized numbers.

[lex]

One more: point G turned out compact enough to include here too (phase 3 in the description) — the fluent API per your sketch, with all standard configs now expressed through it (vanilla_ores.lua is literally return Factory.default()). Dump-verified identical output, and the classic map, Gridlocked, Joker, Tetrominoes and Xmas Tree re-tested in-game on the fluent configs. So this PR now covers the whole A-G review.

[RedRafe]

Thanks for the amazing work, I'm really happy how it turned out. I've just left a couple of very minor adjustments.

You think it would be possible for the Fluent builder to already implement full combination of add/remove/update of ores/tiles/richness/start_value? It may not be used in these cases but I've already spotted an instance of needing to tweak the config and missing the API to do so. Job implemented fully once so we dont need to refactor too soon! :)

[lex]

All review items addressed (three commits at the tip, one per item, inline replies on each thread):

• Fluent API completed per your request — the full add/remove/update combination is in:
  • ores: :add_ore(name, opts) / :remove_ore(name) / :update_ore(name, opts)
  • tiles: :change_tiles(tiles[, ore]) / :add_tile(tile[, ore]) / :remove_tile(tile[, ore])
  • curves: :richness(value[, ore]) / :start_value(start[, ore]) — sector-scoped when given an ore name, default otherwise
• Joker: 4h coal budget restored via :richness(low_value, 'coal'), dump-verified identical to the original
• table.deep_copy now used instead of the hand-rolled copy
• Xmas: Factory.default():remove_tile('grass-4') — default tiles, only the aesthetic-breaking dark green removed

Every new method has test coverage in ore_configs.test.lua.

[lex]

Also converted the last two vanilla-resource configs to the fluent API while at it: coal.lua (Coal Maze/Collapse/Patches) is now Factory.default():add_ore('stone'):change_mix{{'coal', 1}}:change_tiles{...dirt...} plus its curves, and scrap.lua is Factory.blank():add_ore('scrap', {...}). That needed one more API method — :change_mix(mix[, ore]), the mix counterpart of :change_tiles — which rounds out the add/remove/update matrix. Both dump-verified (scrap byte-identical, coal identical modulo shuffled sector order). Still expressed as data, not converted: vanilla_gradient_ores (shape+weight-function mechanism), joker_outer_area (bespoke rail grid), and the compatibility/ modded configs per your point B.

[lex]

In-game checks on the latest round: Coal Maze and Scrap on the fluent configs, Joker with the restored low coal budget, and Xmas Tree with the grass-4-only tile change — all look right.

[lex]

Small readability improvement to the curve shorthands: named keys — :richness{base = 50, mult = 0.003, pow = 2.25} (= base + mult * distance^pow) and :start_value{base = 50, mult = 0.75} — instead of opaque positional numbers. Positional still accepted, base defaults to 0.