previously this was only possible by storing the unit and then unstoring
with advance=yes. Unstoring a unit can cause a lot of overhead if the
unit is complicated. so i added a way to do it without [unstore_unit]
headers from lua/.. contain macros that can break other headers in
wesnoth, boost or other libraries.
In this case it was a macro
#define cast(t, exp) ((t)(exp))
defined in lua/llimits.h that broke a boost header.
persistent=no does not imply that the side does not have a recall list:
1) persisent=no did prevent units from this scenario to be carried over
to a next scenario but it did not prevent units from a previous scenario
to be carried over to this scenario.
2) [unit] in [side] and [unit] in action wml can give recall units to
nonpersistent sides.
3) The wiki does not mention that a side with persistent=no cannot have
recall units.
So i removed checks for [side]persistent= so that [unstore_unit] and
wesnoth.put_recall_unit can put units to the recall list and also tidied
up some other code that assumed sides with persistent=no to not have a
recall list.
I removed the NONE value of LEVEL_RESULT because 'LEVEL_RESULT==NONE'
was basicly the same information as '!end_level_data.transient.disabled'
I removed end_level_data.transient.disabled and instead store the end
level_data as an optional<end_level_data> to remember whether we already
have an end_level_data
I removed the SKIP_TO_LINGER value of LEVEL_RESULT because it was not
possible that play_scenario returned SKIP_TO_LINGER (so i removed that
code in playcampaign.cpp that handled this case)
I replaced playsingle_controller::level_result_ and
end_level_exception/struct::result which both held more or less the same
data with end_level_data::is_vitory, in case of QUIT the
optional<end_level_data> is empty (none_t)
I also reordered the if cases in playsingle_controller::play_scenario to
simplify.
msvc liked the previous code but travis said:
usr/include/boost/optional/optional.hpp:526:5: candidate constructor not
viable: no known conversion from 'const config::attribute_value::yes_no'
to 'argument_type' (aka 'const bool &') for 1st argument.
optional ( argument_type val ) : base(val) {}
I hope travis likes this version.
adds [result] tags in [endlevel] as suggested in
http://gna.org/bugs/?4960
the following [endlevel] attributes can now be given side spcific:
'result', 'bonus', 'carryover_precentage', 'carryover_add'
In the normnal case we show a victory message on a client if any of the
local humans is victorious, but we have to watch out for border cases
like when there are no human sides and behave just like we did
previously in this case.
This also fixes a bug that the calculated carryover could be different
from what is shown in the message (see comment in playcampaign.cpp that
was removed by this commit)
This also removes some unused functions in carryover.cpp that were
incompatible with this commit.
The default with_border value is false. Certain functions, such as game_lua_kernel::intf_get_locations
pass an explicit true value to with_border. This commit allows any user-facing tags using those
(such as [store_locations]) to pass an explicit override.
this commit also changed slightly the way that wml menu events
are synced. previously they were run via "run_in_synced_context",
now they are run via "run_in_synced_context_if_not_already", which
makes it safe to fire them from lua (a synced context).
This line was not an error -- it is legal in C++ to bind a const
reference to a temporary value. It's only slightly more confusing
than usual in this case because the string it is built from is
a C-string owned by lua, and the temporary std::string object is
implicit.
I don't believe this commit will even make any difference in the
compiled code, it's only slightly simpler and more readable.
this commit causes wml menu items to have their events registered
not during construction but only when "init_handler" is called.
it refactors the wmi_container object to do this when it
constructs new items via the [set_menu_item] path.
this is necessary because the items might be constructed before
the event queue even exists, and we want them to be able to
persist and be reactivated when a new campaign scenario starts.
more testing is necessary to determine if all code paths, including
carryover and reloading, are still working after this commit, and
the earlier commit 6fc1ac1bb2
See also discussion of bug #23115.
This commit broke the lua unit modify method for unit.side, the
reason was that I wasn't sure how to handle a safety check that
required a reference to the gamestate -- I'm not totally convinced
that units should not be allowed to be made in lua if there is not
an active gamestate.
However instead of commenting out this line, I should have
replaced it with a version that does the same thing without the
safety check... not sure why I didn't do this the first time.
This fixes lua errors that occur in the test scenario startup.
first we now throw a lua error instead of just giving a log message this
makes it easier to find the source of a bug becase we now get a
stacktrace.
Also we now give a more detailed error message.
There were two bugs here:
In 6603de667b, in unit::advance_to,
the code fragment that resets the animation set based on the new
unit type was made to run after modifications had been processed.
Since modifications may introduce new animations, this caused these
to be discarded.
In d7bf5be356, [animate_unit] was
broken by accidentally not including it in the lua kernel
initialization routine.
In lua 5.0, the preferred way to define custom metatables is to
use registry keys defined by pushing pointers as lightuserdata to
lua. (These pointers can be pointers to arbitrary constant objects,
as long as they are unique.)
In lua 5.2, the preferred way is to use constant strings as the
registry indices, and several lua API functions are introduced:
"luaL_newmetatable, luaL_setmetatable, luaL_checkudata,
luaL_testudata" which greatly simplify the operations for creating
the metatable, assigning it to a userdata, and checking if the
userdata has that type.
This commit switches over the keys associated to textdomains,
translatable strings, vconfigs, and lua gui2 dialogs to use the
new style, and simplifies some of the implementation details in
the process. For instance, luaW_toconfig no longer has to have an
optional argument to an index on the stack where the tstring
metatable is... these details are handled by the lua API instead.
