wmi_manager::set_item would replace a wml_menu_item object with a new one whose state was copied
from the old, but the old one was destroyed *after* the new one was constructed. That means when
the new object (and hence the new record) was created, it would not update the entry in the master
hotkey command info list, since the old still existed. The old object (and its record) would then
be destroyed, performing cleanup in the process, and resulting in the bug.
A new wml_menu_item object constructed from the state of the old one now takes control of its
record as well, so the new object has sole control over its lifetime and the hotkey info can be
appropriately updated.
The code checked for `unit.attacks_left() >= attack_count_` even
though _currently_ it seems perfectly legal to invoke an attack
with less attacks left (see the discussion on #7406), although this
will probably be changed soon.
If this is changed in the future, before changing that assert
remember to also change the check in attack::check_validity.
Also it didn't reset the attacks in attack::remove_temp_modifier
properly.
* Revert changes in 91983c8
* Revert changes in 6551584
* Revert "Solve OOS by moving code to synced event"
This reverts commit 040550f0a6e3127505796ea120653b299c424cad.
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.
