That huge block in pull_remote_choice existed becasue we don't want to
return becasue we dont wan't to make choices for sides that we only
controll temporary.
With the 'new' idle controller type this can be simplyfied by just not
making choices for idle sides.
The functionality of tracking observers and displaying chat messages
is moved to a manager class, which the gui owns.
The functionality of displaying notifications is similarly moved out
of the game_display and to a private namespace. (Static singleton
pattern seems okay here since there really won't need to be more
than one of these for a single application, it seems.)
we already clear the undostack after an action if data was sended over teh netwrok (we call synced_context::can_undo to check) so there is no need for the call here.
the comment in replay.cpp says we want "send data to others" so
calling "pull_remote_user_input" is not really correct. I added a
function synced_context::send_user_choice for this case.
this fixes a bug where players can get an oos error in
wesnoth.synconize_choice
I backported a simpler version to 1.12:
0e79ef919f5718cd8024bbbac31ed1e7b67e4fc7 because i don't know whether
this bug can happen in 1.12 too.
This function required the use of resources::game_map, so properly
should be a method of game_map. This will help us to make sure that
such functions work when using either the editor or the play
controller, or the replay controller, and generally improve
encapsulation.
maybe_do_init_side and do_init_side both required a team_index
argument, which was always player_number_ - 1, (checked this with
assertions and playtesting), and which was available in the class
which defined them
This is the result of running this command in directory src/
find . -type f -exec sed -i 's/\(ERR.*\)\\n\"\;/\1\" << std::endl\;/g' '{}' \;
and carefully inspecting the results.
we now add nonundoable commands at the current position instead of
assuming
at_end(), this way nonundoable replay entrys like speak can now also be
added
while we are not at end.
Usually playturn_network_adapter ensures that we are always are at_end()
and i didn't get any error with the previous solution but the new
solution
is just more robust in case something goes wrong.
Note that we cannot add nonundoable commands at end if we aren’t at end
because
in that case the user would see the message again when he replays it.
Note that we cannot just do this for normal command because it might
bring the
replay in disorder.
instead of giving an assertion error after the OOS message we now
1) ignore dependent comments when we find them but didn't expect them
2) save commands for later when we find them while expecting another
dependent command. In this case we try to get a correct dependent
command by querying the user.
after we showed the OOS message ofc.
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.
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.
Previousy, the [side]'s in level_ were updated with controller changes,
so that observers who join would be up to date, since controller changes
were not stored in history. We now change this, so that controller changes
are stored in history.
These are stored as "[record_change_controller]" tags rather than
"[change_controller]" because during a replay we should not
restart the turn and reinit in the event of such a change.
This is in preparation to move all controller tweaks to server-side.
i already wrote another version of that code in actions/attacks.cpp
thats uses get_user_choice for advancement choices.
the only function left thats used dialogs::advance_unit was the code for
the :unit advance=n debug command, now that code uses
attack.cpp::advance_unit_at too.
thsi code used the variable is_simulaneously, is_simultaneously_ is true
when we have aready sended data over the network, this variable is used
in get_user_choice so that when we make a local choice we only send it
immediately over the network if did already send data over the network.
luas sync_choice now takes a third parameter which is a array of number
that determines on which sides the function will be evaluated, if you
use this parameter you'll also get a table back, the passed function
will then be executed on all passed sides simulaniously (you don't have
to wait for the other side before you can make your input) example:
[code]
[event]
name = "start"
[lua]
code = <<
local result = wesnoth.synchronize_choice(
function()
local option1 = T.option { message = "No", T.command { T.set_variable {
name = "input1", value = "No"}}}
local option2 = T.option { message = "Yes", T.command { T.set_variable {
name = "input1", value = "Yes"}}}
wesnoth.fire(T.message{ message = "Are you sure you want to play this
game?", option1, option2})
return { value = wesnoth.get_variable("input1") }
end,
function()
return { value = math.random(30) }
end, {1,2})
wesnoth.message("Player 1 wants to play: " .. result[1].value)
wesnoth.message("Player 2 wants to play: " .. result[2].value)
>>
[/lua]
[/event]
[/code]
note, that wesnoth is still a turn based strategy game and it's most
likeley a bad idea to require user input from sides when it's not their
turn because they might be afk.
so it might be better to use it during [start] events
we replace lua_settop by lua_pushvalue because we want to be able to
call the function multiple times in case one controller controlls more
than one of the passed sides.
the old code used to execute one last [end_turn] after the end of the
replay was reached, This doesn't work because the wml might require
[message][option] or similar during "turn end" events and we don't have
the data for that.
i also replaced set_random_results/get_random_results with
synced_checkup in recruit_checksums in create.cpp.
i don't see a reason why we shouldn't use the checkup when calling
place_recruit from wml, since the wml is called on all clients. Just
like a normal recruit. (if we are in an unsynced context then checkup
doesnt have any effect anyway.)
in undos we have to do it differently in different actions becasue in moves we just show the move (ro save performance i guess) but in other actions (recall/recruit) we also fire the events again.
"Rest" means: lua_ai, disband, fire_event (right click menus), update_shroud manualy.
this commit is part of pr 121.
we use ignore_error_function to get the same behavior as before. that means we allow to pass an invalid recall and just nothing happens in this case. We also don't put anything on the recorder, because run_in_sycned_context removes it from the recorder if we weren't successful, as intended.
In order to get the same move results that we got during the game in replay, we now save continue_move/skip_sighed in the replay.
We also call move_unit now with replay_dest = NULL, is_replay = false during replay.
So during replays we now execute the same code, that we execute during the normal game. That also means that, the variable replay_ in move.cpp is now always false. which means there is some unused code now in move.cpp
i still hesitate to remove this code because it somehow seems to be too easy to do it like this, but i have found no bugs.
i suppose, that is_replay_ if a leftover from a time when visibility wasn't calculated normally during replays.
in a later commit i also put skip_ally_sighted in the replay data.
I don't use run_in_synced_context for moves because some methods use the returnvalue of move_unit. Instead i splitted move_unit into move_unit_and_recod and move_unit_from_replay, because using 'if' isn't possible for set_scontext_synced. And i don't want to record a move if nothing happend. Also i think a very small code duplicate for one 'if' less is a very fair trade.
this commit is part of pr 121.
