A feature for mp campaigns. previous_save_id lets you specify which user
of teh previous scenario should control this side. For example if
previous_save_id="Konrad" than the user that controlled the side with
the save_id "Konrad" in the previous scenario should control this side.
This also replaces the controller=<number> feature which had similar
intentions but was less flexible.
This removes a config reload when opening multiplayer or singleplayer
campaign selection screen after playign a campaign.
To do this we must make sure the default era for sp and for mp have the
same id becasue otherwise we might get an id not found error.
adds a bool variable in game_config which comepltely disables the
configure_engine, and connect_engine in sp.
Using this should fix https://gna.org/bugs/?23629 and
https://gna.org/bugs/?23496 but some bugs of the spmp patch like the
additional config reload in the campaigns menu are still present.
This function is implemented using case-insensitive pattern matching,
unlike filesystem::ends_with(). I missed this when writing my original
fix, so the vulnerability still applied to .pbl files on a
case-insensitive filesystem (e.g. NTFS and FAT* on Windows) by using
different case to bypass the check.
making 4mp leader automaticly quick is unexpected for a campaigns
designer. And the intention is make it easier to port sp campaigns to
mp.
To do this i ported the quick4 mp leader code to lua.
I also moved the lua code from eras.cfg to a new file eras.lua, this
makes is easier for an editor to detect lua syntax highlichting
automaticly.
For campaigns (sp and mp) which are usually coop campaigns you usually
don't want the turns over advantage message. So we disable it by default
for campaigns. It is still possible to (de-)activate is manually by
setting the wml variable show_turns_over_advantage to yes/no
Previously it could happen that moves of the previous turn were not
sended yet to other players during 'side X turn' and similar events.
This caused OOS because "change_controller_wml" could be sended before
the the moves of the previous turn.
I also removed a virtual froma function that didn't need to be virtual.
Previously it could happen that a client would wait for a remote user
imput while still having a non-empty undo stack. Becasue of this the
client would not send the move that issued the user input (because the
client thinks it is undoable) to the other clients which then never gave
the user input.
This resulted in a situation where the game could not proceed and had to
be aborted.
Fixed it by calling resources::undo_stack->clear() as soon as we know
that a remote user input is needed
(synced_context::set_is_simultaneously()). Also added some assertions to
guard against this situation.
A new unit test, called 'test_role_lua' was added, to ensure that the [role]
tag could be used from Lua.
Also, in the first unit test the types list is stored in a variable, to
ensure that variable substitution works as intended
The following fixes were applied:
* cfg.__shallow_literal -> helper.shallow_literal, to allow calling the tag
from Lua as wesnoth.wml_actions.role
* added trim() to the for cycle
* deleted filter.role and filter.type after having copied their data, because
when calling the tag from Lua they ended up being deleted too early
* unit.role = cfg.role -> unit.role = role
Moves the check for alignment string to the caller to we dont have to
pass a custom error_handler.
Also removed a comment about a segfault in older code.
When using force_lock_settings=yes that game now not only forces
use_map_settings to on, instead if doest show these options and doesn't
thouch those attributes in the scenario.
This implements http://gna.org/bugs/?23037
and might also fix some bugs related to spmp patch ( specially
https://gna.org/bugs/?23509) since force_lock_settings default to yes
for campaigns.
This only seems to happen when Use Map Settings is enabled. Using
faction_lock in that case forces the "Custom" faction selection, which
offers all possible leaders from all factions and doesn't override the
recruit lists.
faction_from_recruit would limit the faction selection to Loyalists in
1.10, thus ensuring all leaders are Loyalists with Use Map Settings on,
but that doesn't seem to work right now either. It shouldn't matter for
this scenario anyway as long as the recruit lists are the ones defined
here rather than the faction's.
http://gna.org/bugs/?23028
previously clients could add a "team_name" to specific packages which
should only be redirect to sides in this team. But the serversided code
which calculated in which team a side was had some bugs:
1) It did not correctly handle sides that were in multiple teams
([side] team_name="team1,team2"...)
2) The serversided data about teams was not updated when wml changed the
teams, also the calculation which side was controlled by a human used
posssibly oudated information.
This commit moves this calculation to the sending client so that the
clients now must specify a list of sides to which the package should be
sended.
Previously it was possible that (modified) clients send user commands
like recruit or move while its not their turn. To prevent this, we now
use the from_side check (that was previously only used for dependent
commands) also for normal synced commands.
The from_side check works like this:
The sending clients adds a from_side= attribute to its commands which
contains which side issued this command.
The server veryfies that that client actually controls that side
The recieveing clients veryfy that this is the side that can currently
issue commands (the currently plaing side).
For compability with older clients it currently just gives a
ERR_REPLAY. Later it should be changed into a replay::process_error.
