This commit changes the resources::game_map pointer to a const *,
so that changes to the game_map coming from lua or wml apis must
go through the game_board. Three functions were moved into the
game_board -- although substantively they did not change, there
were minor changes, in terms of the kind of error reporting done,
and also in how gui refresh orders are issued afterwards. In
testing the differences due to this refactor don't seem to be
noticeable.
This reverts commit 2f8b997cb8a093b71a54a64e47b3c9d4a826885f.
This needs to be redone in a less sloppy way that doesn't functions not
returning an actual value per their declaration or mass code
reindentations.
Slightly fewer units in scenario 1 on hard
Deep One has more hp/attacks depending on difficulty
Less income available to player on hard in scenarios 1 and 2 to
decrease gold available in scenario 3
Added a define to make it easier to make Garak killable in scenario 3
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...
