we don't want to expose the fileds "snapshot", "carryover_sides".
instead we only add classification, and mp_game_setting to resources
which are members of game_state.
in order to do that, we have to add a do_autosave method to
play_controller.
this commit also moves some code from game_state::write_snapshot to
play_controller::to_config which was intended to be in a different
commit.
This commit manages to purge all references to resources::teams
and resources::units from the turn_info object, by moving
functionality to game_board, or refactoring to use const &
accessors.
This is not a strict refactor, but I had my hand in the earlier
state of this code anyways, and I have playtested the new version.
This is a refactor to introduce an object encapsulating the unit map, the game map, and the list of teams. Introducing this object permits us to move a substantial amount of code out of the play_controller object, and also to give a home to some helper functions in unit.?pp that previously sat in the global namespace. It also allows us to simplify the construction of some of the clients of play_controller.
This refactor is ongoing WIP. The goals are
(1) better organize the architecture of the engine, to make saving and reloading easier.
(2) Facilitate the introduction of an improved pathfinding mechanism, which will need to sit between most of the other engine modules and the unit map / game map.
(3) Refactoring clarifies what the existing code is doing, therefore it may help us to find bugs in the current system, which may be fixed independently of the refactor in 1.12.
"parent" is a leftover from a feature that was planned 5 years ago but
was never implemented. To have something like a "tree view" for
savegames in the load dialog.
"parent" gets written but never gets read.
The current code writing the "parent" doesn't really work because it is
only takes the name of the last savefile unrelated of whether there was
a reload, or similar between so for example a "parent" of an sp campaign
save could easily be a mp match save. Also it could produce cycle which
would also be wrong for a tree view.
Unit tested and playtested after moving the functions decalarations,
and definitions, adding links to play_controller::game_board from
resources.?pp, and executing find and replace commands:
git grep -lz 'find_visible_unit(' | xargs -0 perl -i'' -pE "s/find_visible_unit\(/resources::gameboard->find_visible_unit\(/g"
git grep -lz 'get_visible_unit(' | xargs -0 perl -i'' -pE "s/get_visible_unit\(/resources::gameboard->get_visible_unit\(/g"
This is not a strict refactor -- the game map will also be reset
to the starting configuration now, when we reset the replay. It
doesn't look like this was the case in the old version, so it's
possible that if a scenario used [replace_map] or similar, the
replay could go out of sync after hitting the reset button.
Regardless of whether the old version was buggy, the new version
should be just as good if not better, and was tested.
mp linger mode was not properly setting the completion status,
as sp does. This caused mp end of scenario saves not to end up
in linger mode when they are reloaded.
Note that this reopens bug 15545 (!)
https://gna.org/bugs/index.php?15545
In 1.11+, I believe that the correct way to fix that is to save
the [carryover] while in linger mode, and restore it on reload,
however this is for another commit...
Test was calling the wrong function in place of to_double. Also
fix up an answer value after this.
Fixes up commit 7cd205832f34098375aff05e34a12c37f16046d5
For now this will just help us to put code in logical places and make
the save and load process simpler. This change is invisible outside
of play_controller.
Please don't backport this to 1.12.
