If the variable index is absent it now defaults to 0.
This fixes bug #18728. It might also fix all FOREACH and lua while
loops as Gambit described but I need to double check.
(if race uses name instead of male_name its name doesn't show up.)
I corrected the use of z_name as a default when neither z_male_name
nor z_female_name are presented. We now have race names below unit
names in the side_bar for non-gendered units like Wose and ships.
Perhaps the problem only occured for wooden units?
(Game hangs at loading screen after flushing caches and save index and
pressing F5)
Previously, when the .cache/wesnoth directory was deleted, while
wesnoth was running and then the cache was refreshed with F5 from the
startup screen, wesnoth hung. The crash occured because wesnoth
didn't recreate the cache directory after startup, when it is
recovering from the cache not existing. Now it makes a new cache
directory as needed.
...when assigned "" an empty string.
Previously the attribute became EMPTY which caused problems in lua
which always expects a string in gmatch. It still reports an
attribute equal to "" as empty, but its type has been changed to TOKEN
so that is returns the string "" to lua. This fixes bug #18727 (in
part), bug #18667.
(fix for bug #18695 and bug #18737)
The reason for the bug was that buffering was activated and deacticated
at wrong times.
Events added (or removed) during the current event call stack do not
have effect until the base event has run out. The code previously to
adding the [event]id= feature behaved this way and it is now (again)
this way. Although it's still not exactly clear to me *why* this
buffering is done, adding event handlers which were just added during
the current call stack already to the active ones (FR bug #18713)
would require modifying the array of active handlers withint the same
loop where we are iterating over it, which is always a problematic
thing, and this in an area where every mistake quickly results in
fatal WML engine bugs...
This should be subject to further testing with scenarios featuring
complicated event structure envolving custom events, [fire_event]s,
event ids and removing of events.
The reason for me not being able to reproduce with my testcase was
that I didn't have shroud enabled. ;)
The reason for me being able to reproduce only sometimes was (I think) that
originally, buffering was initialized with random data so it sometimes
delayed the preload event and sometimes it worked correctly.
The pillars need to cover the spaces between the hexes
This is easier than moving all pillars manually
Also, the shift up didn't seem to improve the appearance of any
particular terrain combination
...or campaign (bug #10969)
I'm really not sure why this limitation was in place. Perhaps there was
an architectural constraint back when it was introduced making it
impossible to know about global [theme] nodes right after startup.
My testing indicates this doesn't have any ridiculous side-effects.
Units with non-standard attributes were converting those atributes to
an integer, which the attribute_value::to_int function was converting
to 0, which unit::set_state interpreted as STATE_SLOW. Changed it to
passing a t_token.
...for mixing horizontal_grow and horizontal_alignment by commenting
out the latter
> error gui/parse: horizontal_grow and horizontal_alignment can't be
combined, alignment is ignored.
Fixes most problems with the tall encampment keep (e.g. it now looks
correct beside normal encampment keep)
Some keeps now connect like castles - no base transitions though
Allows the single-hex macro to be used without directly accessing the
internal macros
terrain-graphics.cfg updated to use non-internal macros
Satisfies comment at start of internal-* files
