In scenario 16, El'Isomithir's id uses a straight apostrophe, and in 18 a
slanted one. The maintainer can decide which to go with, or simply leave
it be.
The exception is Gryphon Mountain, where the magic comments are updated to
recognize the awakened ids.
This is not the only approach that could be used. wmllint could be upgraded
to recognize the transformed ids in [modify_unit]. This is more involved
than I want to do right now, for what I expect to be a corner case.
The other way would be to also filter the awakening events by type as well
as id, and not change the id at all. The original awakening code killed the
old unit and created a new one in its place, and the new id distinguished
the new unit from the old one. However, now that we are modifying an existing
unit, we do not need to change ids, especially since this is not seen by
the player.
For now, though, the easiest path is just to tweak the already existing
magic comments.
The "unknown speaker" warning shows its usefulness, as it turns up a busted
last breath event.
We also delete a few "# wmllint: recognize" magic comments that we don't
need now that ids in NAMED_GENERIC_UNIT are auto-recognized.
The main character macros now have "who is" pairings. This, along with the
advent of auto-recognition of NAMED_*UNIT ids, makes some "recognize" magic
comments unnecessary. Meanwhile, the new "unknown speaker" warning makes
adding others necessary.
The ally characters still trigger "unknown speaker" warnings. There are two
possible solutions: one, to add a set of four "recognize" mcs to several
scenarios. The second, which I lean towards, would be to create a macro
for the recall of the ally character, and pair it with a "who" mc. I will
leave the choice to the UtBS maintainer, however.
I actually thought this was already checked by the "unknown 'xx' referred to
by id" warning. Probably because many more [message]s used to use id= and
role= rather than speaker=.
As a side effect, this new error will force designers to use my 'who' and
'whofield' magic comments!
I am responsible for wmlscope suddenly giving macro mismatch errors, as was
pointed out on IRC. The tell is that in each of these errors, the last field
is interpreted as a stringliteral.
An argument that starts and ends with a quote is interpreted as a stringliteral.
But under previous code, that couldn't happen: quote characters toggled the
instring status on and off, but weren't added to arg, so no arg contained any
quotes. I didn't like the fact that this stripped the quotes out of translatable
strings, so I changed the code to include quotes in arg and strip them out if
they began and ended the arg. Unfortunately, while I stripped out quotes when
arg was terminated by a space, I didn't think it was necessary when the right
bracket terminated the arg. It was.
The tags are now tested directly, rather than as a parent of a key. The old
test was probably not missing tags like the test for illegal child of [if]
did, because [part] could be anywhere in ancestors. Anyway, [part] rarely
contains other tags.
Previously, only lines that parse_attribute could process got passed to
local_sanity_check. So tags survived as ancestors of attribute lines, but
the lines with the tags themselves got discarded. Hence, the "illegal child
of [if]" error was actually triggered by attributes, and the line number
referred to that line rather than the child tag.
While working on [aspect] and [facet] (which originally preceded this commit),
I changed the TypeError exception to pass all lines to local_sanity_check. This
allows for a direct test of the child tags. It turns out many child tags were
not tested because all the attributes were nested deeper inside other tags,
so that the child tag was not the parent of any attribute.
Two core macros failed the new test with the tags [filter_second] and
[filter_second_attack]. This pointed up the fact that these were not in the
list of valid child tags.
It also turns out that tags inside #ifdefs didn't fit the original test,
because "#ifdef" was considered an ancestor, interrupting the link between
"[if]" and the child tag.
Previously, the string only needed to match part of the macro. However, this
left too much room for unintended matches. This change is also quicker for
wmllint to process.
As described in detail in the bug report <https://gna.org/bugs/?21426>,
SDL_mixer's notion of a channel that's "not playing" appears to include
channels with their volume set to zero (a direct consequence of setting
Wesnoth's sound effects volume to zero in preferences or through the
[volume] WML action), which results in Mix_FadeOutChannel() doing
nothing, letting the channel resume playing at a later time once the
volume is reset.
For sound sources removed with [remove_sound_source] while the sound
effects volume is zero, this effectively means that once the volume is
reset, the sound sources will continue playing in SDL_mixer-land and
Wesnoth (or more specifically, WML) can't do anything about it because
the associated data structures have been released and the sound sources
don't exist in Wesnoth-land anymore.
Calling Mix_HaltChannel() directly when the channel's volume is already
set to zero avoids this issue and does not negate the point of the
fade-out effect since there is no way to fade out a channel when it's
muted anyway.
Needs backporting to 1.10.
aggression=1 is the largest sensible value. For larger values, the AI
actually prefers attacks in which it receives more damage, leading to
it choosing the wrong attacks.
Extension of commit 329e7cea968a by fendrin. Now when a build parameter
is defined, the cmake recipe will no longer link in libvorbisfile (just
linking it in makes the app crash when ogg-vorbis music is played).
This was used in saved games during the serialization of the display
configuration (see the display::write() method) since around 1.10.x. The
trailing underscore was clearly not intentional, as the siblings of this
attribute for the red and green channels don't have it, so drop it.
Resulting from this commit, saved games from previous versions that did
have the trailing underscore and were affected by a [color_adjust]
action may be loaded with the wrong color channel configuration (blue
will be reset to the default of zero), but this situation should be rare
enough to not absolutely require backwards-compatibility code.
Multi-line section headers such as those generated by campaigns with
multi-line titles result in slight scrolling glitches because the
scrolling code assumes every entry in the text vector to comprise a
single line.
We don't want to split those headers for the help screen because the
current approach results in nicely formatted headers for the
Contributors page there, so a hacky compromise for now should be to only
split multiline headers for the scrolling credits.
An alternative would have been to make the text vector a linked list so
about::show_about could deal with this issue directly, but that seems
rather wasteful.
