- ls:invert(w,h,[border_size]) takes an absolute complement as if the map were the given size
- ls:invert(map) takes an absolute complement relative to the specified map
- ~ls is only available in the game kernel and takes an absolute complement relative to the real map
This is the real cause of the breakage in 5a9c24c4e79d624e34aa475949a4aa49b1984322 and d04bd2bf5d2ad932ca9bb3203f4ff9f91411e261.
A returned location now has both x/y and 1/2, so the location_set logic removed the x/y but kept the 1/2, causing it to break when converted to a config.
This makes it use rawget when the value is a table, which fixes it.
- place_shroud and remove_shroud no longer accept a shroud data string or the special string "all"
- new functions are added to convert between lists of locations and shroud data strings
- place_fog, remove_fog, is_fogged, and is_shrouded aren't changed, only moved
- 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 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
This accomplishes two main things:
- Creates a mapgen_helper.lua module containing functions useful for Lua map generators
- Paves the way for allowing the cave generator to produce scenarios and accept user configuration
variable v does not exist... the function is not commented so I
can't be sure of the intention, but the most backwards-compatible
fix is to not pass argument v, so that it will be nil as before.
this bug was revealed by enabling lua "strict mode"
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.
