The purpose of this is to make it easy for functions implemented in Lua to handle locations
in the same way as functions implemented in C++.
The location_set module has been updated to make use of this functionality in its setter functions.
Usage example:
Imagine a function foo with the following signature:
foo(bar : string, home : location, mode : string, target : location, moo : boolean) -> boolean
With the new read_location function it could be implemented as follows:
function foo(...)
-- First argument goes in bar
local bar = ...
-- Read location starting at the second argument
local home, n = wesnoth.mP.read_location(select(2, ...))
-- note: n will be 0 if a location wasn't found at that position
-- This could be an error, or it could be handled as an optional parameter
-- Next argument after that goes in mode
local mode = select(n + 2, ...)
-- Then read a location into target
local target, m = wesnoth.map.read_location(select(n + 2, ...))
-- Finally, read a parameter into moo
local moo = select(m + n + 2, ...)
-- Do stuff with all these parameters
return true
end
With that code, all the following invocations of foo work:
foo('a', 'b', true) -- both optional locations omitted
foo('a', 1, 2, 'q', 5, 6, false) -- locations given as separate integer parameters
foo('a', 'm', {1, 7}, true) -- first location omitted, second given as 2-element array
foo('a', some_unit, 'z', {x = 5, y = 10}, false) -- a unit also functions as a location
foo('a', 7, 12, 'q', my_leader, true) -- mixing different forms also works
* units - set image_icon for sidebar display of Cataphract
* units - remove inactive ability description for Diversion
* add recruit/recall to event list triggering check for diversion animation (Dunefolk Falconer)
The existing tag has a confusing name - it returns the chance to be hit rather
than the defense, for example 30 would be returned for a unit on 70% terrain.
The new tag returns a higher-is-better value.
The remove attribute for [event] was never added to the validation schema,
and using [remove_event] seems easier to search WML for. Let's just recommend
the new key and deprecate the old one.
This also removes backwards-compatibility.lua altogether.
It's no longer correct in the general case to add backwards compatibility code to this file, so removing it entirely avoids situations where compatibility code is incorrectly added there.
In the C++, this removes the commented-out old GUI2 API entries, and
adds show_dialog to the gui module directly instead of moving it in core.lua
this refactors the lua gui2 callback c++ implementation
Now the callback infrastructure also supports different
types of callbacks for a single widget. Furthermore
it also supports multiple open gui2 dialogs at the same time.
This now also makes the widget parameter of widget.find
manditory.
lua now has a widget userdata that can be used
to set/get widgets properties as one would
expect, a lot of the set/get_dialog_xy function
were converted into modifiable properties of
the widget userdata. This in particular allows
us to get rid of the strange 'path to widget'
type of arguments of gui2 functions.
It currently generates lot of compiler wanrings,
I will fix this in a later commit.
One of the main advantage is that it makes it
much easier to add new api, previously a lot
of functions where overused, probably because
that was just easier than creatign a new
function. For example set_dialog_value returned
multiple value of listbox objects. (the
compatibility path doesn't support this
particular feature yet but i don't think it is
important, it probably wasn't even used at all,
since it also wasn't documented).
This also adds some new features, like an 'add_item'
function to add an item to a listbox, a 'type'
property of widgets to query the type of a
widget and a 'item_count' property to count the
number of children in an item.
Im still not 100% sure about the
property /function names, in particular:
1) i might rename 'items' to 'elements' or
'children' in some functions. Not sure yet
2) I might rename the 'value' property to
'value_compat' to make clear that its only
supposed to be used by the
backwards_compat.lua code.
A next step in improving this api might be
to introduce a (reusable!) 'window' userdata
so that the implementaion of wesnoth.show_dialog
would become:
```
function wesnoth.show_dialog(wml, preshow, postshow)
local dialog = gui.create_dialog(wml)
preshow(dialog)
local res = dialog:show()
postshow(dialog)
return res
end
```
However this is currently not really possble
since the pure existance of a gui2::window
object blocks the gui1 code (the main game view)
from receiving events. So we clearly cannot luas
gc take ownership of gui2::window objects.
returns all items on a locations, this allows is to
remove quite a bit of code in the dropping.lua file
of world conquest since that can now just use items.lua
instead
This adds an additional `test_result` attribute to [endlevel], intended for use with the automated unit tests. This allows for the unit tests to differentiate a pass/fail result separately from scenario victory or defeat, which allows for more accurately determining the outcome of a test as well as addresses the potential, for example, for a scenario to be expect to pass because of the {SUCCEED} macro but instead passes because the scenario ended as a victory through some other method.
Additional unit tests which were the original motivation for this change are also added as part of this. They test, as much as possible, that events are executed at all, and are then also executed in the expected order.
* Units - Dunefolk - first draft at Falconer branch of skirmisher
* Dunefolk - revision to Falconer line
* Units - dunefolk - some progress on falconer standing animation
* Units - dunefolk - attack animations for falconer
* Units - dunefolk - defense and melee (partial) attack anims
* units - dunefolk - WIP lvl3 falconer
* units - dunefolk - revise falconer
* units - dunefolk - animation work on Falconer line
* units - dunefolk - falconer ability diversion revised to affect enemy chance-to-hit. Animation filter/trigger not yet resolved
* units/abilities - dunefolk falconer diversion ability-related animations mechanism
* units - dunefolk - sky_hunter animation frames
* dunefolk/abilities - fix diversion animations to work on die event
* abilities - schema validation induced correction
* abilities - diversion animations - attempt to fix case of undo movement
* units - dunefolk - finish some cosmetic issues for Falconer line
* units - dunefolk - wmlindent
* use on_undo over select in diversionability
undoing can only change the 'diversion' state if the original action also did,
so there is no reason to check it in all 'select' events.
* fixup
* minor clean-up
Co-authored-by: gfgtdf <daniel.gfgtdf@gmail.com>
this code handles wesnoth.persistent_tags which is used by all addons. The previous behviour would mean that an addon that uses wesnoth.persistent_tags wrongly would also break other code that uses wesnoth.persistent_tags like the [item] implementation.
One of the cases fails due to something in find_vacant_tile - perhaps someone else can figure out how to fix this?
If nothing else, setting check_passability=no in the [move_unit] should do it, but I'd prefer not to have to do that...
