* WML: Adjust the weapon selection logic for [kill]
The previous logic simply did not make sense, especially for the secondary weapon.
For example, it would ignore the secondary weapon specification if the primary weapon was not found on the secondary unit, which does not make any sense.
The cases that this changes are:
- There is a secondary unit and a primary attack, but no matching attack was found. Previously it would use the default, now it pretends that attack exists.
- There is a secondary attack specified, but no primary attack, either because it was unspecified or because it didn't match any attack on the secondary unit
In both these cases, the animation runs as if a matching attack exists, rather than using no attack and choosing the default animation.
Adjust the log level too.
Also backtracked the removal of wesnoth.get_recall_units, which is now available as wesnoth.units.find_on_recall - it's just more convenient than passing x=recall to wesnoth.units.find
This prevents the animator from holding a strong reference to the target unit, which was keeping the unit object alive and thus preventing the unit halo, if any, from disappearing.
(cherry-picked from commit 7d6e2b2a10)
fix code problems found by luacheck
Second iteration of the process, now handling data/lua/wml/*.lua
luacheck command used to find bugs:
luacheck ./*.lua --globals wesnoth wml --codes --ignore 542 213
Additionally, error code 211 (unused variables) could be ignored,
as using underscore convention `_` is controversial in
wesnoth ( see https://github.com/wesnoth/wesnoth/pull/2380#discussion_r162519341 )
Actual bugs found:
* items.lua, access of global `write_name` instead of local `cfg.write_name`
* kill.lua, typo `primary_unit` -> `primary`
* bad code style: global `i` instead of local `i`
(would conflict with 3-rd party code if it would use global `i`, too)
This reverts commit 70b468070b.
As I said in the commit message, the fix is not pretty, and
@CelticMinstrel said in IRC that a different fix would definitely be
better. I'll fix the problem by having an animation automatically
release the unit when done, instead (next commit).
The problem was that the kill animation retained a reference to the unit.
Triggering a Lua garbage collection (which destroys the animation object)
fixes it, although it's definitely not a pretty fix.
Closes pull request #2313.
The [kill] tag can run animations. But it can also fire the `last breath` event, which can call [kill]. When we get back to the original [kill], the unit is gone, causing an error attempting to run the animations.
Added a check to ensure the unit is still on the map before we attempt to run the animations.
The Issue also requested that [harm_unit] pass the unit causing the harm into the [kill] tag so that `last breath` could use the secondary (killing) unit available like it does elsewhere.
Closes#2298
Regression from commit d40a9e930b.
In that commit I removed a redraw after the death animation of a killed
unit has been played, but just to be safe, I then added a redraw after the
unit has been erased from the map. Turns out it's not a good idea because
[modify_unit] operates by killing and recreating the unit.
This commit simply removes the redraw after erasing. Hopefully we aren't
relying on [kill] triggering a redraw somewhere.
[ci skip]
