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).
Previously by default langcode_to_string() would only look at languages based on them meeting the minimum percent translated to be selectable by default from the main menu. This is incorrect since an add-on's translation has no relation to the state of the translation of mainline.
