Move `event_name_variable_substitution` to the top of the file, as it's testing
that the event triggers at all, before the tests that check which order the
events are triggered in.
The old `order_of_variable_events1` seemed to be a combination of two tests that
should exist, but the code didn't quite test either of them. This replaces it
with a new `order_of_variable_events1` and `order_of_variable_events3`.
Docs partially written by Pentarctagon, this started as a review comment
on the documentation PR.
when returning by value, the ideal way to store the returned value is
another value - using a const& works only because of how c++ prolongs
the lifetime of temporaries with const&'s
use move on strings that get destroyed at scope end
fix some formatting differences between a couple functions (parens,
spaces)
formatting to match the coding guidelines, including fixing up existing code
use [] to be consistent with the file
put { on the same line as for and if
C++20 will add std::erase_if as a convenience wrapper around std::remove_if,
handling the subsequent call to std::vector::erase. This simplifies readability,
avoiding the need to either store the result of std::remove_if in a temporary
or to put the second argument of vector::erase after the body of a lambda.
This adds utils::erase_if, which does the same thing. The C++20 function returns
the number of elements removed, but as none of the callers need that I've not
implemented it in utils::erase_if.
This commit omits the refactor of attack_type::overwrite_special_checking,
because that function is being worked on in parallel by Newfrenchy. It'll be
simpler for either of us to update it later instead of creating merge conflicts.
Using the first loop to define three boolean variables is more complicated than simply eliminating from the 'overwrite_specials' list the abilities not carrying the attribute then; if an ability with the attribute is present define a double for loop inside each other, where for each ability with overwrite_specials the type of ability removal from the returned list is defined at that time (one_side or both_sides).
I eventually want to be able to be even more selective about the abilities that can be removed or not and extend the use of the attribute beyond chance_to_hit. When (and if) these two PRs will be merged in master, I will have to add 3-4 lines of hardcoding to implement the filtering). Building a list instead of splicing the existing one is incompatible with this project.
the code that does autodetection looked like it could be put inside a
function - add a function that explains what it does
avoid some string copying and move where possible
use scoped ifs (c++17) to limit scope of local variables
Fixes#6898. The issue is that non-WML events added through the new events API
always disable undo with no equivalent of WML's `[allow_undo]`. The long-term
fix is to add a way to do that; however until that's available then listeners
for `moveto` need to use the old `on_event` API. The old `on_event` API can't
be deprecated yet, and this is enforced by our unit tests (the build fails if
there are unexpected deprecation warnings during the tests).
Reverts most of 7e234f8833282424b3535b9c334c751748f7222b. Does not revert files
that only listen for non-undoable events such as `die` or `new turn`.
Reverts the deprecation part of #5663's 8cd133263058a5df85f64988e348d2cf54d13a48.
From 5 to 4. Makes moving them from one water body to another somewhat less tedious. Likewise makes merfolk units a bit more viable on maps with separated waterways.
This was caught through a mishap with -Wshorten-64-to-32 on Xcode,
and seems like a disaster waiting to happen with a sufficiently
large input ("this will never happen" kinda stuff waiting to be
proven wrong).
