we have one events_disabler when starting the replay_controller and a
second when entering the synced context. Thats why we have
events::commands_disabled == 1 and >1 when we are executing an action.
get_user_choice usually shows a dialog to the user. Because we shouldn't
use the screen during prestart events i disabled it there.
this commit might contain spelling corrections.
when a player chats while multiple actions from another player are
executed on the local machine we before got an assertion error becasue
replay s add_command expects that there are no other commands yet to be
processed on the replay.
(this was broken at da4cdef146bf5a1b8026f12d6b1caa6c1cd20602)
we now fix this problem by ensuring that there is never more data on the
replay than needed.
for this purpose i wrote that playturn_network_adapter.cpp whose main
purpose it to split incoming [turn]s into smaller [turn]s
we also don't need the backlog anymore because now with playturn_network_adapter we only feed process_network_data with small data pieces that can always be handled at once.
I also removed the replay_ member of turn_info.
Before, we read actions from replay_srouce and wrote actions to recorder.
And after the actions in replay_source has been executed they had been pushed into recorder.
With get_user_choice this doesn't work, because we might end up pushing the 'answer' (the user choice) of a get_user_choice in the recorder while the 'question' (the invoking user action) was in replay_source and then would be pushed onto the recorder after the 'answer', leading to a wrong order in the recorder. This could maybe also have been fixed by always pushing user choices into replay_source, and syncing the replay_source somehow after we enter a user choice, but the way it was done in this commit seemed easier.
note that replay_ and backlog were already made unused in da4cdef146bf5a1b8026f12d6b1caa6c1cd20602 (that was a rather uncomplete commit)
We maybe (i didnt test, just a guess) could also fix this bug by using add_nonundoable_command instead of add_command for nonundoable commands in replay.cpp with add_nonundoable_command defined as:
config& add_nonundoable_command()
{
auto c = cfg_.add_child_at("command",config(), pos_);
pos_++;
return c;
}
One reason why i decided against it is, that i feared add_child_at to be slow (vector::insert) if there are a lot of entries in cfg_ (for example when we join game that has already run may turns).
With the playturn_network_adapter this shouldn't be an issue anymore, but it also isnt needed anymore.
Before this, 'faction' and 'gender' were not used if 'force_lock_settings'
wasn't set to 'yes'. This resulted in inconsistent behaviour between the
mentioned two attributes and 'type' attribute. When 'type' was set, the relevant
leader was always selected by default.
This partially fixes bugs #21753 and #20562. To properly address them, it might
be needed to add 'faction_lock', 'type_lock' and 'gender_lock' attributes so
that UMC authors would have a way to actually lock these selections without
using 'force_lock_settings' if they don't want to.
It’s slow for finding units with moves or attacks left. The
alternative method of getting all units and then looping over the table
with a condition is much faster.
It’s slow. The inverse logic using table.insert is much faster,
especially for large tables. Only kept table.remove in a couple places
where it doesn’t matter.
I forgot what my real intention with this change was, but i still think this is a good change, becasue now people don't have to look up the comments to see what do_replay returns.
So i committed it.
During the synced context we are in a state 'during an execution of an
event/action' that the savefile format cannot cover. So we use
command_disabler to prevent saving.
since idle sides don't get initialized until someone takes control
this alleviates 21459. it might possibly aggravate 21397, if that
bug is not fixed by correcting save files with unintialized sides
1. sides without leaders aren't defeated if
"fight_on_without_leader = true". don't use no_leader
for this purpose anymore.
2. refactor to use a std::set instead of std::vector,
and some related improvements, for what was formerly
the "seen_leaders" data structure
this field is intended to allow battles to continue after the death of a leader
if a side has this flag enabled and any units alive, they will be considered
to have a leader regardless of canrecruit.
