A floating point literal without a type specifier is a double and
causes the float to be promoted to double as well. It has no
advantages in these cases so avoid it. (Found with gcc
-Wdouble-promotion.)
final syntax for these: all sides if neither side= nor [filter_side] are
present, all sides matching the ssf in [filter_side] if the tag is
present regardless of inline side=, and the sides matching inline side=
otherwise.
modify_side can't have inline SSF due to key conflicts. The other two
(and capture_village) already have inline SLF so it's a bad idea to
add an inline SSF. After removing filter_side in [gold] and
[modify_ai] this leaves 4 tags with possibly redundant side info
and confusing syntax (especially capture_village),
at the benefit of more backwards compatibility.
This is done by implementing an end_credits attribute for use in
[endlevel], [scenario] and [campaign]. The (boolean) value is stored in
saved games and defaults to true.
Example:
[endlevel]
next_scenario=null
end_credits=no
linger_mode=no
[/endlevel]
This will be documented later in the wiki.
This should make it so that action wml from [set_menu_item]id=X[command]
is always executed after an [event]name=menu item X, even if
that event was added in the same event callstack as the set_menu_item
was called.
Removes a menu item from the right click menu, the according event
handler if it had a [command] tag, and from being saved in the savefile.
Does not touch manually added events of type "menu item x".
Menu items were automatically carried over between scenarios so far,
causing potential savefile bloat by accumulating over the course
of a campaign.
Unless both the menu item and its command tag didn't have an id.
Makes it possible to remove the resulting event handler
in the same way [event]remove=yes removes events.
Unless I'm badly mistaken, event handlers caused by a menu item's command
should already be unique, so no id collisions are expected.
...and wesnoth.set_variable
This supposedly common problem (value of a set variable composed
of the values of other variables which perhaps don't exist or are empty)
causes corrupted savegames and makes :inspect fail. Hard to track on
wml side; there are probably a more ways of corrupting saves via empty
key or tag names.
These were the variable substitution delaying in the [object] code. It is
no longer needed due to the workaround [object]delayed_...=yes|no.
Removes repeated WML parsing. Reverts behavior to mostly what was in 1.8
If ABILITY_TELEPORT is added by an [object], or [object][effect][filter]
contains $this_unit, delayed_...=yes is required for the modifications
to work as expected.
However, if the same object wants to get variables substituted and
add ABILITY_TELEPORT to a unit, the code would have worked in 1.8
but doesn't in 1.9.
(bug #18893, bug #19225)
since they break compatibility.
This reverts
2011-12-16T01:24:54Z!anonymissimus@arcor.de
2011-12-16T04:06:47Z!Majora700@gmail.com
2011-12-16T04:08:22Z!Majora700@gmail.com
2011-12-16T04:14:58Z!Majora700@gmail.com
2011-12-16T20:13:27Z!anonymissimus@arcor.de
2011-12-16T20:14:08Z!anonymissimus@arcor.de
2011-12-16T20:48:39Z!Majora700@gmail.com
2011-12-17T09:46:29Z!Majora700@gmail.com
1. The internal type is a std::string, the lua getters/setters should
reflect that like all the existing ones already do instead of making
implicit conversions.
2. It doesn't make sense to convert the already translated string
into a t_string again upon getting it.
3. The setter in team.cpp you added is redundant.
4. The attribute is apparently not really meant to be modified
by lua or wml so a tag is no good idea.
get_time_of_day() = global ToD
get_time_of_day(loc) = local ToD using ToD areas
get_illuminated_time_of_day(loc) = local ToD using ToD areas and illumination
...to enforce the non-activation of the future unit map.
This prevents code called from WML events (drawing code, among others)
from building the future unit map.
(fix for bug #18879)
There was an implicit conversion config::attribute_value to int with
default 0. Strangely, this sometimes went well with my MinGw built and
also does for some time in Espreon's backtrace, but MSVC crashes early
where the resulting out-of-bounds problem occurs (actions.cpp:2366)
The unparsed vconfig from the [unit] tag is passed to the unit
constructor and filter_recall and event tags are taken from it.
[side][unit] did already no variable substitution, wesnoth.put_unit does
it only if passed a vconfig userdata to describe the unit.
According to a comment by mordante in variable.hpp, std::string& foo =
vcfg["foo"] is unsafe, and silene appears to have always used
config::attribute_value foo = vcfg["foo"] (without reference).
