* WML: Support [filter_side] in [item].
If [filter_side] is present then "team_name" is ignored.
Fixes#1477.
* WML: Compare [item]team_name to [side]team_name using intersection.
Fixes problems with substrings and when one or the other is a
comma-separated list. See #3533
* WML: Rename [item][filter_side] to [item][filter_team]
* Add changelog entry
This happens when the list comes up empty because of a non-matching
filter, e.g. "Elvish Archer222" and the user clicks on one of the gender
options in this state.
Ideally we should clear the preview pane and disable the options and OK
button here, but the former appears impossible and for some reason
changing the pane's visibility in filter_text_changed() doesn't work
reliably.
This could otherwise be used to escape the lua sandbox, as described in
multiple sources. For example one can use it to reenable the os.execute
function to do shell commands
The affected functions were
load,loadstring,wesnoth.dofile,wesnoth.require and various places in the
wesnoth source where lua chunks were loaded for example by the ai code.
This commit also changes the lua source to change luas load (which is
the same as loadstring), alternatively we could add a wrapper around the
original load function that always passes "t" as third parameter, i went
this way mostly because it was easier to implement, but also because i
was not 100% sure that is is impossible to query the upvalues of a
function via lua (wesnoth disables debug.getupvalue but still).
There is also an occurance in the application_lua_kernel that was not fixed
because i assumed that umc cannot contian application lua scipts.
As further security measure we might want to disable printing the function
adress in luas tostring for c functions, this cannot be exploited by itself
but it can be used to defeat ASLR in some cases.
There's really no reason to have this anymore. It was (AFAIK) introduced years ago
as a performance-saving measure, then was moved to Advanced Preferences in 1.13 since
modern PCs mostly have no issues. With accelerated rendering, there's even less of a
reason to have this.
Fixes wmllint crashing like this upon encountering a gzip tarball in an
add-on:
Traceback (most recent call last):
File "/home/shadowm/bin/wmllint-1.14", line 3188, in <module>
for fn in allcfgfiles(directory):
File "/home/shadowm/bin/wmllint-1.14", line 2944, in allcfgfiles
if interesting(os.path.join(root, name)):
File "/home/shadowm/bin/wmllint-1.14", line 2927, in interesting
return fn.endswith(".cfg") or is_map(fn) or issave(fn)
File "/home/shadowm/src/wesnoth-1.14/data/tools/wesnoth/wmltools3.py", line 270, in issave
return firstline.startswith("label=")
TypeError: startswith first arg must be bytes or a tuple of bytes, not str
[ci skip]
We're going to be using NN scaling for the map, and that's already handled automatically
by SDL (and in the future, OGL). We don't need these settings for surface SCALED_TO_ZOOM
and SCALED_TO_HEX scaling. In any case, if we want to scale a surface to zoom or hex, it
will almost certainly be for map rendering (such scaling methods don't make sense in the
UI, for example), so just defaulting to NN is simplest.
As for why I've decided to stick with nearest-neighbor scaling for zoom, it happens to look
a lot better when done on the GPU than on the CPU for some reason (perhaps having to do with
the old rendering pipeline in which we were doing surface scaling), and it's better to have
a consistent scaling look as you zoom in, especially if we wanted to do animated zoom-ins.
This change drops the option to use Linear or xBRZ scaling for map zooming. This was already
the practical case due to me converting map rendering to use textures. NN was used for all
zoom levels, and it's fast and looks good.
Half-fix for issue #1634 and issue #1924.
The issue that remains to be solved is that on subsequent sessions after
a campaign has failed to load, it is possible for the game to generate a
cache entry for it that only contains the main menu WML for it.
Apparently the config cache transactions mechanism causes the game to
try to generate a cache entry with the wrong defines (a define set that
doesn't include the campaign's symbol, for instance) instead of the ones
that are actually needed and used to match the cache entry's filename
via checksumming. As a result, on subsequent sessions the failed
campaign is aborted with "failed to load the scenario" instead of
displaying the real WML error again (since the error is not hit again if
it depends on the campaign's symbol being defined).
In the meantime, this at least removes the red herring error and makes
the underlying issue a bit more visible. It's a very crude hack but it
does the job.
For lobby messages, there was a length cap in place already, but the
truncated message was lost in processing because it ended up in a WML
document that isn't the one relayed to listening clients.
On the other hand, whisper messages were missing the truncate logic
entirely. Oops.
(The logic for in-game messages does truncate messages correctly as far
as I can tell, and additionally the client UI doesn't allow overlong
messages.)
Thanks to Soliton for pointing me towards the faulty code.
This was due to the change in the MP initialization process wherein the lobby wouldn't
show up until the initial gamelist was received. Since the admin auth message is sent
after [join_game] and before the initial gamelist, and the chatbox widget handled parsing
the auth message, the client was never marked as authenticated and therefor couldn't
observe private games. This fixes that by adding auth parsing to the MP initialization
process.
Note this doesn't fix the issue of the auth confirmation not showing up in the lobby chat
(issue #2920). I'll have to think of a way to fix that separately.
