Two missed observations:

• the Player.cpp code is only executed when the user clicks on the Player tab the first time.
• the scenarios/_blank.xml supplies the default civs the default civs initially

We can derive a rmgen/ reproducible bug from that:

1. Start atlas
2. Do not click on the player tab
3. Load a skirmish or scenario map that doesn't specify civs, for instance Acropolis Bay (2)
4. Generate a random map that doesn't specify the civs

Then we get the player civ undefined error in rmgen/player.js that was previously muted with the FALLBACK_CIV.

Conclusion:

• The _blank.xml map ought not to duplicate default values when we have a different place we load default values from at other times
• Instead of reintroducing the FALLBACK_CIV workaround, Atlas should always load the player_defaults.json

If someone wants to raise a concern I wouldn't disagree. Even though that this bug existed since the introduction of rmgen in atlas and was just hidden with that rmgen FALLBACK_CIV.

There are many places where the defaults could be implemented

• rmgen/ (sounds wrong, it should be the gamesetup instance in all cases)
• MapGenerator.cpp (sounds wrong for the same reason)
• Atlas GUI function calling the mapgenerator
• Atlas non-GUI function called by the atlas GUI function
• Atlas mapsettings loader code independent from the maptype

I have to look deeper to find the right solution.