This also changes nearly all API functions taking locations to use the new functions.
As a result, these functions can now accept their location arguments in any of three formats:
- An array of two integers
- A table with x and y keys
- Two separate, consecutive integer arguments
Functions that return locations mostly still use whatever format they used before.
This is because changing return values is a more compatibility-breaking change.
This temporarily breaks compatibiliy for the following AI functions:
- ai.get_targets()
- ai.get_avoid()
- ai.get_attacks()
This also adds a 'color' parameter to wesnoth.float_label. It was already
previously possible to set a labels color using pango markup, but to
implement [unstore_unit] i need to support the color= syntax as given
by [unstore_unit]
This also adds a 'fire_event' parameter to wesnoth.put_unit to specify
whether the 'unit_placed' event is fired, this is needed to implement
fire_events=yes/no in [unstore_unit] but its also generally useful
for the same reason why [unstore_unit] has this parameter.
wesnoth.select_hex has problems with simply highlighting units without displaying
their movement range. If you set its third argument to false, the unit gets
selected, but no hex cursors appears around it. Using this allows us to simply
highlight a location with the hex cursor, independent of unit presence (select_hex
works funny if no unit is present).
i moved the 'description', 'usage', 'halo', 'ellipse', 'random_traits',
'generate_name' and 'upkeep' from cfg_ into unit member variables.
This main advantage is that its now clearer which unit type attributes
exist, also it is a little faster becasue it doesn't need string lookps
when accesing those attributes.
I used scoped_ptr<string> instead of just string to store 'usage',
'halo' and 'ellipse' because that is closer to the previous memory
layout.
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.
the cfg_ field of the unit class now doesn’t store the advancements and
the abilities anymore. Instead they are stored in separate fields.
I used boost::ptr_vector<config> because that’s similar to how config
objects store their child values internally. Unfortunately
boost::ptr_vector defines ptr_vector::value_type in a bad way so that it
cannot be used for BOOST_FOREACH loops value types, so i had to
change lua's push_check file to use T::reference to be compatible
with ptr_vector
This commit removes all child tags of the unit cfg_ because the only
tags that are now left in cfg_ are [variation] and [advancefrom] from
[unit_type], which werent used in [unit] and only caused the savefiles
to bloat.
This reverts commit eaa078a86d.
This attempts to fix gna.org/bugs/?23545 but is reintroduces
https://gna.org/bugs/?23115 so the commit that casues that one will
also be reverted.
This reverts commit c5e31e83f1.
This reverts commit 8447ebbb88.
[event] in [unit_type] was broken during a refactor of the gamestate
initilisation that also involved the commits above. The commits above
didn't directly cause this bug but reverting them makes fixing this bug
much easier.
We fix the bug by initilizing the game_events manager before creating the
units.
And related commits.
This reverts commit 545253ec2b.
This reverts commit 1215f65eb8.
This reverts commit 11664f4024.
This reverts commit e948df3424.
This reverts commit 3781e7839f.
This commits were reverted to exclude them from wesnoth 1.13.2 release because:
1) We are still unsure about the best name oftthese attributes
2) This breaks multiple campaigns, including LoW and the tutorial.
Feel free to revert this revert after 1.13.2 when thse issues can be solved..
And also other commits that used that function.
This reverts commit 0d8c008018.
This reverts commit 956e5f9322.
This reverts commit 8f35c4bfcf.
This reverts commit dcb265ae70.
This commit just contained too many bugs, including:
1) string_to_color not parsing any input correctly
2) string_to_color segfaulting on some input strings
3) missing backwards compability in [unstore_unit]
This means the Lua code implementing the WML tags are now solely
responsible for parsing the comma-separated id list. It just so happens
that I added code for that without realizing that I was duplicating
existing functionality on the C++ side.
As a result:
* wesnoth.add_time_area and wesnoth.remove_time_area can operate on
time area ids that contain commas (if someone feels this is needed
for some weird reason)
* [time_area] no longer warns about adding time areas with commas in
their ids (actually adding the first id of the list instead)
* [time_area] remove=yes and [remove_time_area] still handle
comma-separated lists of ids, in the Lua side instead of C++.
This makes the Lua API for this consistent with [event]/[remove_event].
Since the Lua API functions in question are undocumented at this moment,
it's unlikely this impacts anyone, really.
http://gna.org/bugs/?23490
This makes it possible to store variables inside the side with the lua
functions get/set_side_variable. These variables are carried over along
other side specific data(units, gold)
unit.variables now uses the same functionality as
wesnoth.get/set_variable (just for the unit variable instead of the game
variables) which makes it possible to access table values. Its also
posible to access subvariables as
unit.variables["list1[2].list2.length"]
Note that is not possible to use untore_unit/put unit inside those
effects becasue it will casue infinite recirsion.
Intead you can eigher use direct lua unit modification or use reuse
effects with wesnoth.add_modification(u, ..., , ..., false)
The main problem here was, that [effect]s are often applied in unit's
constructor where is was previously not possible to create a lua_unit
refering to that unit, to fix that i had to change lua_unit, luaW_checkunit
and luaW_getunit.