the carryover code now reads the "next_underlying_unit_id" and [end_level_data] directly form the last snapshot which is expicitly created before the playsingle_controller object is destroyed (in playcampaign.cpp), so no reason to write them here.
also the state_of_game.carryover_sides_start["next_scenario"] = resources::gamedata->next_scenario(); is not needed since show_carryover_message doesn't do this neigher (it's done done by convert to start save later).
This is done for cases when the value cannot be read from the unit_info
table, which might happen in some UMC. This fixes a rare bug affecting
the Fast Micro AI attack evaluation
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.
we move state_of_game.expand_carryover(); out of playmp/singel scenario to remove code dublication
we move gamestate.get_starting_pos().child_range("story"); after expand_random_scenario because expand_random_scenario might invalidate the returnvalue of child_range("story").
we don't need gamestate.carryover_sides_start["next_scenario"] = resources::gamedata->next_scenario(); at that location, becasue that function only does the message, the actual carryover was moved to saved_game.cpp/carryover.cpp
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.
Check whether the unit in the way has an unoccupied hex to move to.
Previously, it was only checked whether its reach was >1, which
sometimes can include only hexes occupied by units on its own side,
making the actual move impossible.
Defines a UnitPtr (boost::intrusive_ptr<unit>, after irc
discussion), which the engine will use to pass units between
different modules, and which it is planned that the animation
engine will also hold, to avoid segfaulting.
Unfortunately this commit could not really be made smaller, it is
necessary to change all of these things over at once, or specify
very complicated deletion policies for the units at the
boundaries of the modules.
The main intention of the commit is to get these three modules
using a reference counting system to hold units, even as they
are passed between the modules. Eventually the fake units and
other kinds of units will all also be held in such pointers, and
the unit_map::unit_pod object will be replaced itself with a
single smart pointer.
Finally the animations objects will hold weak pointers to units,
to fix the segfault issues.
This commit required us to change over the whiteboard, most of
the action_wml, and the AI modules, since these make use of the
recall list from the team class.
We also add the unit_ptr.hpp header file, to allow to forward
declare the UnitPtr object essentially, and it's const variation.
If we forward declare the intrusive_ptr functions, we can forward
declare the UnitPtr type and avoid including unit in a bunch of
places that we don't need to. (Good as that is a very heavy
include.)
The declaration is now in unit_ptr.hpp
Since we can't forward declare inheritance, the easiest way to
resolve linker problems is to not derive unit from the
reference_counted_object class and just include the intrusive_ptr
boilerplate as usual instead.
change savefile format & wesnothd protocoll
The main intentions of this patch are:
1) To remove redundant information in savefiles
2) To fix mp/sp bugs: "modification [event]s wont be reaplied if one advances from a mp game (also if it was reloaded from sp that was reloaded in sp)"
3) To fix "start-of-scenario mp saves are broken"
4) Clear up playcampaign.cpp s code
This patch changes the wesnothd server protocoll causing incompability with oder version regarding networked mutiplayer. We now use the savefile fomat when sending new games to the server.
Also between some commits in this pr some mp related things will not work.
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.
having with network/network_ai together with force_lock_settings_ cause
assertion errors because update_controller_options won't add any
possible options.
this patch restores the previous behaviour where force_lock_settings_
was ignored for reloaded games.
Set this default value immideately after reading the scenario is
importent because otherwise we might endup settings this value to the
multiplayer players name, which would break carryover. (doing this in at
config loading in game_config would be ok too i think.)
I also removed 'mp_game_title' because if i leave it, it casues an 'attributes not in order' error since level_ contains attributes. Idk what it does so i removed it. if we want it we should write in into level_
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]
