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.
