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 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.
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"
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.
fixup end of scenario saves
iceiceice writes: does anyone know why we have this line?
https://github.com/wesnoth/wesnoth/blob/master/src/play_controller.cpp#L752
it causes end of scenario saves to be stripped of all units
my theory is that it was for some point in time before carryover was implemented properly
i propose to remove it in 1.12 and master
AI0867 writes: See commit aa2cf7d.
Looks like the carryover refactoring might have made it do the opposite of what it used to.
maybe_do_init_side and do_init_side both required a team_index
argument, which was always player_number_ - 1, (checked this with
assertions and playtesting), and which was available in the class
which defined them
this is intended to fix
1) an error messages in stderr when reloading a game related to
synced_context: (the original game called random ... times ...)
2) reloading a save with init_side_done = no
Now the game ends on all client at the same time even with victory_when_enemies_defeated_= no.
previously in mp the attribute victory_when_enemies_defeated only prevents victory for human sides but doesn't prevent defeats. This means in a simple 1vs1 Mp game with victory_when_enemies_defeated=no when side 1 gets defeated, Player 1 will get the "You have been defeated" message and for client 2 the game continues. I tested with adding victory_when_enemies_defeated =no in 2p_Arcanclave_Citadel.cfg.
When side 1 looses (leader killed) (during side 2' turn) the following happens:
[list=1]
[*]side 1 gets a "you get defeated", side 2 continues
[*]when side 1 checks "end scenario" side 2 gets a "side 1 has left the game... reassign controll to ai/human/idle/..."
[*]I clicked "controll by human" on client 2
[*]I ended side 2's turn and continued playing side 1 on client 2 and didnt get defeated
[/list]
I am sure that this is not the intended behaviour.
this commits also effects when "enemies defeated" is fired accodignly so it is fired on all clients at the same time like any synced event.
This is the result of running this command in directory src/
find . -type f -exec sed -i 's/\(ERR.*\)\\n\"\;/\1\" << std::endl\;/g' '{}' \;
and carefully inspecting the results.
If we decided it was worth it to inline map_location ==, then
surely this is also worth it to inline null_location, as the
compiler may be able to reduce tests for == null location to
"x == ... && y == ...", without having to move to a different
compilation unit.
This is a minor change to victory_when_enemies_defeated condition.
Old logic: If there are no not defeated sides which are enemies
of eachother (i.e. there is still a battle going on),
BUT victory_when_enemies_defeated = false, and either we found
a not defeated local human player, or we are a multiplayer observer
(there are no locally controlled sides), then don't end the level.
New logic: If there are no not defeated sides which are enemies,
BUT victory when enemies defeated = false, and EITHER we found a
not defeated local human player, OR there is a not defeated remote
human player AND no local human side assigned at all,
then don't end the level.
I think this more precisely the behavior we want. is_observer
doesn't belong in this function, and with the introduction of
defeat_condition, UMC will pretty much always be able to get the
behavior they want, so I'm much more comfortable to introduce this
change now than I would be otherwise.
[side] now has an attribute defeat_condition which can be "no_leader"(default), "no_units" or "never"
"no_leader" behaves liek it behaved before.
"no_units" behaves like fight_on_without_leader=yes behaved before
"never" is new and causes the side to never get defeated, this usually means the scenariodesigner has to end the scenario with [endlevel]
