whether DSU (= delayed shroud updates) is enabled for a team is part of
the gamestate and toggeling it during a turn of a networked side will
cause OOS sooner or later. So we cannot toggle it then.
and for [store_locations] [store_starting_location] [store_unit_type]
see comment for 201d83f608 (fix [store_side] to allow explicit indexes)
As a side effect, this commit now also alows mode="replace"/"append"/default for
[store_locations] [store_starting_location] [store_side] [store_unit_type] which was
previously only possible for store_unit
The game sometimes does some checkup to test whether the calculated results in a replay match the ones calculated during the original game.
This data was stored in the replay inside the [command] for that action. The problem is that this doesn't work in networked mp because we often send the [command] before calculating the results.
I added an alternative mode that used get_user_choice to compare the results, this also works in networked mp but it causes a little more network traffic.
this commit also changed slightly the way that wml menu events
are synced. previously they were run via "run_in_synced_context",
now they are run via "run_in_synced_context_if_not_already", which
makes it safe to fire them from lua (a synced context).
adds a new method is_replay() to check whether we are in a replay.
fixes http://gna.org/bugs/?21906
Also also we make [do_command]/run_in_synced_context_if_not_already more
robust by checking is_replay
This line was not an error -- it is legal in C++ to bind a const
reference to a temporary value. It's only slightly more confusing
than usual in this case because the string it is built from is
a C-string owned by lua, and the temporary std::string object is
implicit.
I don't believe this commit will even make any difference in the
compiled code, it's only slightly simpler and more readable.
After this commit, the "strict mode" lua variable errors may be
disabled with
ilua.strict = false
and reenabled with
ilua.strict = true
There will typically be no noticeable performance difference from
previously to this commit.
This is a bit simpler than the other methods described which
include using pcall or resetting the metatable of _G.
this commit causes wml menu items to have their events registered
not during construction but only when "init_handler" is called.
it refactors the wmi_container object to do this when it
constructs new items via the [set_menu_item] path.
this is necessary because the items might be constructed before
the event queue even exists, and we want them to be able to
persist and be reactivated when a new campaign scenario starts.
more testing is necessary to determine if all code paths, including
carryover and reloading, are still working after this commit, and
the earlier commit 6fc1ac1bb224cddec5ccbb7f7865b69b1b093a01
See also discussion of bug #23115.
[store_side] variable= some_variable[0] ... [/store_side] would result in a wesnoth.set_variable(some_variable[0][0]. ...) call which we don't allow in master after https://github.com/wesnoth/wesnoth/pull/231. 1.12 would just ignore the second index in this case. I decided to rather fix [store_side] than to restore the 1.12 behaviour of set_variable (which wouldn't be harder).
