(even if never populated) rather than only the needed cache. The index was also never reset for the lifetime of the program.
This new design uses a hashmap based on the locators themselves.
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]
```