(fixup of 736ceaa6c7e81882c9c5b2e932307b1f1ecb3bfd)
Following discussion with Soliton, we move all "controller tweaks"
i.e. assignments of networked side to human on the matching client
at start of game, to be server decisions, performed concurrent with
start of game.
In fact the controller tweaks are performed using
game::change_controller, which is modified so that it doesn't try to
make server messages before the game has started.
When the server receives [start_game] from the host, the server will
call game::change_controller for every side, sending corresponding
messages to all players and observers, updating them as appropriate.
The server will also rewrite level_ so that human sides are "network"
and ai sides are "network_ai", making the level_ correct for any
observer who subsequently joins.
We remove the obsoleted client-side code in playcampaign.cpp,
multiplayer.cpp.
We also add to multiplayer_wait.cpp the necessary support code to
interpret [change_controller] messages recieved before game start.
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.
this fixes up commit cb9d69aff4a37c8325b2c126e243812f2d91cfeb where we
introduced the second checkbox. it turns out that there isn't space for
this in 800w resolutions (reported as bug #21888)
sync, attack events, start/prestart and more
sync attack events, sync start/prestart, fix gna.org/bugs/?20871, partly implement gna.org/bugs/?21697 fixing OOS related to [get_global_variable], unify the rng for attacks and other things, implement a third argument for wesnoth.synchronize_choice, implement the deterministic mode for sp. See https://github.com/wesnoth/wesnoth/pull/121 for full descrition.
the player can now choose whether he want to play a new SP game in the
deterministic mode where he'll get the same results when he reloads a
game.
i think it would also be nice to enable the deterministic mode for MP for players with verybad network connection, because that would result in less network traffic but more options to cheat.
but i currently don't know enough about the mp connect code to that.
I don't really know much about the gamestatus cpp/hpp file, so i just
copied from the difficulty code (to create the random_mode attribute).
I add the deterministic mode to the ui in another commit.
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.)
"from_side" is an attribute whose only purpose is to enable a check by
the server that a package is really sended by the side given in
"from_side", if thats not the case, the server sets an attribute
"side_invalid". The main purpose of this contruct is to disallow
cheating in mp.
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.
these commit uses the synced_context in replays in and in attacks.
we also don't need to use expected_advanaments anymore, because advancements now run through get_user_choice.
Which was not posible before, because get_user_choice didn't work during attacks.
the main intention of these commits is to fix gna.org/bugs/?20871, gna.org/bugs/?21697, some OOS erros related to use of multiple
[get_global_variable] with different sides in one event.
To remove the deterministic random for traits and similar as discusssed
here http://forums.wesnoth.org/viewtopic.php?f=6&t=39611. And to sync
start end prestart events.
the file synced_commands.cpp is mosty code moved from replay.cpp with the main intention to make do_replay.cpp smaller. But also to be able to call run_in_synced_context from non replay if posible,
so that we can just use the same function syned_context::run_in_scned_context that we call during replays, but in most cases this won't be possible.
the file synced_checkup.cpp was written to replace get/set_random_results from rnadom.cpp which was used to check wether unit checksums and attacks results match the ones in the replay. And wasn't realy related to random.
We also use the new random generator which is automaticly synced during
the execution of scned_context::run_in_scned_context, and otherwise not.
So we cannot cause oos anymore by using rand= from an unsnced command
like "select"
Alternativeley we can also set the new random synced by using the new
RAII object set_sconext_sycned, this happens for example during prestart
events.
Unlike the old random generator, the new random generator is not
determinstic by default because it asks the server (or itself in a SP
game) for a new seed, at every side command (attack, move, recruit ...)
that requires random ,similar to how the previous rand for attacks
worked (it doesnt ask at the beginning, just the first time it is needed
unlinke how attacks worked before). That way we can also unify the rng
for attacks and for other random choices.
this commit breaks ai's advancement aspects, i'll bring it back in a later commit.
this commit is part of pr 121.
by using set_scontext_synced and recording brefore doing that.
we split fire_prestart and fire_preload becasue prestart runs in a synced context and fire preload not.
we also dont need recorder.pre_replay anymore becasue of the changes to the rng.
the line synced_context::run_in_synced_context("auto_shroud", replay_helper::get_auto_shroud(true));
was accidently placed in this commit and should rather be in the commit called "use synced_context in undo and rest"
this commit is part of pr 121.
previously and afterwards there can be 2 ways an action(attack, rectuit, move...) can be executed, the first way is that the action runs on the local client, and the action is sended over the network as soon as it is completed, this happends in recruits, moves, recall, and some more. The second way is that the action is sended over the network first and is then executed on all cielents simultaniously, this happends in attack events, and similar happends in prestart/start events. This is also why mp_sync didn work in this actions before: side 2 noticed that it needs data from side 1 but side 1 did send the execeution of the action before it generated the user_input data. That's why side 2 doesnt have the user input data at this point. Previously there was one special and very bugged case when the code waited for remote input before calling get_user_choice: [get_global_variable].
This commit moves (and fixes) the "waiting" from persist_var.cpp into get_user_choice so that the caller of get_user_choice don't have to worry about it. With this we can also use get_user_choice if we already sended data over the network. And we can enable the mp_sync in attack related events and prestart events. The intention of this commit is to fix fix http://gna.org/bugs/?20871.
the plan is to sync start and prestart events, so we don't need to check for that anymore,
we also don't need to pass the rng because we can use call random_new::generator->..
this commit is part of pr 121
with the new synced_context system, the old code would bring code in the wrong order onto the replay if we received data during get_user_choice
which now could be called during turn_info::handle_turn.
also previous code would fail to process
[turn]
[command]
[move]
x = 3,4,5
y = 4,3,3
[/move]
[/command]
[/turn]
[turn]
[command]
dependent = yes
[input]
[/input]
[/command]
[/turn]
because [input] would be processed after [move] was processed, but
[move] need [input] on the replay to work properly.
(if luas sync_choice was called from a moveto event)
this commit is part or pr 121.
the plan is, that random_new::generator will be a object that does synced random calls during a synced context and otherwise not,
so that we cannot create OOS anymore by using random in unsynced actions like select event
the intention is also to unfy random calls for attacks and random calls and for other actions like traits and [set_variable] rand= .
the synced random generator will be set with the set_scontext_synced object.
the new rng will be similar to the old rng used for attacks becasue it will ask the server for a new seed for every new user action (=recruit, attack...) that requires random numbers.
Previously there were 2 different random generators, one for attacks, and one for other things, pr 121 is supposed to fix the problems with the "sending data over teh network first" an we try to throw the old rng for non attack things out. So that attacks and other tings use the same rng.
We use a new random generator which is automaticly synced during the execution of scned_context::run_in_scned_context, and otherwise not. So we cannot cause oos anymore by using rand= from an unsnced command like "select"
Alternativeley we can also set the new random synced by using the new RAII object set_sconext_sycned, this happens for example during prestart events.
Unlike the old random generator, the new random generator is not determinstic by default because it asks the server (or itself in a SP game) for a new seed, at every side command (attack, move, recruit ...) that requires random, similar to how the previous rand for attacks worked (it doesn't ask at the beginning, just the first time it is needed unlinke how attacks worked before). That way i can also use the same rng for attacks and for other random choices.
I also plan to move the code from set/get_random_results to syncec_checkup.cpp later.
this commit is part of pr 121.
