* Automatically generate the isValid() Lua API function for handle types
If an ADE object's stored type has an isValid() member, ade_obj now registers an isValid function for it automatically. An explicit ADE_FUNC(isValid, ...) declared after the ADE_OBJ replaces the generated one, so types with special semantics (e.g. sound) keep their own. The 67 hand-written functions that merely delegated to the member are removed, and 26 types that previously exposed no isValid() gain one.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
* Add ADE_OBJ_VALIDATOR for index-based Lua handles
Int-index handles (shipclass, weaponclass, team, etc.) can now declare their validity predicate with a single ADE_OBJ_VALIDATOR or ADE_OBJ_VALIDATOR_RANGE line after the ADE_OBJ. The registered validator drives the generated isValid() function and is also honored by ade_set_args when the mod table asks for nil instead of invalid objects, which previously never applied to these handles. The 19 hand-written range-check functions are replaced, and loadout_ship, default_primary, default_secondary, and support_rearm_pool_team gain isValid(). Add a validator to HudGauge while we're at it.
Also fully qualify the scripting namespace in LuaConvert.h so its templates can be instantiated from the unit tests.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
---------
Co-authored-by: Claude Fable 5.1 <[email protected]>
The return value of `lua_tostring()` is NULL if (and only if) the string conversion failed. Many places in the code did not check for this situation, which led to the crash in #6290.
Fixes#6290.
This introduces type parsing for all types used within the scripting
documentation. This improves the generated JSON output and also
validates new code via the unit test.
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.
I added a pretty generic container structure for the scripting
documentation when adding JSON output. However, I did not use that new
structure for the HTML output since that was just too much work.
This moves the HTML output over to the new structure so now the
scripting API handling code is independent from how the resulting
documentation is generated. I also moved that code out of the main
scripting code which removes quite a lot of clutter in those files.
This is mostly a straight port of the old code with no significant
changes (except the changes to make it use the new data).
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 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 moves towards defining the hooks in the code module that executes
them. Also provides the API necessary for better documentation of hooks.
This only covers a few hooks as a test and demonstration of the new API.
If no issues are found with this it can be extended in the future.
This adds JSON as an additional scripting documentation output format.
This can be used by external tools to examine the scripting
documentation and generate interface declarations or documentation for
any language. The existing documentation code is left largely in place.
This allows to mark certain functions or virtvars to be declared as
"deprecated" starting with a specific engine version. What this means is
that a special message will be added to the documentation stating since
when the function is deprecated and can contain an optional message. The
actual enforcement of the deprecation depends on the target version of
the mod so that we can stay backwards compatible.
If the mod supports the version since when the function is deprecated,
it will not be added to the Lua state which means that it doesn't exist
for the calling script. If the targetted version is before the stated
version, the function will still be added to the Lua state.
As the first function to use this feature, I have deprecated
createParticle in the testing library and moved it to the graphics
library with a new name reflecting that it creates a persistent
particle. I also added the corresponding function for adding a
non-persistent particle.
This is a system for storing arbitrary data in the config file and then
easily retrieving it later on. This has full Lua support for exposing
the available options in a custom UI and changing the values of the
options. This ported some of the existing command line options over to
the new system which is opt-in for the moment by using a mod_table flag.
This will automatically call the destructor of a type of Lua calls the
garbage collector for an object of that type. This is the last step
towards fully supporting non-trivial objects in the Lua API and all
previous workarounds have been removed.
This is pretty much similar to the value setting changes. This is a much
safer solution for getting values out of the scripting system which has
compile time validation for move-only types.
This commit changes the way the scripting API works by properly using
the newly available type information for moving the FSO resources into
the memory supplied by lua. This has full support for rvalue references
which will make it possible to use move-only types with the scripting
API.
This also makes the API much safer to use since it doesn't use pointers
to local values anymore which made it very hard to use the API in a
different context without causing issues.
This only covers writing the FSO values to Lua. Getting values back is
not covered yet.
This was previously used for allowing scripts to set arbitrary values on
scripting objects. However, it was used by only a few scripting
functions and, as far as I know, no script uses this features.
This removes that feature which simplifies the code ade_index_handler
of.
This also simplifies the code that handles the userdata for libraries
provided by FSO.
This maintains the type information which can be used for enforce
const-correctness and also for implementing more advanced ways of
handling the type information.
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.
As described in #1278, the current scripting system has issues with
handling non-trivial C++ types. Since fixing that deficiency is too much
work, especially since we are in a feature freeze, I decided to simply
enforce the usage of trivial types for scripting handles. Fortunately,
only two handles used non-trivial types so it was relatively easy to fix
those instances by dynamically allocating those and only storing the
pointers in the lua memory.
This fixes a bug in JAD-XA where the game would crash at the last boss.
Also, I noticed that the HudGauge handle used a copy of the hud gauge
rather than a pointer to the actual instance so I'm pretty sure that any
scripting changes to a custom HUD gauge simply didn't work before.
