Completely restoring the game state from the savegame
Even if we couldn't have such a support enabled by default, having it at least optionally would be a big help. Use-case here is the autogame testing. If my testing environment would have such a feature enabled, I could (in many cases) reproduce issues from the latest savegame within minutes, instead of each debugging iteration taking twelve hours to run from the beginning of the game to the point where the issue occurs.
First to create required random number facilities: #47667
alain_bkr Reply To cazfi
If my testing environment would have such a feature enabled, I could (in many cases) reproduce issues from the latest savegame within minutes, instead of each debugging iteration taking twelve hours to run from the beginning of the game to the point where the issue occurs.
I understand mapseed, which always give the same map (all other parameters unchanged)
Do you mean that currently, it is the same for gameseed (or some other parameter) and i can replay one game identically given the initial seeds ? or at least one turn if i know the "turnseed" ?
Reply To alain_bkr
it is the same for gameseed (or some other parameter) and i can replay one game identically given the initial seeds ?
Yes, autogame from a .serv file that sets gameseed to value other than zero runs identical if used with the same server codebase. At least as long as you use classic AI, and not any threaded ones (e.g. tex) that can cause things to happen in different order.
alain_bkr Thanks , i understand why my tests with S3_1 autogames seems to be absolutely reproducible, even from a saved game. (and resist several patches, and run on another computer)
Naive question 1 : adding a 'random' section for each thread (each AI) could help ?
Naive question 2 : i was wondering of AI as a client , which would avoid all thread problem, just run a different process, and let the OS manage parralelism and the server control correctness of AIs actions ?
alain_bkr)
Reply To alain_bkr
Thanks , i understand why my tests with S3_1 autogames seems to be absolutely reproducible, even from a saved game. (and resist several patches, and run on another computer) * i have only ai classic (i tested threaded and see mostly no speed difference so ...) * gameseed and mapseed are in the .serv file and in the saved game, along with a 'random' section. Naive question 1 : adding a 'random' section for each thread (each AI) could help ?
Not really. The issue is in how threads proceed in relation to each other, timing wise. Consider next two runs, from the same starting point (randseed). Not sure if this exact example is even theoretically possible with current codebase, but it should reveal the principle.
1. Main thread wins a race, and reports enemy unit movement to the threaded AI
2. Threaded AI sees that enemy unit has moved closer when it considers threads to its city -> goes for strengthening defenses
1. Threaded AI wins a race, and considers threads to its city. As there's no enemies close by, it goes for strengthening economy
2. Main thread reports enemy unit movement to the threaded AI
Naive question 2 : i was wondering of AI as a client , which would avoid all thread problem, just run a different process, and let the OS manage parralelism and the server control correctness of AIs actions ?
That's something I did 1998, as a project of my own, before joining actual freeciv team :-)
Other people have run similar projects later.
So, while it's technically a good idea, we are still to see someone who can easily sink thousands of working hours on it initially, and then keep on maintaining it from freeciv version to the next.
Some randseed logging utilities to enable this work -> #47667
In the very early days of the freeciv project debugging was made significantly easier by the fact that the bugs were much more often reproducible from the savegames - the bug you encountered during regular run could be reproduced by loading previous savegame and doing the same actions as in the original run.
It required some work to maintain that state of things - that loading the savegame would produce the same state (especially that of the random number generator) as what it was during the original run. Eventually it broke more permanently, over twenty years ago - I remember that I had filed a bug report about the final breakage before moving to another city in early 2001.
Maybe we should revisit the issue. It would be very beneficial to have that reproducibility working, and it might be more feasible to fix now than back then. We could, e.g., include more data to the savegame these days, without the size of the files becoming a problem.