The code comments talk about both Dunefolk and Quenoth Elves - of these two, only the
Dunefolk's data is changed in this commit. All Quenoth unit are race=elf at the moment,
I intend to add [race]id=quenoth in a separate PR.
Draft documentation for the Wiki:
* '''help_taxonomy''': {{DevFeature1.15|?}} in the help browser, show this
race as a group of units from another race; the value of this attribute should
be the other race's '''id''' attribute. This only affects the help browser, for
all other purposes (such as WML filters) the two races are completely separate.
How this is visualised in the help browser is a GUI design decision, this attribute
merely tells the engine that the relationship exists.
Fixes#1935 for normal users, expanding on aac0941's fix which only showed
these abiities when Wesnoth was in debug mode.
The removed enum member "NON_REVEALING_DESCRIPTION" was unused, and all
existing callers effectively used description_type() as a boolean.
This does mean that the "aged" trait will be shown to all users, even if
they haven't played HttT, however that seems reasonable.
This commit uses the UI's calculated indent for the UI's event handling, and
removes section::level. The code generating the help sections still has its own
"level", which is used to detect excessive recursion.
This fixes a UI quirk that I only noticed while working out what section::level
was for, while considering the subtopics needed for implementing a taxonomy
system. The help browser calculates indentation for its tree-view based on the
data tree given to it. However, the logic for deciding whether a mouse-click
was on the icon or the text used section::level, rather than any value
calculated in the UI classes. While section::level was often the correct
number, it was wrong for the terrain types' sections.
the game_config_view object offers const
access to the game_config object, furthermore
it allows the game_config config object to be
replaced by a vector of config objects which
is what we will do later.
Even when a terrain has hide_help=yes, its help should still be shown if the
player right-clicks on a hex of that type and selects "Terrain description".
This commit changes lines that have inconsistent logic, and the main reason for
doing it was to work out whether that inconsistency was something that needed
to be kept when refactoring the terrain code.
The inconsistency was a bug, help would fail to open the topic. However, the
bug is so obscure that I only found it when considering the edge case that the
commit is removing, and there's no terrain in core that would trigger it. The
edge case requires a terrain to be:
* defined by a [terrain_type] tag, so is_combined()==false
* hide_help=yes
* hidden=no (or is the default value)
To replicate the bug, try changing the definition of Gg to have hide_help=yes.
Change terrain_type_data's documentation and some methods to avoid exposing
implementation details, for example renaming try_merge_terrains to is_known.
Move the code to load all the [terrain_types] in to the terrain_type_data
class's own .cpp file, and out of terrain.cpp.
Add documentation about "underlying", and why worst(best(a,b),c,d) terrains don't work
The commented-out code for merging pluses and minuses in the middle of an alias
was commented out in 1.5's d2edbe118a, but the
concept of pluses and minuses in the middle of an alias seems broken anyway
(see comments added to merge_alias_lists in this commit).
Descriptions are t_strings, avoid converting them to std::string and back.
The old copy-assignment code would have appended the topics and sections
without clearing those lists, while the new code does clear them. However, the
copy-assignment is only called after calling clear(), so this doesn't affect
the behavior.
This was needed to get the build working with vcpkg's version of SDL, where all the SDL files are
in their own SDL folder. However, our cmake config also has a note saying it was a deliberate choice
to move our SDL files *out* of their SDL2 folder due to certain distros (FreeBSD is mentioned) not
putting the files in said folder in the first place.
This changes:
utf8::char_t -> char
utf8::string -> std::string
utf16::char_t -> char16_t
utf16::string -> std::u16string
ucs4::char_t -> char32_t
ucs4::string -> std::u32string
utf16::string and ucs4::string are now proper strings instead of vectors of characters too.
In order to get this change to compile at all, I needed to add a ucs4_convert_impl::convert_impl
specialization for wchar_t alongside the new char16_t specialization; both point to the same
conversion implementation type.
This commit doesn't do any additional cleanup. I'm sure if we looked, we could get rid of a
lot of the custom conversion code and probably a bunch of stuff that might have had to do with
supporting utf16::string and ucs4::string being vectors instead of basic_string specializations.
Either way, I don't know the code (or encoding handling in general) to make a call as to what's
needed or not. I'll let someone else do that.
(cherry-picked from commit 1deacd89f6)
I had disabled this when I redid the End Credits screen in GUI2 (476027f) since (IIRC)
I didn't want to figure out about parsing the new config-based credits storage. The topic
remained in Help, empty. We've decided the new End Credits screen is a better method for
viewing the credits anyway, so I'm now removing the topic.
This fixes#1774. Essentially, I made the help browser use both ability name and ids when
deciding which ones to add topics for. To facilitate that, I've gotten rid of the separate
vectors for ability names and descriptions and consolidated all the data into a single
ability_metadata struct to unit_type. It still needs to be expanded for use in the unit
class (which I intend to do), which is why it has a whole bunch of fields I don't use.
I've also totally refactored the ability topic generation code in the help browser.
A few of them are quite small, so this has no performance effect on those, but a few others
are potentially quite large, such as the one in campaign_server.cpp.
this not only fixes a very theoretical case where an era could have the same id as an era form another faction. It also makes it possible to check whether a topic describes a faction by just checking it's id prefix.
For example the factions of Default Era and Age of Heroes have the same id's, which caused the faction help topics to have the same id's as well, leading to a faction link on both era pages to lead to the same faction page. Adding an era prefix to the faction topic id's makes them unique and solves the problem.
Covers more cases of:
* push_back(std::pair
* push_back(std::make_pair
* push_back(std::make_tuple
* push_back(T) where T is an empty object of type T
Small thing I noticed: this does mean the numbers in font::subset_descriptor are no longer 'cast' to size_t before being
added to the vector, but that shouldn't matter (hopefully).
This (should) allow sdl/utils.hpp to be modified without a huge rebuild, since a number
of widely used headers included that file simply for the surface class type.
