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?

[RedRafe]

Shouldn't theses be computed from danger_ores/config/*_ores.lua?

I think it would be better for reusability if this module could accept ore config as input to be reused in other presets

[RedRafe]

for allowed entities, I think it would be better for mod compatibility if it was whitelisted by LuaEntity::type and not by LuaEntity::name.
Also, you could look at entity_placement_restriction module that already implements entity destroying/saving, just need to pass the validation function to it which you already have

[RedRafe]

Adding this comment here but I think it covers last 5 maps: each maps doesnt necessarily need a new ore config, especially if it's vanilla.
Having 4x files with same vanilla ore distribution (iron>copper>coal>stone) does not carry any benefit, especially if we decide to tweak ore percentages, having 1 file with all the ore numbers is easier to maintain.

Evaluate if it's possible to remove the latest ore configs in favor of using vanilla_ores.lua (yes, stone is "missing" but stone is not really used aside from SpaceAge

[RedRafe]

Not sure what the usage of data.generated is since it's only read and assigned once here and nowhere else. on_init functions will only run once on_init so no need to check that, can simply pass Event.on_init(assign_ores)

[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