The aspects are:
- recruitment_diversity
- recruitment_instructions
- recruitment_more
- recruitment_randomness
- recruitment_save_gold
All aspects will only work with the new recruitment CA (not committed yet).
See http://wiki.wesnoth.org/AI_Recruitment
This includes:
- A new constructor for class battle_context_unit_stats to make simulations work with unit_types,
- Making function combat_modifier() a bit more generic (to specify a custom lawful-bonus),
- Changing method battle_context::better_combat() to be a static method (It doesn't use class-members).
- Adding method unit_type::resistance_against() so a unit_type can evaluate WML-resistance-abilities.
Apparently iterator_extend_base caused more issues than it solved,
so it is gone now.
Also, access to the underlying iterator has been made less roundabout.
The basic_string::data() method does not guarantee the result to be
null-terminated, and passing a non-null-terminated string where a
null-terminated string is expected (i.e. every Win32 API call here)
leads to all kinds of misfortune.
This defines some types and functions that come from the STL
definition of a container. It's not complete, though, as I do
not see a reason to define size(), max_size(), or swap() at the
moment. (They would be easy to add, if the need ever arises.)
The new #include file might be useful elsewhere as well. I'll look
into that.
This fixes memory leaks or crash-to-desktop (the latter reliably
triggered by Boost 1.54) situations resulting from failed connections to
an add-ons server throwing an exception from the addons_client
constructor, not giving the destructor a chance to run.
Thanks to loonycyborg for helping me diagnose the issue.
The old management had potential, but in practice it was rarely in
a position to show off. It ended up doing little more than reference
counting; a shared_ptr can do this with less overhead.
The game config is being reloaded to make sure that players have the
same config as host, if possible.
Note that reloading only happens when it is necessary and it would not
happen if host's cache defines matches the player's ones. I.e. regular
MP scenarios won't trigger a config reload.
The commit was reverted because "allow_player" value is being checked in
other places. This resulted in different default values for
"allow_player" in the different places.
1st case:
Overwriting "current_player" with default value produces an incorrect
side config and causes the server to not recognize the player if its
username is not the same as "current_player" value. This is not
desirable, since a different player might be assigned to an ex-reserverd
side or a player might just simply change his/her username.
2nd case:
Using default value for "current_player" if no player has taken that
side, results in setting wrong controller in case side was reserved for
host.
The players being unnotified resulted in them being able to press "End
Turn/End Scenario" button and downloading the current scenario data
instead of the next one.
Related code, which was marked as "deprecated", has been removed due to
not actually affecting anything.
The new has_variation SUF attribute filters if a unit has a variation
child type with the given id. If the unit is a variation itself the
siblings are considered.
* Use "Options" as a dialog title instead of "Filter Options" for
simplicity and to represent its current functionality better.
* Limited dialog width to 800 pixels for readability.
* Replaced neutral sorting options header with something that hopefully
describes their purpose in a more user-accessible fashion.
* The installation status options listbox now grows along with its
containing grid.
* Ascending/Descending options are placed closer to the sorting
criterion selection.
* Description labels use text wrapping when needed.
This replaces the container-driven add-ons list sorting with
std::stable_sort() on a vector for the sake of simplicity, since now
sorting is controlled by user preferences rather than being completely
hard-coded. Alphanumerical sorting by add-on title continues to be the
default option, but now it is also possible to choose between last
upload time sorting (timestamp field in campaignd data) and first
upload order (which is the campaignd WML order, which is artificially
restored using an internal sorting index for now since the std::map
add-ons list optimization causes the campaignd order to be lost in the
pipeline). It is also possible to choose the sorting direction
(ascending or descending).
The full rationale for the whole design follows (also provided in
Doxygen comment form):
"The internal add-ons list is actually implemented employing an
associative container to map individual list entries to add-on ids for
faster look-ups. The visible form of the list may actually include more
elements than just the contents of the add-ons server; more
specifically, it may include Publish and Delete entries for local
add-ons with .pbl files.
The GUI1 list/menu class does not support horizontal scrolling, which
results in a very limited set of information columns that can be
displayed safely without running out of space and causing content to be
omitted, and clicking on any column header to change the sort also
affects the Publish/Delete entries by necessity. These two factors
combined make it inconvenient at this time to just use the GUI1
widget's interface to make it default to a specific sorting criterion.
Thus, we need a 'neutral' or 'fallback' sorting step before feeding the
add-ons list's data to the widget and appending Publish/Delete options
to it. Since this is definitely not the most evident UI concept in use
in this dialog, it is hidden behind the Options dialog and has sensible
defaults intended to optimize the add-ons experience; alphanumerical
sorting feels natural and breaks any illusion of quality rating or any
such that could result from a list default-sorted by first-upload order
as done in all versions prior to 1.11.0."
***
To recapitulate, this is probably the ugliest thing I've ever done, but
those are the limitations imposed by Wesnoth's chronic UI framework
deficiencies.
This will be used for sorting add-ons by creation/first-upload time
in the add-ons list, since it is currently a map indexing add-ons
by name for performance reasons and otherwise the first-upload order
(determined by the add-ons list WML order as delivered by campaignd)
is completely gone since 1.10.x.
