Previously, if a script called a function that called another scripting
hook, some hook variables might be removed. This was the case since
after executing the hook the code would remove the set hook variables
again. If these variables had the same name as previously set variables,
they would overwrite and corrupt the state the original script expected.
This was unexpected behavior for script writers so this puts values on a
stack and only adds or removes from the stack instead of overwriting
values. This should make the hook variable state consistent for scripts
even if scripting hooks are called indirectly.
This can be used by script code for reliably storing Lua values without
having to build a custom serialization format.
The C++ code can also be used by other code modules that want to
serialize data. The new classes simply return a byte array with an
unspecified format.
At the moment this uses a plain JSON encoding but could be extended in
the future to include either compression or BSON encoding if necessary.
The format is future compatible by using a simple header to identify
different kinds of formats.
The previous system was kind of hacky and made things a bit inflexible.
This improves that system quite a bit and also adds unit tests for the
hook variable functionality.
This adds a Lua API for representing asynchronous operations and running
coroutines based on those operations comfortably. This is very similar
to features other languages have introduced such as C# or JavaScript. In
fact, the whole "promise" thing is derived from how JavaScript
represents these operations.
This is the initial and very basic system for supporting async
coroutines in Lua. There is no native support for running these
operations at specific points (they run whenever the awaited promise
resolved) or making sure they do not leak through different game states.
This allows to use the built-in lua "require" function with our file
system. This will help organize complicated scripts and it will also
allow to use libraries which were designed for this system.
To enable this change, this includes a new mechanism which allows to
load scripts from the default file system so that the files don't need
to be included in every mod. The default files can be overridden by a
mod if a special mod-table option has been set, similar to how external
shaders are handled right now.
Goober5000