when a player leaves a mp game during a lua call and the other player
pressed escape, lua catches the error that should exit the game, idk
wether i can fix that but at least i can give a better error message.
the intention is to fix#20871 and implement #21697, to sync
prestart/start events, and to implement
http://forums.wesnoth.org/viewtopic.php?f=6&t=39611 in the next patches,
the intention of synced_checkup is to replace random .. set/get_random_results.
Because set/get_random_results didn't have much to do with random, since it was only used to compare unit checksums and attacker damage to replays.
the intention of synced_commands is to move code out of do_replay_handle and make it callable from other places too so that we can just call the same function taht was called from replay in the simple cases (with synced_context::run_in_synced_command).
the object set_scontext_synced can be used to enter the synced context which enables synced_checkup and make the random calls synced.
Or we can use run_in_synced_context which is normaly easier than set_scontext_synced.
we can check wether we are in a synced context with get_syced_state to make addidional checks to detect oos (the other intention of that is to implement #21697 ).
this commit is part of pf 121.
in the file config_assign.cpp/hpp, it can be use similar to boost's boost::assign for config object.
I don't use it that much, but i found it useful especialy to pass or return a config that just contains one or two childs.
the main intention was to make the file replay.cpp smaller during writing pr 121.
also in order to use synced_context::run_in_synced_context this is useful.
(replay_helper.cpp was already accidently moved into makelist.txt in a pevious commit (add new rng))
the plan is to have random_new::generator which can be a rng_synced or not dependng on whether we are in a synced context (for example select events are no synced context)
this commit is part of pr 121.
… setting up an MAI. Ideally, we would delete such previous occurrences
of [micro_ai] tags in the AI's self.data variable. However, the MAI can
be changed while it is not the AI's turn, when this is not possible. So
instead, we check for the existence of such tags and make sure we are
using a different ai_id.
These provide a simple and consistent method of storing variables
inside [micro_ai] tags in the AI's persistent self.data variable. This
is needed for fixing a bug with variables stored there from a previous
MAI causing problems with a subsequent MAI
This is unit specific information, and therefore should go into the
unit. By contrast, information whether all units of the side have been
released needs to remain in self.data.
… for determining whether AI/CA ids are unique. Also pass AI id to
eval/exec functions, instead of CA id. This is also a step toward
fixing the bug with MAI variables remaining stored in units after an
MAI is removed.
In principle, the ca_id= key in the [micro_ai] tag should now be
renamed to ai_id, but that would break backward compatibility without
any benefit to the user, so we deal with it internally behind the
scenes instead.
These provide a simple and consistent way of storing variables inside
[micro_ai] tags in unit variables. This is needed for fixing a bug
with variables stored in units from a previous MAI causing problems
with a subsequent MAI.
Removed duplicate code that caused timer to be refreshed an additional
time if time runs out. The usual refreshing in
playmp_controller::after_human_turn is already called in this case as
well (after turn ends). The duplicate code gave the bonuses before the
turn ended, and after that the turn was ended (giving turn bonus again)
only if there was no random seed incoming from the server.
Conflicts:
changelog
moved 2 preferences::.. calls out of the loop so that we just call it once.
the following is especialy true on large maps, all results are recorded from a msvc 2010 release build, and recorded with the msvc 2010 sampling Profiler.
these calls are less expensive than the final scale_surface_sharp call at the end of the funcion. But if you assume the scale_surface_sharp woudn't be there, then they'd use a major part (~50%) of the cputime of get_minimap.
i also tested replacing scale_surface_sharp at the end of the function with scale_surface. Here are the results:
tested on LotI Mp Map (part of LotI addon) which has a size 200x200 with fog but no shroud, no logs, ingame debug mode enabled (the :debug wesnoth-console command).
the image on the upper middle is made with scale_surface the other two are made with scale_surface_sharp.
The down-left Image are the profiler results from the scale_surface version of get_minimap, the down-right are from the scale_surface_sharp version. The record was started shortly before a moving so the record only shows the cputime during moving. Also the content of this commit is used in those testings.
http://i.imgur.com/YETVuNq.png
the profiler shows that during movements (with fog) more than 50% of the cputime of wesnoth is spend in scale_surface_sharp for get_minimap, and i personaly think differences in the minimap are not worth that. But there are different opinions and thats why i didn't change it yet, but i still propose replacing the last call
minimap = scale_surface_sharp(minimap,
static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));
with something like:
if(map.w() > 100 || map.h() > 100)
{
minimap = scale_surface(minimap,
static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));
}
else
{
minimap = scale_surface_sharp(minimap,
static_cast<int>(minimap->w * ratio), static_cast<int>(minimap->h * ratio));
}
note, that the 100 is choosen rather randomly.
If that's a problem with msvc then i propose wrapping it in a #if.
I have heared that we will be able to do scaling with hardware acceleration later (around september), but i don't see how thats a reason to not do this until then.
