* Add lua mouse button event handler that can be consumed.
* Fix middle-mouse down/click not getting sent to lua
This is a flexible event handler mechanism to allow for more advanced
add-on features. It does not allow the add-on to consume the value
however, so there's no mechanism for the add-on to requrest the default
action not be executed.
We would normally deal separately with mouse down, up and click, with
the later being an event where the mouse has gone both down and up on
the same UI component. However, Wesnoth's code seems to allow a mouse up
on many UI components to serve as a click, so this implementation
follows that behavior.
This addresses issue #7949
The mouse handling code needs an overhaul, so this patch works with it
in it's current state in the best possible way. The revised code
attempts to restrict clicks to those events where a mouse went both down
and up on the same map tile. It is able to do this with the right mouse
button as well as X1 and X2, but must work as existing click events are
treated for now.
This means that "left click" is managed via the `left_click()` function
which occurrs at mouse down, "right click" via `right_mouse_up()` when
the right mouse button comes up, and the middle button's click behavior
is coded directly into mouse_handler_base::mouse_press() (so no function
is called) and "clicks" when the button comes down. The new
`on_mouse_button()` code will allow the mod developer to consume any
click event, preventing the default behavior, and also receive event
callbacks for up and down events, although the return value is ignored
for these calls and left and middle click occur on mouse down.
The code keeps record of the previous hp to prevent unit:transform form changing it. But it reads it before the object was added which prevented the object from increasing the units hp.
a free random training on easier difficulties should only be given in the first scenario. (Otherwise they'll accumulate to 5 free trainings at scenario 5.)
Fix https://github.com/wesnoth/wesnoth/issues/7923 .when we want to detect an ability with value=0-20 and an ability with add=15 is present, this is detected because the system assigns a value of 0 when 'value' is not present, and so the system matches abilities that do not use 'value' or even no numerical value at all. it is therefore necessary to decide that the absence of an attribute is a non-correspondence to the criteria.
There are questions about how this filter should treat empty values, and the
use cases that we can think of can be implemented in other ways, for example,
if we want to look for big damage boosts, then we could filter for
`add=5-infinity` `[or]` `multiply=2-infinity`.
The simple answer seems to be to remove it from the API before we freeze for 1.18.
There's more discussion in issue 7944.
using overwrite_specials alone means that we have only two possibilities, either one_side is chosen and in this case if the ability used as a weapon carrying the attribute is applied to the unit (apply_to=self), the other abilities are the same type applied also to 'self' not carrying the attribute will be overwritten, but those of the opponent with apply_to=opponent will be kept in the list; or else both_sides is chosen and all abilities of the same type that do not carry the attribute will be overwritten. To be able to use the attribute in abilities like [damage] for example, it is necessary to be able to be even more selective as for a 'charge' type leadership with multiply=2.5 but which must not be combined with the classic charge and without overwriting the aute [damage] as backstab, [overwrite_filter] to only match damage with apply_to=both and active_on=offense is then interesting.
adding priority allows you to select that it ability can use its overwrite_specials attribute while the others can be overwritten in the same way as an ability without the attribute. Finally, this system makes it unnecessary to limit the use of the attribute to abilities used as weapons but also to special weapons.
