> wanted players to study in advance

I was that close to commit my patch when it sink in that this use-case might be the reason startposition assignment has not been using mapseed. While you may want terrain to be known to everyone, at the same time you may don't want to give up where other players start.
But is thuis use-case obsolete anyway now that we have "reveal map in game start" -feature?

> But why do you think games where first map generation success
> with random seed are reproducible?

I think I must have been thinking of games with explicitly set mapseed, although I didn't make that clear.
For some reason in my autogame script I explicitly set both gameseed and mapseed for a new run.
More generally, the main case I see for only setting one seed is gameseed=0 mapseed=<chosen>, if you've got a randomly generated map you really liked, or wanted players to study in advance or whatever. That doesn't work right now if the mapseed triggered a retry.

I agree that with mapseed = 0 but explicitly set gameseed, you can't currently expect to get reproducible results regardless of retries.

That generally seems like an odd configuration to ever use, given that with a different map the game will go differently anyway. Is there any reason why mapseed shouldn't follow purely from gameseed without the time() factor?

My patch has reproducibility problem in my own regression testing use-case. I use random seeds to get different games, but log those seeds carefully for using in reproduction of the problems encountered. But with my patch main random state goes one step forward (to produce mapseed) when mapseed is initially zero = for original testrun. Once one sets mapseed explicitly to same value, gameseed does not proceed.

> Which I think means any autogame where the first map generation
> failed will not be reproducible.

Uhm, I've been setting also mapseed for some time for reproducible games as I've had problems with gameseed only. And this may explain why. But why do you think games where first map generation success with random seed are reproducible?

Hm.
Not directly relevant to the patch (which seems like a fine idea), but the random Lua-generated labels, it would be kind of nice if they were generated from mapseed rather than gameseed, so that if I pick a mapseed I like, I get fixed labels as well.
But would it perhaps be too much to force every Lua function hooked off the "map_generated" signal to get mapseed-derived randomness? If we did, we'd want to ensure that game-start events could have access to gameseed-derived randomness; is the ability to hook onto the turn_started signal sufficient? I'd rather not explicitly expose two different random sources concurrently to Lua.

There must be some problem in how main gameseed is restored after map has been generated (note that it's already restored by the time map_generated lua signal).

Actually, if restoring of gameseed worked like it seems to be designed, our new 2.4 feature of trying to generate map with different seed if first fails would not work. The map generation random seed would be the same on the second attempt as on first if main gameseed would have been succesfully restored after first attempt.