This reverts commit 6d0b7c8424. Turns out there's
a better way to fix this problem without using mutexes, which have a noticeable
performance hit (5.2% of the execution time of game_display::draw_invalidated()
according to @jyrkive).
Didn't use this in the window widget since that doesn't specify front_child as
the queue position. I need to evaluate whether draw callbacks need to be in that
position anyway. AFAIR I only started adding them there since I noticed the one
in the debug clock dialog used that.
One_strike_fight() assumed that if HP distribution hadn't been calculated,
the unit is alive. It would normally be a valid assumption, but the Wesnoth
engine allows units with negative HP (although things aren't guaranteed to
work correctly in the presence of such units).
The assumption, together with a completely wrong calculation for the
probability that the opponent will counterattack, resulted in badly
incorrect results. That, in turn, caused the calculated probability that
the opponent to kill us to become negative (I observed -75 % when
debugging), making the calculated probability to be poisoned/slowed to
exceed 100 %, and that finally caused an assert if the AI simulated another
fight for the same unit.
I have now fixed those issues. I also noticed that rounding error allowed
the probability to be killed to still become slightly negative, and thus
changed std::min() to utils::clamp() to limit the value to the allowed
range.
This reverts commit ef60deaa2b.
@ln-zookeeper pointed out that units with negative HP are documented in
the wiki, and thus disallowing them is an API
change.
volatile draw had to do with drawing map labels pre-accelerated rendering. They're unused
now and I don't foresee using them again since they don't offer anything the regular draw
functions don't and they aren't needed for the map labels anymore.
Tooltips are handled by handled by GUI2. There are no more help strings since the related
interface in CVideo got removed.
Namely complete_redraw_event(), recalculate_minimap(), and redraw_minimap(). I had
been keeping the last around for reference (see f5ec886cb5) but I
figure it's not really worth it since this isn't the drawing method we'll want to
be using in the end anyway.
This list in the connect engine was passed to each of its side engine's flg managers,
where it was then sorted by update_choosable_factions(). Basically, a whole bunch of
unnecessary sorting. This makes it so the list is already sorted when it's passed to
each side engine.
None of the post-processing of the faction list (in populating available_leaders_)
should mess with the order, as far as I can tell.
the line above does exactly the same as the line inside that if(){..} so it has no effect.
Also, what the comment says is wrong. We do not want to keep the old recall cost if it is different from the original recall cost because doing that would break removing objects that change recall cost.
