Clang 3.4 compiles cleanly with this warning enabled, but Clang 3.2
fails. (Clang 3.3 hasn't been tested.)
This reverts 5fb8dc8a3356b284b8890481df62cfb087a2c300
Previously, the [filter_vision] tag would cause a false positive when a
unit was on terrain on which it was invisible and that also was under
fog/shroud. There might have been other combinations that did not work
either, I did not check that. I did check that all 8 combinations of
visble=yes/no, the unit hiding due to terrain or not, and the hex being
under fog/shroud or not work now.
This required care to:
* not add ids inside [not] tags
* remove items from dictionary not just when unstored, but when
clear_variable is used
* handle comma-separated values
Sigh. Probably should re-write the .plain file parser to first remove
all commands, keeping the meta-information in a separate class. Then
parse the result (which should be much simpler) and consult the
meta-information where necessary (text-domain for strings, source files
and line numbers for tokens).
Quoting the code from savegame::save_index_class::data(const std::string&):
/*
* All saves are .gz files now so make sure we use that name when opening
* a file. If not some parts of the code use the name with and some parts
* without the .gz suffix.
*/
... A confusing statement that makes absolutely no amount of sense
whatsoever and comes from patch #3125! Not even back then it was true:
saved games could be either compressed (.gz) or uncompressed plain text
files (no extension). Nowadays we also have bzip2-compressed (.bz2)
files to add to the mix.
Most code actually calls the savegame-related functions with an explicit
file extension (if applicable), which is the source of a whole array of
maintainability concerns at this time; thus, I am not really sure what
the "some parts of the code" part refers to.
Previously, the Unknown icon only received TC if the leader unit for
that side supported TC, and it'd only use the source palette specified
in the unit configuration. Our Unknown icon, however, always needs TC,
and it must always be on the magenta palette.
The string only worked as intended before the GUI2/Pango days (i.e.
before some 1.5.x version), meaning that the client would use a red
color for the font.
In other words, deplorable user interface design.
Nowadays, the add-ons client uses a dedicated error message path for
presenting this kind of alerts to the user, which uses a dialog with a
visible "Error" caption and everything. We don't really need extra
formatting, and in any case, *it should not be the server's mission to
do this*!
This adds functionality to enable or disable Pango markup on GUI2
widgets instantiated by Lua GUI2 dialogs.
The code is taken almost verbatim from patch #2759 by Exasperation
<https://gna.org/patch/?2759>, rebased against current master.
