Add `first_time_only=no` to some existing tests, and verify that events that
should only trigger once do trigger exactly once.
A new test of `[filter_attack]` when an event lacks attack data. In testing,
I found that it used to trigger a warning that I thought was useless code, and
had removed during 88439d6427a81a6b131acd8b0f7bf04b2d981d71's review. I think
removing it is still good, at the time that the filter was checked it would have
warned "attempt to filter attack for an event with no attack data."
A new test of what happens when a unit with only a ranged weapon fights a
unit with only a melee weapon. This commit is just the test, it depends on
the engine fix in a previous commit.
This only tests the filtering so far. There should probably be another
additional test to check what the combat results are, however that would need
an ability such as the Deep Elves' Stardust that passively affects the amount
of damage taken. It can't be tested with Slows, as that needs the defender to
hit with a weapon first.
The old query was:
* Selecting data from 2 months ago instead of 1 month ago for some reason, presumably left over from when I was testing the query out for different time periods.
* Counting non-new players who used a new download source as new players.
The last uses of this were removed in 0fbc12ea01986bc97ef6426e0edc89f12224a0d5.
The only uses of the other fixed-point functions from math.hpp are in
src/sdl/utils.cpp. That should probably move to using color.hpp instead,
but this commit is just to solve the -Wshorten-64-to-32 warning.
When we try to trigger an event conditioned by the use of a special whose activity is subject to a condition, we cannot use special_active because the specials are always considered inactive. Additionally, abilities used as weapons possessed or taught by a leadership are also not detectable in [event][filter_attack]. This PR is there to remedy this double problem.
Also remove matches_special_filter and directly use matches_filter.
It's better to disable them that to get in the habit of ignoring the CI fails
from the following two issues; this can be reverted once either is fixed.
glib has a bug where it builds things out of order which results in it failing
to build the dependencies, which fails the build.
https://github.com/microsoft/vcpkg/issues/28722
vcpkg also has a bug where it very often fails to use the cache of the
previously built dependencies even if none of them changed, which then makes it
rebuild all the dependencies again.
https://github.com/microsoft/vcpkg/issues/26601
If the glib bug was fixed, then the errors wouldn't happen since rebuilding the
dependencies wouldn't fail. If the caching bug was fixed, then the errors
wouldn't happen since it'd just reuse the cached dependencies.
Previously it was checked whether the logs directory was writable, which needed to get the log directory, which needed to get the userdata directory, which causes the userdata paths to get initialized, which triggered log rotation. This resulted in rotation being triggered before the logging path was set, which resulted in it always being skipped. Now log rotation is done in the logger class after it has been checked whether the logs directory is writable or not.
