resolve [filter_attack/weapon]type= can check both type when it wait only effective type.
* add 'base_type' filter for detect original type of attack reagrdless of [damage_type] modifications
if for some reason the original type must be filtered instead of effective type, this attribute is here for that.
* add effective_type in formulas
nothing related to scenario balance has changed. Purely aesthetic refinements.
Co-authored-by: Tahsin Jahin Khalid <5283677+knyghtmare@users.noreply.github.com>
Use the floating point ability/weapon special value in damage calculation. Change some more internal calculations from truncation to rounding.
Fixes#9467.
See #7292, closes#2913. Apparently, this has never worked, and based on discussion in #7292, it's not even particularly useful. Plus, since it was removed from the schema two years ago, has been functionally deprecated since then.
The keys in unit_type remain untouched.
a1dd77a fixed Delfador's unset disable_stronger_amlas variable, but inadvertently broken the campaign due to an unset save_id for side 1. By placing Delfador inside [leader] instead, we resolve both issues.
Move semantics imply that an r-value parameter is no longer useful once
it is passed into a function. However, this function is used as a helper
function that only partially moves from cfg, so that the rest of cfg
can be reused by the caller.
I don't believe this is a good mechanism for a function call. This
overload is only used in one place: append(config&& cfg), so this commit
moves the relevant logic there. This ensures there's no re-use of a
moved-from object.
Splitting this out separately since it's a special case and API change.
Variables can be automatically moved when a function returns. However,
declaring a variable as const prevents that move from occuring (as the
move modifies the moved-from variable).
This checks when a move constructor for an object copy constructs its
member classes or parent classes. Copying unnecessary as all of the
members of the moved-from object can be clobbered by the move.
If a function takes in an rvalue, it's taking ownership of the object
that's being moved into it. If the object never moves that rvalue param,
then there was no point to moving it into the function.
As an example of a problem this catches, in context_manager.cpp,
replace_map_context_with took in an rvalue unique_ptr "mc" to a map
context. The function then swapped it with a given value in
map_contexts_. This swap was unnecessary because "mc" expired after the
function call was complete. It is more optimal to std::move(mc) into
the value in map_context_ that we were previously swapping with.
A forwarding reference is one of the form (note the template parameter):
template<class X>
void foo( X&& x );
The difference between this and a regular rvalue reference (where X is
not a template) is that foo() also accept lvalues. So it is possible to
call:
std::string s = "Example";
foo(s)
And if the body of foo(X&& x) std::moves x, then s will be invalidated.
This check warns on usage of std::move in this context and recommends
std::forward, which automatically determines whether to std::move
depending on whether foo() is called with an rvalue or an lvalue.
For working out which languages have 80% of core translated, TSG is
now relevant and the old tutorial isn't. This means that the 80%
threshold has increased by around 500 strings.
Add missing changelog entries for 1.19.8 directly to the changelog.
