This also adds a few utility switches which people are probably already
familiarized with from the game proper. Most notably this means I don't
need to alter and recompile campaignd any time I want different logging
settings.
There's some functionality commented out in this commit while I figure
out how to wire it into the campaignd server class.
The file only had a run-time effect if it listed any files as "fuzzy", which it
hasn't since the last change in 2015. However, that isn't a reason for removing
it.
The reason for removing it is that it doesn't make sense to automatically mark
images as fuzzy when an image changes, because fuzzy is often much better than
untranslated. This is different to the logic for strings, where a single word
can negate the meaning of a sentence. The decision has to be a manual process,
and at that point it might as well be done with the source-control tool's
delete-file function.
Even considering the previous times that l10n-track was used, I can't see a
scenario where it would be useful.
* Scenario: a screenshot needs to be replaced. In this case the new images are
going to be screenshots too. If the old images are out of date, better to
just delete them instead of needing the fuzzy mechanism; either option would
have the same effect of showing the up-to-date-but-untranslated image.
* Scenario: a map is completely redrawn. This seems unlikely, as a completely redrawn
image could be added as a new map rather than replacing the old one. Even if
it does happen, it's probably best to just delete the old --overlay.png
files.
* Scenario: a new landmark is added to a map. Using the existing overlay file
is still going to be good, as it means the rest of the map is shown
translated. There's surely new dialogue in the WML files commenting on this
new landmark, which would be a good place to say
# po: Lorem's Ipsum was added to the map on 24 Jan 2020, please add a label to your language's --overlay file.
* Scenario: an old feature is removed from the map. Using the existing overlay
will have an out-of-date label, and the significance of that would depend on
how it affects the storyline. This could be significant enough to make
showing the English labels be a better option than showing the translated
ones. However, the translated maps could be updated without knowledge of the
language, so if it's such a significant change then the developer writing the
new WML should probably do that.
* Scenario: a feature moves slightly on the map. This is an example where the
l10n-track file has been used, it happened with the Bitter Swamp on the
bottom-right corner of the title screen. I think it would have been better to
show the slightly-out-of-date overlay instead of showing the English.
Note about cherry-picking: in the 1.14 branch, the change needs to be applied
to src/picture.cpp instead of src/filesystem.cpp.
Update the list of files installed by "scons install-pytools", dropping Python2
versions and adding their Python3 replacements. This doesn't update any
`import` statements, as the tools have already been ported to use the Python3
modules - the scons script was out of date and was still bundling the wrong
versions.
Note for anyone looking at the history - although most of the current
tools have a '3' in the name just to indicate that they're the Python 3 version,
there's a double-meaning to that number in wmlparser3.py's name. There was a
`wmlparser2.py`, where the `2` indicates a redesign of the original.
The data/tools/README.md file was renamed from plain README without being
converted to Markdown format. This commit touches about half of that file;
headings in that half are updated to be Markdown, but to reduce the diff the
other headings aren't updated.
This has been added as a submodule for convenience of use, since mariadbpp isn't included in any repositories (linux distros, vcpkg, etc) aside from an Arch AUR.
Certain distro/compiler combinations will apparently warn about not optimizing when _FORTIFY_SOURCE is set.
(cherry-picked from commit 09fcc6b0519d458cbc3e16788576000a8484020b)
This reverts commit c93482560779c0e137d9598b9e7185338afe2b82.
Keep data/test/ in 'scons dist' tarballs to match official tarballs.
(cherry-picked from commit bad6897cbc75225624814b66c9226cf6233e95cf)
This makes 'scons dist' work, although the resulting tarballs are not
yet identical to cmake tarballs.
Remove awk usage made obsolete by the git transition
(7f85fa000c836c27cfe9d829db3b0e8aaeb49821).
Update src/revision.hpp reference to use src/revision.h. The former
name is unused since at least 7625b1e079b470119d72ea67ce955104f464e4b8.
(cherry-picked from commit 0ee485415710288d27f7b766e48fe7451b03c9a4)
As per sigurd's trial and error: RELRO's options are unknown entirely and -fstack-protector-strong results in compile errors. Building with just PIE and _FORTIFY_SOURCE enabled does then compile, but results in a broken executable.
(cherry-picked from commit c9541176776aeb676e99f1804d123552430582ee)
This is workaround for windows style path confusing scons if they appear
in CPPATH etc. Paths without prefix still happen to be valid and they
start with "/", not "c:".
(cherry-picked from commit b347bc70b163a572751b7ac72f23e472c3ac9238)
Technically, all this code should work on Vista, (including the recent switch to using
SHGetKnownFolderPath), but since we're also considering requiring Visual Studio 2017
for building, we need Windows 7.
(cherry-picked from commit 2a585118d8b6c4b37d0ff9446a72ca20419ff7f7)
Use of this feature with GCC in particular causes the stack to become marked as executable.
(cherry-picked from commit 96b43a9af4ec76882afe6924e9c3dafb5b8beac5)
Scons OpenGL/GLEW test taken mostly verbatim from 3e2eba22a96cb2c6c69ee5109059b806f22a372f
(cherry-picked from commit 5e36a90039ddde3625690ace5259198e1932a7f8)
Otherwise, if we build with sanitizers and optimizations, the sanitizer stacktraces can become quite hard to read.
(cherry-picked from commit 29089a47369c32d4eabb93ac7f5b33222c047670)
Travis now also makes use of this to set the optimization level for the -O0 builds, rather than extra_flags_*. This additionally fixes an issue where using -O0 in the release build with LTO resulted in the individual *.o files being compiled with -O0, but LTO then still linked with release's default -O3.
(cherry-picked from commit 63ff641662d4192401a49f9a002d7872000a3f02)
After some discussion, we concluded that this code was unmaintained, not even used in
some places (display.cpp, units/frame.cpp), leaving the only area that really used it
at all the image surface cache. Considering there was never really a conclusive benchmark
of its benefits and because said surface cache will be used a lot less going forward,
we're just removing it and simplifying everything for everyone.
Closes#1260 since it's now irrelevant.
(cherry-picked from commit 3792612fb759942e6eb5de51364c2cca4ed16b40)
