- 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
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
* WML: Support [filter_side] in [item].
If [filter_side] is present then "team_name" is ignored.
Fixes#1477.
* WML: Compare [item]team_name to [side]team_name using intersection.
Fixes problems with substrings and when one or the other is a
comma-separated list. See #3533
* WML: Rename [item][filter_side] to [item][filter_team]
* Add changelog entry
(cherry-picked from commit 3a3b752881)
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)
name= has no effect but can be used to delete the item. I also changed
[item] to automatically create an id (in case no id was given) and
return that (only usable if called from lua).
I used the id= field from overlay class for this, it was previously only
used by the editor. Not sure if it is a good idea to reuse the id field.
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.
thonsew: The lua interface is not your playground. This is not the way
I want the lua files or its C++ interface to be modified. You are
invited to talk with me on IRC.
some of the main reasons:
-Your revisions contain lots of unneccessary changes, some of which
break existing lua or wml without a reason. Do you ever look at the
diffs?
-Your revisions pack a lot of unrelated stuff together into one.
2011-09-21T21:44:58Z!thonsew@yahoo.com makes sense in some parts and is what you should have
done in the first place.
1. Created a t_token metatable along with support code for indexing,
garbage collection, tostring, tonumber, comparison and concatenation.
2. Adjusted string comparison and lookup in lua code to work with
either t_token or string.
This addresses in part bug #18631, bug #18695. Before this lua was
treating all t_token as either tstrings or strings.
...t_token in place of std::string. t_token compares, copies, copy
constructs and hashes in 1 operation instead of proportional to the
length of the string.
since when running into this rare exception (if the SLF doesn't
matching anything) it could be hard to figure out what happens.
[remove_item] does nothing in this case now.
