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.
- Removes 1-argument form accepting an integer ID
- Adds 1-argument form accepting a string ID
- Now accepts locations either as 2 arguments or as {i,j} or {x=i,y=j}
previously there was one function which sometimes returned a wml table
and sometimes a map integer to wml tables dependent on its parameters.
Now there are 2 different functions: wesnoth.synchronize_choice and
wesnoth.synchronize_choices. the first one handles the case where you just
want to get a choice from one side and thus it returns just one wml
table. The second function handles the case where you want to get
choices from multiple sides. that function retruns a table of wml
tables.
I also added an optional string parameter to that function specifying
the type of that choice (this is useful to make replays more robust and
readable)
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]
This change maintains backwards compatibility
- [advance] will still work if present
- attempts to add [advance] via Lua will instead add [advancement].
- The "category" property is mainly for use by scenario designers; players will be able to hide labels based on this
- The "creator" property is meant to allow players to hide labels placed by specific other players
- Map editor allows setting the "category" property
previously there were 2 flags share_view=yes/no and share_maps=yes/no,
but only 3 possible settings (share both, share none, only share shroud)
(so share_maps= was ignored if share_viewv=yes). This made the wml code and
the c++ code needlessly complicated.
Now these 2 flags are replaced by share_vision=all/shroud/none
http://gna.org/bugs/?23677
units advancements is an array of wml tables.
This also adds template lua_push/lua_check functions wich also accept
vectors or similar. The file scripting/push_check.hpp was written using msvc
which implements look-up in template functions differently so it might be
necessary to fix it for other compilers by adding forward declarations of
those template functions.
Instead of creating an enum, the MAKE_ENUM macro now creates a struct
which holds an enum and provides functions for enum <-> string
conversion.
This has multiple advantages:
1) We don't need MAKE_ENUM_STREAM_OPS anymore.
2) The generated struct is much easier to use in templates
3) We don't allow implicit to int conversions anymore.
4) The enum values are now declared inside the structs scope.
