Explicitly use t_str() to avoid an ambiguous construction from
7bee8ee157, which made GCC9 error out because it
could alternatively use t_string::t_string(const string &).
Resolve the merge conflict from 26d1ca7a7d
Possible fix for #4058, with the following logic:
* If non-empty, [unit]overlay= is handled by adding modifications
* unit::write will always output an empty overlay=
* The Lua API's get_units() will still provide the list of overlays
* [effect]apply_to=overlay can now remove as well as add overlays
* [remove_unit_overlay] is implemented with [effect]apply_to=overlay
Using [object]s with durations hasn't been tested, but expected effects:
* An expired add= followed by a non-expired remove= will simply cause the remove=
to have no effect when std::remove(overlays_ ...) is called.
* A remove= followed by [remove_unit_overlay] cause the [remove_unit_overlay] to be a no-op,
and the overlay will reappear when the first remove= expires. This edge case is already
documented as unsupported on the wiki.
Simplify the public interface for movement, vision and jamming costs to only
the movetype class and a read-only interface called "terrain_costs". Changes
to terrain_costs now need to be done through the movetype instance, so logic
about how movement, vision and jamming interact with each other can be handled
in movetype. This fixes a possible dangling-pointer issue: the default
copy/move implementation in movetype::terrain_info would have copied raw
pointers, without ensuring that those pointers remained valid.
This feels too complex, but also feels like time to merge it and do any further
cleanup as a separate commit. For example, there's only one place that calls
make_data_unique, and one place that calls make_data_shareable. Merging the
functions should make it clearer.
The terrain_info class is now a private class implementing the terrain_costs
interface, previously it was a public class with raw pointers to other
instances of itself, and a copy constructor which copied the raw-pointers
as-is. One of the raw pointers is still there, but it's only non-null when both
instances involved are owned by one instance of movetype.
=== To cherry-pick back to 1.14 ===
Cherry-pick the tests from 358f564301.
* units.cpp: needs a manual merge. Remove the `set_attr_changed(UA_MOVEMENT_TYPE)`
call from the master version.
* movetype.cpp: take the changes in this commit, in each case the conflict is
the change of std::shared_ptr::unique() to std::shared_ptr::count(), which
has been replaced with make_data_shareable() and make_data_writable().
* movetype.hpp: take the changes in this commit, deleting the old terrain_costs
class and adding functions to movetype.
* Removed create_neutral_surface in favor of a surface ctor that takes w/h dimensions.
* Removed make_neutral_surface in favor of a surface::make_neutral function. Most usecases of this were
to make a copy of a surface anyway, so I added a new surface::clone function
* Moved the pixel format validation and conversion to the surface class. Now *all* surfaces should be
guaranteed to be in the 'neutral' format. Any new surface that is created (with clone() or the dimension
ctor will be in that format, and any time a raw SDL_Surface* ptr is assigned, it is also converted. This
applies both to the ctor and assignment operators.
* Removed create_compatible_surface. All surfaces should be compatible in the first place.
* Removed surface::assign was in favor of simple assignment operators. The existing assignment operators
already just called assign().
* Removed surface::null in favor of the implicit SDL_Surface* conversion operator for consistency. We were
already using null and implicit pointer bool conversion, so I decided to go with the latter. I was going
to add an operator bool(), but it was ambiguous in surface-to-surface comparisons.
fixes#1451
Currently advancements can be changed in two ways:
1) Via [advancefrom], this causes OOS in multiplayer
2) Via certain campaign etra defines, this has other disadvantages see
The new [unit_type_fix] that is accepted in [scenario], [multiplayer],
[era], [modification] , [campaign] and [ressource] changes the advancement
of a unit type only for one game and has non of the disadvantages of
the other two methods.
We should also deprecate the other two methods.
In Caves of the Basilisk, give the monsters names so their descriptions
would show in-game. The descriptions show in the tooltip, so
a non-empty name is required in order for players to be able to summon
th tooltip.
Show ability of a selected unit as active/inactive with respect to
mouseover hex. For example, selecting an Elvish Ranger that stands on a
forest and highlighting a water hex should show the "ambush" ability in
gray.
When multiple negative heal abilities are present, the game now
chooses the ability with the lowest value. The leadership ability
now also uses the same get_composite_value function that is also
used by most other abilities
In the case of strong and resilient, the tooltip should now be easier
for players to understand.
Old:
"+4 HP and +1 HP per level"
New:
"+4 HP
+1 HP per level"
Old:
"battle axe and hammer: +1 damage and +1 HP"
New:
"battle axe and hammer: +1 damage
+1 HP"
previously when the unit had a movement effect, expire_modifications
could remove movement via the `movement_ = max_movement_;` line in
the movement effect implementation.
now experience_modifer only changes the unit types xp, it no
longer has an effect on [effect]s that change xp, in particular
it fixes#1796 where a apply_to,increase=max_experience,2 [effect]
added one or two max_experience to a unit dependend on how much
max_experience it had before. This was in particular a problem
because this effect would only behave like this during unit
construction, not when an object is added ([object]).
