This doesn't change the behavior - the changed line is in a conditional block
which tells us exactly which of scenario_id()'s code paths will happen, and it
will still end up using carryover_["next_scenario"]. The change is just making
it consistent with the way that other lines in expand_scenario() find out which
scenario id to use; it's preparing to load the next scenario, so it should use
that scenario's id to load any metadata, not the current scenario's id.
Also, scenario_id() should be const. This helps with refactoring out the
existence of a de-facto singleton instance of saved_game.
This commit:
* sends the era and scenario as part of a [multiplayer][addon] in order to make it consistent with how add-ons' information is sent to wesnothd. this means all of the game's content information is now available in the [multiplayer][addon] data.
* correctly covers the case of there potentially being modifications added to mainline at some point. the current code looks at the [multiplayer]mp_scenario= and [multiplayer]mp_era attributes to cover the case of a mainline era/scenario being used, but looks for modifications only in the [multiplayer][addon] data, which wouldn't have any entry for a mainline modification right now if one were added.
Now content that is loaded via [load_resource] is placed to the position
where the [load_resource] was. This fixes a problem where previously one could
not use lua variables/functions created by the [resource][lua] because the
engine would put the [lua] tags from the [resource] after the [resource] from the
scenario.
This time it uses size_t indicies instad of vector iterators to prevent
possible bugs arisong from invalidating iterators when the size of the
vector changes.
This reverts commit b3e1680f886ec27c29150912bb27949d7cdd7f6e.
In the long run i think it might actually be better to allow [event] and
[lua] to have a order/priority attribute similar to lua on_event events.
Then this commit would probably not be needed anymore.
This reverts commit 706740220957a9313909f5cc358ba5aba3bf4118.
The commit used the `pos` iterator after invalidating
it (passing an iterator to `config::add_child_at()`
invalidates it), resulting in undefined behavior.
Now content that is loaded via [load_resource] is placed to the position
where the [load_resource] was. This fixes a problem where previously one could
not use lua variables/functions created by the [resource][lua] because the
engine would put the [lua] tags from the [resource] after the [resource] from the
scenario.
(cherry-picked from commit 1ac635ec63e775dcd1aa90d04b9adf3f061ef476)
this fixes require_scenario=yes for scenarios that use map_generation or
scenario_generation, the problem was that create_engine does not call
saved_game::expand_scenario for random maps, (which is the function that
checks require_scenario=yes)
fixes#3105
(cherry-picked from commit a10287c5c2a49ff248f218c11f4061e472090089)
The old name was too easy to confuse with a side's map staring position, something
I've done several times.
(cherry-picked from commit 8f93d0a7c67f77e3917c5a24c55a9d450579a423)
Turns out I mistook @celticminstrel's opinion that we should use include guards over pragma (737916e).
Since all major compilers support `#pragma once`, there's no reason not to use it.
For future mergability reasons, this excludes src/spirit_po and src/xBRZ. It also excludes src/boost-patched.
[scenario],[multiplayer],[era],[modification] and [campaign] can now
contain [load_resource] tags that will load [resource]s that are
toplevel tags similar to [modification] whose child tags will be copied
into the scenario.
First we make saved_game assignment operator copy and swap.
This might increase performance in case where the copy elison can be aplied.
Second we add a set_data(config& ) method that moves the savefile cfg
into this object. And use that function in the loadgame class.
Previously recorder had config memaber and saved_game had a config
memeber.
And when saving a game the config was copied from recorder to saved_game
and the other way when loading a game.
Now the recorder object directly writes into the saved_game object. This
saves some copying when saving and loading data.
I also moved the pos_ variable from the recorder object to the
saved_game replay_recorder_base object, This fixes a bug where saving a
game during a replay also caused to not yet played turns to be written
into the savefile.
First we remove the snapshot_ memaber form savegame class which was
previously copied with saved_game.set_snapshot
Second we use copy and swap in saved_game::set_snapshot
saved_game::set_scenario, this makes it possible to apply copy elison
and saves another copy of the snapshot if the compiler is smart enough.
the connect_engine.cpp code assumed that save_id was already set, which
wasnt the case if we used scenario_generation becasue the setting of
save_id in expand_scenario might be overwritten in
expand_random_scenario.
this was previously broken because we passed a temporary pointer to
generate_map. While fixing this i moved it to saved_game.cpp
i also added a call to expand_random_scenario in mp_game_utils so that
in a mp campaign players advance to the next scenario which is randomly
generated. they have all the same scenario.
this was broken by a commite earlier by me.
We now add them to teh scenario in saved_game.cpp and not in the mp
code. The reason is that we stil want them to work if a mp campaign game
was reloaded in sp.
This patch changes the mp wesnothd protocol.
multiplayer connect now works as following:
multiplayer_create/configure creates saved_game object which is then
loaded by mp_connect and sended to the server in the usual savefile
format, this especially implies that [side] are no longer at toplevel
but instead nested into [scenario] or [snapshot].
mp options are saved into state (the saved_game object)
(state_.mp_settings()) previously we had a separate mp_settings object
for that now we only have one mp_setting object.
This commit still not fixes mp modification/era events/options. The
reason is, that i want to move the expansion of those to saved_game.cpp
for better compatibility to Sp (Especially make era events work in mp games
reloaded in sp), but if that won't work i'll just enable them how they
were before.
There are still some things to do. Especially the server generated
replay-saves will be completely broken. (will fix in another commit)
we don't use the [replay_start] as starting pos in mp anymore so i removed
2 lines in playcampaign that assumed that.
I also removed soem code in mo_game_utils that seemed redundant, bugged or useless
since we now send the [carryover_sides_start] over the network too there
is no reason to apply [carryover_sides_start] before getting into
mp_connect engine (when advanging the the next scenario), even more,
since the new code expects only ONE of [carryover_sides_start] or
[carryover_sides] to be present, we cannot expand carryover_sides_start
in playcampaign before going to mp_connect because we might wan to modify
[carryover_sides_start] in mp_connect
still TODO:
* rename mp::configure::get_parameters
* reimplement mp modification/era s events/options
* remove fields from the mp_game_settings object
* remove disabled/outcommented code
the intention is to change the serverside generated replays to contain
[scenario] & [carryover_sides_start] & [replay]. [replay_start] would
be wrong because carryover isn't expanded in these servergenerated
saves.
Servergenerated saves from reloaded (non start of scenario) games will
then contain [replay_start] & [carryover_sides] & [replay]
this also makes a small change in the savefile format: [endlevel] ->
[end_level_data] in snapshots.
we still have the "store_carryover" function in playcampaign.cpp which does the visual message.
Note that the real carryover happens after linger mode while that message happens before linger mode this simplifies linger mode saves.
