* doesn't clutter unit help tree when a unit variation is displayed
* when displaying a unit variation in the help, it displays the links
below the unit image at the same line as when displaying the base unit
patch from #6011
Previously the config class had an operator bool and
it was a common pattern to use if(const config& = cfg.child(..)).
While this pattern was nice to use. It has severe drawbacks, in
particular it was unclear whether a function that took a config&
parameter allowed "invalid" configs, while most functions
did not, there were some that did. Furtheremore it lead to a few
buggy codes that were unconvered by this change (Not fixed though!),
in particular codes that tested local config objects that were
not references to being invalid, which could never be the case.
This commits replaces those with just `true` in order to not
change behaviour.
Some obvious cases were also removed including for example
things like `assert(config());` There is ony case in the ai code
that i'm not 100% sure of where one implementation of a virtual
function checked for an invalid config and another one that didn't.
With this, all code that check for a config child to be
present now uses config::optional_child which returns an object
that behaves similar to optional<(const) config&>, so it throws
on invalid dereferencing. But it also has operator[string] for
convinience, in particular to make is similary
easy to use the the previous `if (config& = .. child())`.
Also it has a tool DEBUG_CONFIG which tests whether all
optional_config values are checked before they are derefereneced.
Another method manditory_child was
added that throws when the key is not found, which replaces all
occurances of child() that did not check whether the result was
valid. This was neccecary (this= adding a new method instead of
renaming .child) to keep track of converted changes, and be sure
no occurances of child() were accidentally changed to the
throwing version.
We might want to rename one of mandatory_child or optional_child
to just child later. Not sure which one yet. I think it's better
to keep it in the current state (no config::child() ) for a while
though, so that people that currently used child() in their open
prs or other work get an error and not wrongly rely on the previous
behviour of config::child.
The interface of vconfig was not changed in this commit.
The `[trait]availability=` attribute acts as a part of the parent tag, not as a
part of the trait itself. For example, `[trait]id=fearless` occurs in both the
`TRAIT_FEARLESS` and `TRAIT_FEARLESS_MUSTHAVE` macros, and the trait is:
* Must-have for units: Ghast, Ghoul, ...
* Available for non-leaders of race: Troll
* Available for non-leaders of types: Dune Paragon, HI, ...
Showing a single "Availability:" in the help is therefor misleading. Adding a
detailed list of where it's available adds a lot of code complexity for little
gain; this commit takes the code cleanup and comments from prototyping that,
but just removes the "Availability:" text from the help.
For example, UtBS' Quenoth Elves now appear as a subfolder of Elves, and a major
reorganisation of animals is being discussed in https://r.wesnoth.org/t56522 .
Multiple levels of nesting are supported. If [race]help_taxonomy= points to a
race that isn't defined, or isn't defined with the current set of add-ons, then
it will fall back to adding the race at the top level. Discovering a unit
belonging to a subgroup will automatically treat the parent group as discovered
too.
I may have missed a trick in writing this nicely, the code uses several different
traversal patterns over the tree that it's constructing.
* Pango changed its definition of 'green' in version 1.32.2 to align with CSS specifications (see #4348 for details).
* This change focuses only on instances of '<span color="green">', leaving instances of named colours that don't use 'green'.
* Problem: Cannot use this approach with '<format>' (at least not that I'm currently aware) so it breaks time-of-day bonus colour consistency.
This additionally:
* Makes all copyright notices identical aside from the starting year for Wesnoth-specific source files. Files not included: mariadbpp, lua, spirit po, xbrz, and bcrypt (crypt_blowfish).
* Removes all attribution from the files, since the vast majority of them are outdated or seemingly just outright incorrect. For example, I would guess that Dave is no longer the sole author of the majority of Wesnoth's current code.
Colours obtained from help markup until now have been generated using
from_argb_bytes(), even though the caller ensures they are 7 characters
long and thus in #RRGGBB hex notation. When porting the help text render
code to pango_text, this resulted in text with colour set by markup
being rendered invisible with an alpha value of 0.
Unless we decide at a later point to support alpha values in help
markup, we want alpha to always be 255.
Keep in mind ter_data_cache is simply a shared_ptr, and in all call locations it was grabbed from game_config_manager::terrain_types().
1. campaign_controller took and kept a member, which was passed to either...
2. playsingle_controller or playmp_controller, which passed it to their parent class...
3. play_controller, which kept a member to initialize...
4. game_state, which passed it on to...
5. game_board, which passed it on to...
6. gamemap, where it was *finally* actually needed.
This entire chain has been replaced with a single call to game_config_manager::terrain_types() in the game_board constructor.
gamemap retains its ctor parameter since editor_map passes in its own object.
The ter_data_cache alias has also been removed. It was just confusing.
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.
