Add Danger Ores - City Blocks map

[lex]

Danger Ores – City Blocks

It's always been a little sad how little use trains get on danger ores maps — belts rule everything. Maybe this map changes that.

A grid of isolated one-ore rooms (4×4 chunks; stone rooms rare) separated by paved rail corridors carrying a ready-made double-track network: continuous lines ring every room and meet at a signalled roundabout on every corner. The rails are ordinary and minable — a head start, not a constraint. Only rail infrastructure (rails, signals, train stops, power poles) and trains can be built on the corridors, and belts cannot span them: trains are the only inter-room logistics.

Details

• Spawn room carries all four ores (one per quadrant); rail techs pre-researched with a starter train kit (rails, stops, signals, locomotive, wagons, fuel).
• Corridors are paved (gravel rail beds, concrete curbs/medians); anything non-rail built there is refunded with a message.
• modules/city_blocks.lua generates everything chunk-locally (no cross-chunk writes, generation-order independent); room ores assigned once on init (weighted, BFS-guaranteed all four ores adjacent to spawn).
• Roundabout geometry decoded from an in-game blueprint (legacy rail pieces — functional in 2.0 and already on the danger-ores allowed list).
• Registered in map_poll.lua (danger_ore_normal) and the danger ores changelog.

Play it

return require 'map_gen.maps.danger_ores.presets.danger_ore_city_blocks'

Testing

Layout harness (ore coverage/weighting/spawn guarantee) + playtested in-game through several iterations: corridors, roundabouts, signals, train routing, build restrictions.

🤖 Generated with Claude Code

[RedRafe]

I've left a few suggestions. Additionally, have you tested this map by saving, closing, & reloading the savefile?

[lex]

Thanks for the review! All four points addressed in the new commit:

• Ore config as input: register(config) now derives the ore count from the passed main_ores (any N works), with optional room_ore_weights; the spawn-quadrant split and the BFS all-ores-near-spawn guarantee adapt to whatever config is used.
• vanilla_ores: dropped city_blocks_ores.lua entirely — the preset now uses config/vanilla_ores.lua. Rooms are iron/copper/coal and stone stays in the mixed ratios, which plays fine here. One heads-up for the "last 5 maps" part: Tetrominoes and Voronoi can't move to a 3-ore config — their no-two-touching-regions-share-an-ore guarantee is a graph 4-colouring, and 4 colours is the mathematical minimum (with 3, some adjacent regions must share). Consolidating their two identical 4-ore configs into one shared file would work though — happy to do that as a small follow-up PR.
• entity_placement_restriction: corridor rule now runs through the shared module with a keep-alive callback (ghosts/refunds/destruction handled there). The whitelist was already keyed by LuaEntity.type rather than name, and stays that way.
• data.generated: gone — Event.on_init(assign_ores) directly.

Save/close/reload tested on the local scenario (both before and after these changes) — layout, room ores and corridor rules all persist correctly; the layout lives in Global so nothing regenerates.

Also refreshed the preview image to match the current map.

[RedRafe]

Thanks for applying the changes! Looks good

Tetrominoes and Voronoi can't move to a 3-ore config — their no-two-touching-regions-share-an-ore guarantee is a graph 4-colouring, and 4 colours is the mathematical minimum (with 3, some adjacent regions must share). Consolidating their two identical 4-ore configs into one shared file would work though — happy to do that as a small follow-up PR.

Happy to accept follow-up PRs if you want to. I see two issues hanging:

1. Would be cool if Tetris & Voronoi could also accept ore configs as inputs to make the module moddable with other ores. If there's a minimum number of ores to be inputed I would suggest enforcing in each module the limit and actively checking on map creation that certain rules have bene followed.

2. Regarding the shared files for ores config, I see "many" vanilla ores have similar ore configs but are split each one in its own file (even older maps). This was only recently spotted. We could probably reduce the number of vanilla ore configs by collapsing presets into a few shared files (or a more dynamic module that provides ore configs) - but it needs some rework and understanding of how different maps work. I understand if this is something you dont want to invest time so we can leave it for the future

[lex]

The follow-up is up as #1573 — it went a bit further than the two duplicates: a shared main-ores factory now holds the canonical tile sets and ratio mixes once, with nine configs derived from it (all byte-identical to before, one commit per config), plus the 4-ore minimum asserted at map creation in the Tetrominoes/Voronoi layouts and a test suite over all the ore configs.

[RedRafe]

Good for me, I havent tested the map but seems to be working. Passing the PR into @grilledham 's hands for an accurate revision/approval after the last comment is addressed.

Thanks @lex :D

[lex]

Note: once #1573 (the ore-config factory) merges, this branch will be refreshed against develop and CI re-run. No changes expected here — City Blocks consumes config.vanilla_ores by require and carries no ore numbers of its own, so it picks up the factory-backed config automatically.

[RedRafe]

Good to go, thanks! :)

[grilledham]

LGTM. Thanks for the contribution.