This was the last thing that was missing for complete support of all
function parameter declarations.
To ensure parameter lists stay valid a unit test was added that will
validate the argument lists and cause the test to fail if they cannot be
parsed.
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.
Collision groups as previously coded were unusable due to Lua 5.1's lack of support for bitwise operators. This fixes that deficiency in two ways:
1) Objects now have the functions `addToCollisionGroup` and `removeFromCollisionGroup`
2) An `evaluateNumericSEXP` function has been added for returning SEXP results as numbers (so that the bitwise SEXP operators can be used)
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 can be used for producing even leaner builds for standalone
servers. It also provides a nice architecture verification since now
using internal OpenGL functions will cause a compilation or linking
failure.
This allows a script to create its own execution context so that it can
control when a coroutine is valid to play based on custom data.
Also adds a function which causes a coroutine to end in an error.
The previous API only allowed very limited access to the audio stream
system. These changes add full support for playing all types of audio
streams via a dedicated API.
1) Upgrade the pilot file code to correctly save flags whether entries are added *or* removed
2) Make the tech-db/tech-db-multi ship flag handling consistent
3) Add scripting support for intel entries
4) Add scripting support for adding and removing entries from the tech room
5) Minor cleanup
This adds access to the command briefing data parsed from the mission
file to the scripting API so it can be used by the UI scripts for the
high res UI.
Also switches the animation support to using the generic anim to use
streaming to improve performance.
This adds an Antlr grammar for parsing argument lists instead of using a
hand written parser. This allows to write much more complicated syntax
constructs and have all the code being auto-generated. It will also
produce a much more correct parser instead of having all those hacks in
the hand-written one.
This also adds (in addition to supporting the previous syntax) support
for function types along with support for them in HTML and JSON output
formats.
The ANTLR generated parser is included in source form so that it is not
necessary to have an ANTLR installation around if you are not going to
change the grammar. Also includes the necessary runtime code from Antlr.
This adds a mechanism for running generic operations at specific points
of the frame execution. This can be used by any part of the code an not
just Lua since it simply executes std::functions. It also adds an
"execution context" concept that specifies in which situation an
operation should be executed.
This is then used by the Lua Coroutines code for resuming coroutines at
specific points instead of always when the awaited promise resolves.
This adds a simple parser that takes the existing argument
documentations and parses them so that better documentation can be
generated from that information. This should be sufficient for providing
proper documentation generation for the most common and simple cases of
argument lists (type, name, possible default value, and optional
groups).
This will ensure that Lua functions will always be executed in the
correct Lua state. Since we now have multiple threads (which are
different lua_State objects) it is possible that the current code could
execute a Lua function in the main state instead of the thread that is
currently executing. This can lead to weird behavior and probably also
to issues inside Lua.
This can be used by Lua code to trace the runtime of their code in the
same way the engine already is capable of doing for most in-mission and
mission loading code.
Also adds some tracing scopes to the libRocket code
This makes the necessary campaign room API available to the scripting
API so that it can be implemented using libRocket. Also adds an
engine.sleep function which I needed for making my Lua debugger work
reliably.
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.
Previously the scripting call `gr.drawOffscreenIndicator` did not properly draw the indicator and/or return coordinates. After some bug hunting it turns out it is because there gauge was not being set to active. This PR adds that line and retores the intended functionality. Tested and works as expected.
Since the original release of FS2, internal strings have been translated to their English entries in strings.tbl but external strings have not been translated to their English entries in tstrings.tbl. It appears that string translation was universal until it was disabled via a hack, probably due to FRED idiosyncrasies (see comment in `fred_init()`), and then not re-enabled for release. PR #2343 re-enabled it, but this turned out to have undesirable side-effects since many mods used incorrect XSTR indexes for external strings.
This PR restores the previous behavior and also cleanly separates localization into translated and untranslated modes. FRED will always run in untranslated mode. FSO will run in translated mode for all languages except English, where it will run in untranslated mode UNLESS the new option `$Use tabled strings for the default language` is enabled in game_settings.tbl.
This adds the capability to have a Lua script that does not need to use
our table syntax at all but instead defines the hooks by calling API
functions. This also makes it possible to add hook functions at runtime
if the script requires that.
Also clean up some unused debug stuff.
asarium