The .pbl [feedback] block (also used in the server configuration WML)
specifies a list of format values interpolated into the
feedback_url_format string from [server_info] to build a web page URL
that is delivered to clients each time an add-on's metadata is sent in a
[campaign] block.
For example, given the following campaignd-side configuration:
[server_info]
feedback_url_format="http://forums.wesnoth.org/viewtopic.php?t=$thread_id"
[/server_info]
And the following tag in the _server.pbl WML:
[feedback]
thread_id=32091
[/feedback]
..., the server will deliver the following field as part of the
[campaign] block provided in the response to [request_campaign_list]:
feedback_url="http://forums.wesnoth.org/viewtopic.php?t=32091
The fields from the [feedback] block are percent-encoded to ensure that
the .pbl WML can't manipulate query strings from the
feedback_url_format. If for a system administrator it is somehow
desirable to let authors enter arbitrary URL fragments (e.g.
feedback_url_format="$url" and [feedback]
url="http://this-site-kills-kittens.example.com, bad idea btw), then
they should probably remove the utils::urlencode() call themselves and
take responsibility for any malicious links that could be served to
users of the add-ons server that way.
The [server_info] configuration block is intended to contain additional
information about a campaignd instance that may be used by clients or
the server for various purposes.
As a first such information field, the feedback_url_format string
contains a format string for use with
fast_interpolate_variables_into_string() to build add-on feedback page
URLs.
utils::interpolate_variables_into_string() requires a bunch of formula
AI implementation details at linking time, which really shouldn't be in
server-side code (see commit 495f481fdf6cbd6d5eea2ffaa20423f08c955eec).
Since I'm going to need a similar variable interpolation scheme for an
upcoming campaignd feature, add a
fast_interpolate_variables_into_string() function that does something
roughly equivalent, except using simple string replacements without
support for the full WML $variable syntax (e.g. pipes don't have any
meaning in this version of the functionality).
The other choice dialogs in this scenario use "I" or "we", so
this brings it into conformity with them.
On the mailing list, I also spoke of a desire to have Camerin's
lines run before the choice is made, but looking at it, this
is a more complex change than I want to deal with right now.
Though this may be in vain, as I read on the wiki that attack_depth is not
working with the RCA ai and is deprecated. While this bug might break
attack_depth on one difficulty level, it shouldn't have broken it entirely,
so this is probably not the reason it doesn't seem to be working.
The brackets are a relic from when I had a different conception of how the
"who ... is ..." comment would work. Although these comments still work,
because I now strip brackets from the macro name, I don't want UMC authors
getting the idea that this is the "right" way to do these comments.
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!
