They are revived in a cutscene, so they should not become a zombie.
There's no explanation to the player, but it's still better.
undead_variation=null disables plague, but in difference to
the status unplagueable it doesn't affect feeding.
* tusker line (by TSI 2009) (removed the middle Tusker unit, just Gorer and Tusklet included)
* falcon (existing unit, new sprite, some animations)
* elder falcon (existing unit, new sprite)
* crocodile (first pass at portrait, most important animations)
* bear (most important animations)
* icemonax (some animations)
* stoat (some animations)
* fire ant (derivative portrait, some animations)
If you try to move straight into the water, the explorer should stop at the
lake edge and comment about where they're going. Trivial change, mainly because
I was using a fast unit for debugging and wondered why I hadn't triggered the
lake monsters.
This is motivated by reorganising the help pages to split the Quenoth from the
"pointy ears, pale skin" help text in data/core/units.cfg. It also means that
there's no reason to [hide_help] for the default era elvish units. The new help
text is just a short placeholder for now.
The new race has [race]help_taxonomy=elf.
If the player loads a mid-campaign save then their recalls and heroes will have
race=elf while new recruits have race=quenoth. For that reason, I've changed
the scenarios' event triggers to recognise both races.
When levelling up, units with race=elf may change to race=quenoth.
Opening the help for a unit will show the help as if the unit has race=quenoth,
even when right-clicking on a race=elf unit. This is good.
For a few of these, I think another race might be better - they're converted to
Quenoth here, as they were Elves before. The Corrupted Elf is should probably be
considered undead, and the Divine Avatar should possibly be something else, more
like an elemental than a living creature. That those two are currently included
in the elves does have the side-effect of hiding a plot spoiler about the Dark
Assassin who is also included in the elves (the spoiler being that this one is
correct, he really is an elf).
This comment was in both the .cpp file and the .hpp file. No need for two
copies of it, but more importantly the .cpp version wasn't updated for the
changes in c4a6b223f3db8ac3d6d7cc7fc162656e643f73d0.
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#5144 "one missing unit in recruit list makes entire recruit list
unavailable". The player will see an error dialog every time they try to
recruit, that seems good given that the limited recruitment options are likely
to severely affect game balance.
The `std::vector<t_string> unknown_units` uses t_string instead of std::string
because that's the class needed for format_conjunct_list. Those items aren't
translated - they're the values of [unit_type]id=, but the corresponding
[unit_type] is missing, so we can't get the translatable [unit_type]name=.
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.
These 5 scenarios were never completed, so the option to play this branch was
always commented out. However the existence of them has caused extra work for
the translators, and would cause further extra work in tasks roadmapped
for 1.15.x (removal of the ^Uf mushrooms, removal of {MODIFY_UNIT}).
If it comes back then it will likely start as UMC.
The nice new feature that allows translated add-on titles and descriptions in the add-ons manager works well when the language preference is explicitly set to some supported language, but not when "System default language" is selected, because this is represented by an empty string in language.hpp. This pull request fixes this by getting the effective locale (the actual translation target language) from gettext.
