This can be used like in the following example (note that without the
[unsynced] it would cause OOS becasue rand= might or might not be
called.):
[unsynced]
[store_side]
variable = "side"
side = "$side_number"
[/store_side]
[if]
[variable]
name = "side.controller"
equals = "human"
[/variable]
[then]
[set_variable]
name = "num"
rand = _ "two,four,seven"
[/set_variable]
[message]
message = _ "I want $num stones"
[/message]
[/then]
[/if]
[unsynced]
The following fixes were applied:
* cfg.__shallow_literal -> helper.shallow_literal, to allow calling the tag
from Lua as wesnoth.wml_actions.role
* added trim() to the for cycle
* deleted filter.role and filter.type after having copied their data, because
when calling the tag from Lua they ended up being deleted too early
* unit.role = cfg.role -> unit.role = role
previously this was only possible by storing the unit and then unstoring
with advance=yes. Unstoring a unit can cause a lot of overhead if the
unit is complicated. so i added a way to do it without [unstore_unit]
This is set up that there will be no newlines at the end of any section, unless you have
only a summary key, which no one would do. However, there will be a newline at the top of
the dialog if you don't have a win objective, but no one would do that either.
Note that because of newlines not showing up properly on Windows, this won't be viable
on that platform.
and for [store_locations] [store_starting_location] [store_unit_type]
see comment for 201d83f608 (fix [store_side] to allow explicit indexes)
As a side effect, this commit now also alows mode="replace"/"append"/default for
[store_locations] [store_starting_location] [store_side] [store_unit_type] which was
previously only possible for store_unit
After this commit, the "strict mode" lua variable errors may be
disabled with
ilua.strict = false
and reenabled with
ilua.strict = true
There will typically be no noticeable performance difference from
previously to this commit.
This is a bit simpler than the other methods described which
include using pcall or resetting the metatable of _G.
[store_side] variable= some_variable[0] ... [/store_side] would result in a wesnoth.set_variable(some_variable[0][0]. ...) call which we don't allow in master after https://github.com/wesnoth/wesnoth/pull/231. 1.12 would just ignore the second index in this case. I decided to rather fix [store_side] than to restore the 1.12 behaviour of set_variable (which wouldn't be harder).
This commit changes occurrences of the pattern `tostring(x) or y` to
`tostring(x or y)` in the following Lua scripts:
- `data/lua/wml-tags.lua`
- `data/lua/wml/items.lua`
`tostring(x) or y` is unlikely to do what the author intended (and is
pointless unless `x` is an object of a custom type with unusual
behavior), because `tostring` returns a string (`"false"` or `"nil"`)
if `x` is a falsy value (`false` or `nil`), and all strings are truthy
in Lua — thus, `tostring(x) or y` will (unless `x` is of a custom
type) *always* evaluate to `tostring(x)`, never to `y`.
`tostring(x or y)` should, I expect, give the intended behavior.
the ilua `_pretty_print` feature has the property that it sets _
to be what was printed, as an interpreter feature so that _
represents the results of the previous expression. However it
appears that this may conflict with some parts of our api, for
instance the _ is used to hold the return value of
wesnoth.textdomain in the lua implementation of [harm_unit].
Note that there is no actual bug that I have observed, I merely
anticipate that this _ feature won't be compatible with our
established gettext conventions.
the [endlevel] tag does alot of things that could quite comfortably
be split into several parts, like setting the next scenario, the
end level text, message duration, credits. this commit adds
separate lua api for each of these, leaving the rest in end_level,
and the lua tag implementation calls these variously.
