...use bilinear interpolation for everything.
It seems to have been intended to be a slower but fancier alternative
to the original nearest neighbour scaling. However, NN was replaced by
BI long ago and the removed algorithm doesn't seem to have any
benefits over BI.
The Pandora code is not affected.
unit_type_data::add_advancement() will only have an effect the first
time it is called for a given unit_type. So only call it once per
unit_type (instead of once per unit_type per build status).
If set, AI leaders do not move to the closest keep at the beginning of
the turn. Instead, they participate in the move_to_targets candidate
action (and all other CAs in which they already participated anyway,
of course). The default value is 'no', which leaves the default
behavior unchanged.
...if the type is a gendered subtype ([male] or [female]; not directly
related to gender=) and/or a [variation].
Gender appears in parentheses; variation name in square brackets.
...inherit their parent's ID, even if inherit=no.
If a variation is really supposed to have a blank ID, that can still
be accomplished by explicitly setting id="".
This was made possible by 2013-01-19T13:45:47Z!jt_coding@verizon.net, and reduces the number of
blank attributes inserted into the config. (Almost eliminates the
blank attributes in unit_type configs, but variations still get
"inherited=" inserted if it was not specified.)
It is a bit hacky to have unit_type modify the config passed as a
parameter to its constructor, especially when the modifications are
not done by the constructor.
As for performance, this change has little impact on the net time
taken by set_config(). While it does spend more time processing
configs, it takes less time building unit_types. The net result might
be a small increase in time, but any increase is comparable to the
variations in time seen amongst multiple test runs.
This is a complement to config::merge_with(), as it does a merge
without overwriting. This has a few uses in unit_types.cpp, and using
this function makes the code a bit easier to understand at a glance.
The previous version could fail if a unit type had multiple base
units, if it was defined before those unit types, and if those unit
types themselves had base units. (The config merge would lose a base
unit's base unit.)
