Previously the behavior was the following:
- When the "Back to Turn" button was pressed in SP, The gamestate is
reset to the gamestate of that turn.
- When the "Back to Turn" button is pressed in MP, The gamestate is
reset to the gamestate of that turn and a replay is started
replaying the game until the current gamestate (using the usual
replay UI). This is in particular useful to replay the enemies
moves (for example in case you were afk)
Using the MP version also in SP will not only also give
the campaign player a quick way to review the enemies turn,
but also allow the player to restart the gamestate from an
arbitiary point (instead of just the begin of the turn) by
pressing the "Continue from here" button in the the replay
Furthermore, the Autosaves can still be reloaded normally via
the usual Load game menu.
This might need some finetuning based on feedback, in particular:
- Should this be optional, via a game preference?
- Should the 'replay' start in a paused state instead of replaying
right away like it does currently?
- Should we allows addons to disable this feature (in case that
they know that their addon breaks replays)?
- Or when a huge majority of players dislikes this we can also of
course easily revert it.
Previously It used the default error handler, which asserts (which
makes sense since it executes actions right after they were evaluated
by the ui). For executing commands from the network a custom error
handler is used aswell.
We fix this by giving a custom error handler which shows an error
message instead.
I am not completely sure whether it is safe to use 'Back to..' during
events/actions. The exception would mess up the current gamestate
but the current gamestate is replaced anyways.
We now check that the loaded file is in fact a previous gamestate from
the same branch, we do that by checking the [replay] data, We
_could_ in theory additionally check the [replay_start] but i think this
is pretty safe.
It was agreed on that [end_turn] during turn end events ending the
next sides turn is counterintuitive and undocumented behaviour.
Note that it is always possible to end the next sides turn by
spawning an event:
```
inside a turn end event...
...
[event]
name = "side_turn"
[end_turn]
[/end_turn]
[/event]
```
We improve can_execute_command for the entturn button, and replace
button->enable calls with set_button_state/queue_rerender calls
This is more robust in case someone else wants to update buttons.
We remove a call to button->enable in playturn.cpp which probably had
no effect since the linger mode for the clients automaticially ends
there already.
We create a new function to check set to gui to linger mode or not,
in particular is removes the linger overlay in init_scenario, in case
that we want to reset the replay from linger mode.
While the idea was good, the implementation was a bit confusing, in partuclar its unclear why it used SDL semaphones instead of a simple int counter (like
command_disabler). (Also a std::function over a class method function pointer would be better). Also it supported the delayed
save in certain cases. For a new implementation it'd probably be easier just to checek whether a save was requested at certain safe points.
This function made no sense since it invalidated the tiles with
overlays depending on which side is currently playing, but the
overlays don't depend on the currently activive side, but rather
on which side is currently viewing the game.
carryover_show_gold not only shows the carryover message but also
calculates the carryover amount and stores it in the team object.
So omitting this call will result in wrong carryover data when the
observer saves the game in linger mode.
Furthermore carryover_show_gold seems to support generating messages
to observers alredy.
The main intention is to move the linger mode into the
loop so that the replay can play until linger mode
is reached. In particular to allow replays to show
victory events aswell.
Instead of having variables init_side_done_, linger_ and the
END_TURN_STATE enum, we now have more possible states in
game_data::PHASE enum and a boolean end_turn_required_
variable.
The intention is to make the code simpler to prepare a refactor
to move the linger code into the play_scenario function so that
the replay will be able to execute victory events.
It is still a bit arbitrary which variables are part of game_data
or game_state tho imo.
I'm pretty sure that both of these cases don't need special handling,
because playcampaign.cpp calls set_snapshot unconditionally after
play_scenario.
The commit that added these calls is also quite old and
the code has been refactores multiple times since then.
Fixes an issue where the licensing terms would be empty when
interacting with a campaignd instance that has no [server_info] at all.
The previous method to retrieve [server_info] resulted in all the
defaults being ignored if the tag itself was missing in the config file,
due to poor logic to avoid the dreaded "Mandatory WML child missing yet
untested for" error.
This removes the non-const version of the method since it's unused,
will never be used, and would need a different implementation anyway.
Honestly this method is pretty pointless since it's only used once
during startup.
