… 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.
since we can't attack these, this information is not useful.
afaik it is quite common to have permanent "statues" in MP maps,
and extremely rare that units may be unpetrified in any core or
umc scenarios.
logic error was introduced in client side controller types:
when a player drops and controls an ai-side, the side_drop signal
is only sent to the host, who should make that side a local ai,
not a networked ai.
WML values may not be used as keys, this can make savegames invalid.
Store information in the units now rather than in self.data. (Note:
storing in self.data would also be possible if the syntax were changed.)
In the default configuration, the AI moves the messenger which has
advanced the furthest through the waypoints first. If this key is set,
the rearmost messenger is moved first.
For two of the CAs this mostly just means reading the [filter] tag and
picking one of the messengers. However, for the CA moving the escort
units, it means a complete rewrite, as the AI now needs to figure out
which escort unit should be moved toward which messenger.
When there were lots of escort units, they previously quite frequently
blocked the messenger’s way, preventing him from making progress even
when it was possible. Escort units now specifically move out of the
way if they do not need to attack enemy units in the messenger’s way.
in blindfold_ii, blindfold was taken off when local side takes control
in this fixup, blindfold is taken off as soon as host gives control of
any side.
to achieve this, playturn.cpp must be able to ask the playcontroller to
remove the blindfold.
we create a virtual method of play_controller, on_not_observer,
which is called whenever this client gets local control of a side
(it becomes ai or human)
on all play_controllers except play_mpcontroller, this does nothing
in play_mpcontroller it calls a "remove_blindfold" function
when a human side takes control, remove_blindfold is still called,
as a precaution.
