Steps to reproduce:1. Start the new game using the latest (2026-09-17) Nightly executable with pak128.Britain-Ex.
2. Try to create a map with default settings.
Expected result:A new map is created.
Actual result:After ten minutes, the game is still frozen.
A Discord user reports (on Windows):
QuoteIn log, the last entry is
Message: simmain(): Creating cities ...
Warning: stadt_t::random_place(): Not enough places found for cities.
I couldn't replicate that error message on Linux, but maybe my logging level wasn't low enough.
ObservationsThe bug has been reproduced on both Linux (SDL2) and Windows.
The bug does not occur using the Linux (SDL2) executable created by the last commit in the ci-repair branch (https://github.com/jamespetts/simutrans-extended/commit/6844225012c297c78c787ca8642e4be78754a215), available from GitHub Actions (https://github.com/jamespetts/simutrans-extended/actions/runs/33998877206#artifacts).
Github issue created (https://github.com/jamespetts/simutrans-extended/issues/685) here with some concrete suggestions for solutions (the code cause is unknown but the root cause is almost certainly an AI bot being let loose on production).
In my case, the log filled with messages about creating dirt roads (since the date was 1750) and then stopped logging at all while the game hung.
I think it might make sense not to speculate about the nature of the cause until the cause is found.
Thank you both for the report - now found and fixed in the latest CI builds (and the server's nightly builds should have the fix to-morrow).
I am in the process of setting up a new automated map generation test to run with the CI to prevent this sort of failure from occurring in future.
I think threaded code should never alter the objlist or the whole threading becomes pointless since you are using a global semaphore. Either each objlist gets their own semaphore (might be a memory overhead of a byte or more per tile) or that part of threading code altering the map needs to be fixed. Because, with a global semaphore (like included in your atomic statement) the code would mostly wait for other threads whenever accessing the objlist, negating all threading advances.
(Unless I got this wrong, somehow, the verbose commetns and multiple defines do not really help to make it very clear).
Progress so far! The mapgen hang seems fixed and it's no longer impossible to generate a map.
However way building seems much slower than usual, and fills the log with identical messages about way_builder_t::init_builder(). Generating a large-ish map with 50+ cities takes >10 minutes.
Quote from: prissi on September 18, 2026, 04:51:37 AMI think threaded code should never alter the objlist or the whole threading becomes pointless since you are using a global semaphore. Either each objlist gets their own semaphore (might be a memory overhead of a byte or more per tile) or that part of threading code altering the map needs to be fixed. Because, with a global semaphore (like included in your atomic statement) the code would mostly wait for other threads whenever accessing the objlist, negating all threading advances.
(Unless I got this wrong, somehow, the verbose commetns and multiple defines do not really help to make it very clear).
After a lot of puzzling over this I think I'm finally on this same page. Previously for whichever reason there were massive and benign race conditions everywhere in code, and now that the bot solved these, mapgen is effectively singlethreaded and bottlenecks massively on its most parallel task, building ways (rivers and roads).
The obvious naive solution I
think would be switching from a single semaphore to a list of hazard pointers, since while there are hundreds of thousands of objlist objects, there is a much smaller number of threads and therefore it would avoid memory overhead while allowing multiple objects to be accessed simultaneously. However this would involve ripping apart some very low-level and important code, it would have to avoid deadlock, I don't actually know how many threads Simutrans runs (is it just the CPU thread count or is it hundreds?) and I don't have nearly enough multithreading knowledge to be confident about anything I say about it.
Quote from: martin509 on September 18, 2026, 12:19:55 PMProgress so far! The mapgen hang seems fixed and it's no longer impossible to generate a map.
However way building seems much slower than usual, and fills the log with identical messages about way_builder_t::init_builder(). Generating a large-ish map with 50+ cities takes >10 minutes.
Thank you for your report. From what I can tell, this was not a new issue introduced with the latest fixes. The AI found a bug dating back to 2017 that caused city rulesets not to be read properly that would sometimes cause an extreme number of retries at generating town tiles: this is now fixed. A consequence of this fix is that town generation is now correctly fully based on cityrules.tab again.
Second, a further optimisation was introduced that improved town generation speeds further by caching locations where roads/buildings cannot be constructed. This reduced the map generation time in one test from 86.8 seconds to 72.1 seconds.
These fixes/changes are now on the master branch.