variable_as_array_h::operator() expects the range to be passed as a pair (startindex, endindex). We accidentally passed the range as (startindex, size) instead.
Shadowm reported bugs related to global variables but most likely this can also lead to segfaults in other situations (some uses of [set_variables]).
the value of "player_id" is only used to set the userlist in mpwait in
case there is no other userlist available (usualy there is another list
available) adding a side number doesn't make sense.
We also use a std::set for gathering the player_id values to make sure
there is no player_id twice.
the only reason thart this was called variable_info_3 is that it was my
third try to implement it (my second try that used boost::variant for
the differnet states turned out to be too slow)
Formerly, the option buttons at the bottom of the dialog were laid out
by redoing some math instead of tracking the dialog's menu position,
which is always valid (even when there is no menu!). I'm not entirely
sure why, but the math reprised here became bogus with the introduction
of top buttons in commit 045bda037d78056866bdd918b51708d44d2bf515 (for
the Add-ons Manager dialog), in particular for dialogs *not* using them
(such as the in-game Statistics dialog), even though the menu is still
laid out correctly.
So instead of reinventing the wheel, we really should just take the
menu's position and height as a baseline for the bottom option buttons.
At worst the height is 0, but the position is still within the dialog's
boundaries (but see below for an unsolved corner case).
This commit reverts commit f60ef98e275fd3d16733f7d5dfd7314920841fd5
(a.k.a. 69521000dc5c45f9745131ee13e76493e14fefaa in 1.12) that's part of
PR #263, because it turns out that the solution proposed there is only a
convenient workaround that solves a layout issue for a single dialog
(Statistics, see bug #22379) and introduces a new bug for another
(Add-ons Manager, see bug #22791).
Regardless of the cause for #22791, the approach put forward by this
commit is more consistent with best practice (laying out widgets from
top to bottom each row's geometry depending on the previous row's), so I
have decided to not look too much into it.
It should be noted that the layout of bottom option buttons breaks
entirely for dialogs missing a menu, both before and after the
introduction of top buttons. Currently there is no GUI1 dialog that
attempts to insert option buttons while lacking menu entries, so I'm not
too concerned about this bug (which affects 1.10 too!). Besides, some
day GUI1 is supposed to go the way of the dodo and stop bothering us
with its marvelous inflexibility and arcane logic.
When a C function terminates, it should not leave bogus elements
on the stack, or the stack can eventually overflow.
This is not as critical for C functions which are called by lua,
because they return an int explaining how many values on the stack
are important. But for C++ facing functions it is very important.
This reduces the code complexity quite a bit. Now all the lua api
defn's are in the scripting folder, and the generator object itself
needs only construct a kernel and ask it to do things, and catch /
rethrow its exceptions with appropriate type and additional
descriptive info.
read here: http://www.lua.org/manual/5.1/manual.html#lua_CFunction
When the C function returns with "1", all but the top entry are
discarded from the stack. If this function could be called again
and again without ever returning and without ever dumping the stack,
then there could be a stackoverflow, but in this case it's
not possible.
In initial commit of the new lua kernels, I introduced a problem
by trying to use luaW_pcall and lua_pcall interchangeably via
polymorphism. This doesn't work because their return types don't
match, and it's alot of work to change luaW_pcall syntax. Besides
this there's no reason we can't use the custom error handler
everywhere.
This commits adds protected_call and load_string functions to lua
kernel base. These are an intended replacement for luaW_pcall,
and replace the "run" function. They do better error reporting
and allow to specify an error handler.
The error reporting is very flexible -- by default we select a
an error reporting function associated polymorphically to the lua
kernel, so the in-game lua kernel can send chat messages, and
others can do something else. However an arbitrary handler may
be specified, and exceptions instead of logging may also be
requested.
If a lua script is passed as an argument to wesnoth, wesnoth will
actually instantiate the application_lua_kernel defined in the
previous commits, initialize it, and run the script in that
environment.
