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.
This option was already implemented in the GUI2 lobby (without a
warning), which resulted in a misleading advanced preferences entry.
(Forum thread: <http://r.wesnoth.org/t42423>)
The warning works as follows: you get alerted of individual clients
trying to contact you while you have this option enabled, but you'll
only get the alerts every 5 minutes. This seems like a fair compromise
between dealing with abuse and reminding people that this option is
enabled in case they accidentally did so or only intended to do so
temporarily. Also, if the sender is in the ignore list, this will not
produce a warning.
This fixes an issue where unit bars disappeared for individual units
after a movement action with Quick Replays on or when using the Skip
Animations replay option, so that they'd only reappear after playing an
attack or select animation (or any other animation, probably).
The cause was that these options cause the replay code to hold a CVideo
lock, which causes the unit_display::unit_mover::finish() to return
early without restoring the animated unit's bars. Since this also makes
the u_d::unit_mover not hide the bars in the first place, it wouldn't
normally be an issue; the bug is actually caused by an interaction with
actions::unit_mover::do_move(), which unconditionally hides a unit's
bars for every movement step.
Since I don't want to call unit::set_standing() more times than
necessary (even though a::u_m::do_move() appears to do just that), I
decided to have u_d::u_m::finish() reset the unit's state even when
it's not supposed to do anything due to display locks.
I also added comments in a::u_m::do_move() and u_d::u_m::finish() to
warn people about this interaction in case it comes up again in the
future.
draw() calls draw_init(), which in turn calls draw_all_panels(), which
destroys all theme UI buttons, meaning the icon overlays set on them by
set_button_state() are lost until that function is mysteriously called
at a later time, either when control is transferred to the player after
completing the start event, or the player presses the left mouse button
on the minimap buttons (??????) or some other unspecified UI event takes
place either automatically or through player interaction.
This is really a patch over f93b439e13,
where I failed to make sure one of the affected add-on scenarios would
no longer reproduce the bug before pushing.
Backported from master, commit bf75c9d062.
As I said on IRC, whether unit type variations use variation_id or
variation_name to define the variation id is wholly immaterial for
syncing purposes because serialized singular units:
1) Do not include [variation] definitions nowadays;
2) Have a single variation=<id> attribute, where the source for the id
of variations is determined internally during initialization.
One situation that could result in collateral OOS errors is
[store_unit_type]/wesnoth.unit_types retrieving different information
for 1.12.0 and 1.12.1 game clients running the same WML/Lua script. I
suspect this should be relatively rare and it's possible to guard
against synchronization issues by checking for both variation_id and
variation_name for WC/Soulless variations and picking one accordingly.
This fixes many instances of unit types with "technical" variations in
my campaign After the Storm being assigned help sections of their own.
Required adding a new method to unit_type that's actually cheaper than
checking for variations().empty(), as it doesn't involve allocating new
objects.
