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
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.
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.
Closes#9633Fixes#9591
This could also have been fixed by simply adjust the clip rect origin on left alignment (such an adjustment was present for the other alignments), but honestly there's no reason to be messing with the clip rect here when we can set the width directly. The floating_label internals would set the maximum text width to clip rect if no max with was otherwise specified.
This fixes an issue where the bar borders would always be one pixel wide, regardless of the zoom level or game render scaling which made the bars stand out badly amongst the pixel art. This brings us closer to the old look from the surface-drawn days.
This is also an experiment with using normalized, fractional coordinates for rendering instead of absolute screen coordinates. I'd like to take this approach in more places, so this is a good proof of concept.
I'm not sure how it's possibly useful, but apparently this can be sent by the python client
This reverts commit fdc8d92fe6c38c995e0ef02c7fd219841da41ad8.
Turns out the loss of precision over subsequent uses of subrect results in incorrect rendering, even if you round in point_at.
This makes it a non-member function so it can work with both rect and SDL_FRect as input.
This is mainly for the units dialog code, which hides all the sorters beforehand. I decided to put it here, but in future we might want it to be more targeted, in case it becomes an unexpected side effect.
Even though we direct all intermediate rendering to our own backbuffer, SDL recommends clearing the window backbuffer before drawing to it. I don't know if this changes anything with our usecase, but best to follow their recommendations, since SDL interacts with the underlying display driver.
