* Old English (ang)
* Friulian (fur_IT)
* Asturian (ast)
The "Old English (Latin chars) (ang@latin)" translation is not dropped,
which is why Old English is still listed in about_i18n.cfg.
The manpage uses ang_EN in the example of the command-line --language
option, which is then copied in to other translations. That isn't changed
in this commit.
Although the po4a scripts are updated, the update-po4a target currently
fails because of a typo in the pt_BR translation.
Two scripts have a special case for ignoring ang_GB, both of these are
left unchanged on the assumption that old versions of Wesnoth may be
parsed with the latest version of the tools:
* data/tools/unit_tree/helpers.py
* data/tools/wmlunits
[ci skip]
These are incorporated into the objectives dialog automatically. They lack a deprecation
notice, but they should be given level 3 status on the 1.14 branch.
Note: this does not include a fix for #4484, that a double-quote in a _<< >>
delimited string causes a broken msgid. Wondering whether to remove that from
this text, but would prefer to add the feature to wmlxgettext.
Follows the comments in #4480, about how to handle whitespace at the beginning
and end of translatable strings.
This is text that was added after the last pot-update, so updating it
again now will hopefully be before the translators start on it. Some
text that was split into paragraphs is now combined in to one block,
other parts are still split but with non-translatable whitespace; the splits
will hopefully separate the scenario editor parts which are going to change
again before 1.16.0.
The wmlindent override is because the logic for multiline strings isn't working
for << >> delimited strings.
I originally added it in #719. At that point ms_after= affected the *previous*
track due to a bug; however, I had assumed the behavior to be intentional and
compensated for it by adding ms_after= to the first track of a scenario instead
of the story screen music.
In April, I saw the documentation for ms_after= which said that it's supposed
to affect the track itself, not the previous one. Hence, I fixed the bug in
commit b023b818c742cee0bc75460235c9d1088c0b495d. However, I had forgotten that the changes I had made
in #719 depended on the old broken behavior of ms_after=.
This commit moves ms_after= to the right place, restoring the fade-out on
scenario start and removing the pointless pause after the first track.
This also sets its default value to zero, in order to have consistent default behavior with versions from before this parameter was introduced.
It also provides a macro so that the ExpAI can be used with custom parameters in a scenario config, and adds high_level_fraction as an optional parameter to the Recruit Rushers Micro AI.
... with the idea that these pages will either be improved or hidden again
before 1.16.0. I think the terrain-editor part will be good enough to stay in
1.16, but the scenario editor part needs to be updated by someone familiar with
it.
This puts the two tips that are currently in https://wiki.wesnoth.org/MapEditor
in to the in-game text.
As the terrain is hidden in help, these hints can only be seen by
using the "Terrain Description" command on a ^Uf or ^Ufi mushroom
hex, and then switching to the overlay's own page.
A hint for players about how these mushrooms behave, and an editor-only
hint about replacing the ^Uf mushroom terrains with ^Tf.
The image is a fully opaque letter, but leaving many completely transparent
pixels to see the underlying hex. When replacing the old mushroom overlay, it's
helpful to be able to easily recognise the base terrain.
Fixes#4253.
The schema's validation of ranges now rejects negative numbers, because the C++
code doesn't support them (both before and after this commit):
* utils::parse_range("-7") will return {0,0}, because std::stoi("") throws invalid_argument.
* src/map/location.cpp will parse it as -7, but that will never match an on-map coordinate
since the recent changes to overlays= in particular 1a7724e5472,
e71033374c35 and b2cd1cf6c [unit]overlays= is no longer the
recommended way to add an overlay and the use of the
apply_to=overlay effect is reccomended instead, so adding it
to the [trait] is the most natural option here.
this in particular fixes#4058 . Also people simply forgetting the
IS_LOYAL macro was a not-so-uncommon cause of bugs.
In some cases people want to give the LOYAL trait without giving the
loyal overlays for those cases i added a optional OVERLAY parameter to
the {TRAIT_LOYAL} macro, also heroes should now use {TRAIT_LOYAL_HERO}
instead which uses the hero overlay. The IS_LOYAL and IS_HERO macros are
no longer needed in combination with those traits.
