This is used instead of the boost::bind and boost::function method
introduced before. It's a bit simpler than the boost::function code
in lua_cpp_function, and a bit faster / less can go wrong when we
don't use boost::fucntion.
It also fixes a potential future use-case -- if a lua state is
copied, but many of the functions in the environment are made with
boost bind, they become bad pointers since they point to the old
lua state, and there is no easy way to retrieve them. Using lua
extra space instead of bind ties the lua_State more tightly to our
C++ representation of it.
wesnoth.add_dialog_tree_node to add nodes to a tree_value
wesnoth.set_dialog_callback support for tree_views (triggers when the
selected node was changed)
wesnoth.get_dialog_value support for tree_views returns an array of
integers that describe the path to the currebntly selected node.
We use LUAI_EXTRASPACE to add a pointer to the lua_kernel_base in the lua_State
stucture, this makes is very easy to get a reference to the lua_kernel in
functions that take a lua_State* as an argument.
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.
The problem was that intf_require would assume use the wrong
lua_State* since it finds it using the kernel's this pointer. This
commit gives a version of "protected_call" which allows to use the
callback's lua_State*.
In the error handling routines for compiling and running a script
at runtime, don't construct a string directly from lua_tostring,
because if it is null that is a runtime error. Instead check for
this scenario.
In intf_require, when getting the "wesnoth" global, luaW_getglobal
is unnecessary and lua_getglobal should be prefered.
This collection of classes provides a framework whereby the engine
may provide scripting capabilities in any "context". A C++
function may declare a plugin context by providing a list of names
function objects, then may call "play_slice()" on this context to
transfer control to lua. A lua script may generate some arguments
and request to call some of these, then yield to the engine. C++
will run them until one of them signals an error, or that the
context is now invalid (using a boolean return value).
The intended semantics is that lua may only make requests
corresponding to the current context. As soon as a new context
is used (play_slice() is called again) the old context is invalid
from lua's point of view -- calling those functions is a lua
error but not undefined behavior. This should be the case even if
the old context has not been destroyed yet in C++, for instance
if a lua request resulted in a new context being created. There is
a system of locks in place to ensure that when old contexts are
invalidated, stale requests are discarded.
We also add the coroutine library to our lua base. This because
threads are run as coroutines, and writing them requires the use
of coroutine yield from the standard library.
This allows some sort of "drop into debug" mode for lua if your
script detects an error.
We could consider to actually add an "option to attach debugger"
as an error handling mechanism, but it might be complicated
because of wesnoth exceptions which must go through lua and be
treated as lua errors, and we cannot handle two exceptions at once
obviously, so the lua interpreter is probably not safe to run that
way in general. Anyways this commit does not do that.
This commit changes the majority of the wesnoth callback functions
for the game lua kernel to be private methods of the game lua
kernel. The game lua kernel is given direct access, via it's ctor,
to references of many of the things provided by resources. The
call back functions are modified to access these private reference
variables instead of resources, and they are added to the
scripting environment using the lua cpp function mechanism.
This greatly improves encapsulation and will eventually lead to
eliminating the resources pointers from the game lua kernel
entirely.
The solution in place was working but it was flawed in that unlike
with normal lua callbacks, the callbacks would find the userdata
with a pointer to themselves as the first item on the stack. This
breaks the normal lua stack discipline for callback functions.
This commit makes it work normally, removing the stack entry for
the function before it is called, and also making a local copy
of the function pointer in case the lua garbage collector should
deallocate and destroy it when it is removed from the stack.
Enables an ilua feature called "strict mode" in all of our lua
environments. This change causes lua to report an error if a global
variable is used before it is assigned. The benefits of this are:
- Improved maintainability of lua-based add-ons, since you get
better error reporting in case of a typo.
- Improved behavior of the lua interpreter console, since mistyped
or gibberish lines resolve to an error rather than "nil", which
the console treats as a legal return value.
It is possible to disable this or work around it in individual
scripts. For more info see release notes.
I mainly want to use this for random map generators, it would be
silly to rewrite this stuff in lua after we already have it in C++
(and unit tested there).
The lua show dialog used to get the video object from resources,
which is not ideal. In this version, lua kernel base internalizes
a pointer to the video object, and show_dialog is bound to a
method of the lua kernel base.
From now on, lua kernels which want to show dialogs need to be
constructed with a pointer to a CVideo, if it is null the lua will
fail with a runtime error.
The application lua kernel is constructed with the video for
game_launcher, and the game lua kernel is modified so that it is
owned by the play controller and not the game events manager, and
held in a boost scoped pointer rather than manually deleted. This
is because the game events manager doesn't have a video object,
also it conceptually seems independent of the lua kernel anyways.
The map generator lua kernels are constructed with NULL, but if a
user configuration dialog is provided (new feature) then when they
try to run it they will update with the mp_create's video pointer.
- Add an internal command logger to the lua kernel base, and expose
this.
- Redirect the internal lua `print` to the command logger.
- Add an external logger registration system to lua kernel, in
addition to the internal one.
- Add a lua console dialog which binds to a lua kernel base and
permits to review the contents of the logger and issue new commands,
and report errors.
- Add a hotkey binding to launch the lua console "`"
- Adds tab completion support to the lua console
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.
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.
