my biggest concern is the artery roads. Installing E6, E4, E20, E18, E45 and E39 with 2-way roads is going to be hugely timeconsuming
Doing it only once would be preferable. I'm probably on version 50 now on the heightmap, so lots of resets.
But I suspect the game has a few issues here. I've noticed that town generation aims for the assigned location, but sometimes throws a town to the side to make them fit. This obviously wouldnt work with the roads, so it would probably have to be more like saving road data from a scenario/save and loading it back in - but then the heightmap/generated map has to match the saved road.
But industry import would help - and seems more feasible.
Claude looked at the code and found this:
Code: Select all
The short answer: technically feasible, but significantly harder than town importing.
Here's why, broken down:
What works in your favour
The existing CmdBuildIndustry command already has a special mode for the scenario editor. Many of the normal restrictions — such as raw industry construction rules and probability callbacks — are explicitly bypassed when _game_mode == GM_EDITOR. GitHub So the placement machinery already exists and is already permissive in the editor. You wouldn't need to invent a new placement path, just a new JSON loading front-end that calls it in a loop, similar to how town loading works.
The complications
Towns are simple: a name, an x/y coordinate, a population target, and a city flag. Industries are considerably more complex:
Industry type is NewGRF-dependent. The town importer uses a generic "name" string. An industry importer would need to reference a specific IndustryType integer — but those IDs shift depending on which NewGRFs you have loaded. You'd have to either use canonical vanilla type IDs (fragile) or some kind of NewGRF label/string lookup (much harder to implement).
Layout selection. CmdBuildIndustry takes a first_layout parameter GitHub, which selects the tile layout variant. This would either need to be specified in the JSON or randomised at placement time.
Placement can fail silently. The town importer already warns that towns sometimes can't be placed if no flat tile is found nearby. Industries have even stricter terrain and proximity requirements — some need water, slopes, or specific tile types — so failure rates could be high on rough heightmaps.
No existing PR or discussion. There's no open PR or feature request for this in the OpenTTD repo. The original town importer PR author explicitly mentioned that the optional next steps like importing trees, rivers, and objects were left out to keep the PR manageable GitHub — industries weren't even mentioned as a next step, suggesting the complexity was noted.
What a realistic implementation would look like
A JSON format along these lines would be the minimum viable design:
json[
{ "type": "coal_mine", "x": 0.312, "y": 0.445 },
{ "type": "power_station", "x": 0.318, "y": 0.449 }
]
Where type maps to a string name that gets resolved to an IndustryType at load time — but building that string-to-type lookup in the C++ source is the bulk of the work, since it doesn't currently exist for industries in the way town names work.
Bottom line: It's a reasonable PR idea, probably around 2–3× the effort of the town importer, with the NewGRF type-resolution problem being the main design challenge that would need community agreement before implementation.
Either way, this is not something I can or would try to do. Just askin'
