- get_terrain and set_terrain replaced with direct indexing operations
- get_map_size mostly replaced with either the iterator or an on_board call.
Only a few cases really needed to know the size of the map for some other purpose.
- shroud and fog operations, village owner, time areas, and location filters
- get_terrain_info replaced with terrain_types table
- Map generation functions create_map and create_filter
The method of accessing terrain on the map has drastically changed.
- wesnoth.get_terrain and wesnoth.set_terrain are both deprecated
- wesnoth.terrain_mask still works but is moved into the wesnoth.map module and now takes the map object as the first parameter
- The map's terrain is now accessed exclusively via indexing on the map object, ie map[{x,y}]
- You set terrain by assigning a terrain code; the position of ^ in the terrain code now determines the merge mode
- The replace_if_failed option is now manifested as a function that converts any terrain code into a special value that, when assigned to a location on the map, uses the replace if failed logic.
The map object has a few attributes in it:
- width and height are the total size, including borders
- playable_width and playable_height are the values returned from wesnoth.get_map_size, which is now deprecated
- border_size is the third value from wesnoth.get_map_size
- data converts the map to a string
- Special locations are now part of the map object. The length operator is deprecated.
- other than that, wesnoth.map is treated as if it were the metatable of the map object
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
