Generating the chackup data before sending the action
means that other clients would have the checkup available.
(if the "default_checkup" is used the "mp_debug_checkup"
also works after the action is sent). Note however that
its very possible that the action was already sended
before this code is reached, in those cases this change
will have no effect.
This also removes some outdated comments. In
particular sqashing undo actions into one (like
a comment suggeested) would probably bring the
undo stack out of sync with the replay stack.
Not having the shroud updated while dsu is disabled
could lead to shroud not being updated at all or worse
It is a bit annoying to works on code that should actually
be removed (DSU), but the whiteboard still doesn't work perferctly.
We don't want to return from play_idle_loop() when
the game is waiting for a [init_side] or [end_turn].
These actions should be delayed until the side has a
real controller.
1) Renamed !can_undo -> undo_blocked
2) We now automaticially clear the undo stack after every
action that blocked undoing. Since the playturn code
checks undo_stack::can_undo() to check whether to send
data or not this should make it more robust against
errors caused by unsent turn data.
This caused the end_turn button to remain 'pressed' when
using "Replay from turn".
There are now two variables end_turn_requested_ which is
true when the end turn button was pressed, and
end_turn_forced_, which is true when [end_turn] was used.
The later is considered part of the gamestate, to it is
stored in savefiles, the first isn't.
Alternatively we could make sure the synced action that
invokes the [end_turn] ends the turn directly instead of
using a seperate [end_turn] action for that.
But then we'd need to come up with a way to notify the
server about the turn change. (which wouldn't be hard
though, we'd use a similar mechanic as we aleady use
for side changes done by wml)
This function also was missing a send_data() call to send the
last action (which probably caused the game to end), i actually
don't know how this passed the ./mp_tests before.
(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.
