* 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]>
* avoid undefined behavior from UNREACHABLE on reachable code paths
UNREACHABLE expands to __assume(false) / __builtin_unreachable() in
release builds, which is undefined behavior if the code is ever actually
reached. Many UNREACHABLE sites only guard against unexpected-but-
possible runtime states (values from tables, mission/save files, network
packets, scripting, or user input), so reaching them should degrade
gracefully rather than invoke UB.
Replace UNREACHABLE with Assertion(false, ...) at all such sites. It
still pops an error in debug builds, but in release it is a harmless
no-op that simply falls through to the following code. Sites that are
genuinely unreachable by local invariants (e.g. a switch over a bounded
random number) are left as UNREACHABLE.
A few converted sites had no safe fall-through -- an uninitialized read,
null dereference, or null call would have followed -- so they also get a
minimal recovery: initialize the value, guard the dereference, return
early, or skip the offending item.
Where the converted site was a simple guard of the form
if (x) { Assertion(false, ...); return; }
hoist the check onto the invariant instead:
Assertion(!x, ...);
if (x) { return; }
This states the expectation directly and shows the offending value in
the debug popup, while keeping the same graceful runtime degradation.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* addendum
After consultation with Lafiel, use UNREACHABLE in situations that are effectively impossible even if not provably impossible. UNREACHABLE = "this shouldn't ever happen"; Assertion = "if this ever happens, it's a coding error". Also fix a few other sites and change a couple to Warnings.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
* use std::move() for local variables that are copied but not reused
Addresses ~140 Coverity "Variable copied when it could be moved"
defects across 74 files. Every std::move() targets a local variable
whose value is consumed by push_back, emplace, assignment, lambda
capture, or a function call and is never read again afterward.
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
* clang: use std::make_shared
* clang: use std::make_unique
* address feedback
---------
Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>
FSO doesn't appear to use this any longer. And even when it was enabled the
requirements made it largely useless anyway. Removing to clean up cfile a
bit and so we don't have to keep maintaining it.
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.
There was code that could interpret any Lua type as an argument for printing, so I adapted it to be used in ba.print(), ba.warning(), and ba.error(). Also ba.println() seemed like a useful thing to add.
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.
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 allows the coder to test for the existence of a hook variable by comparing it to `nil`. The engine will currently error out and crash if you try to access a nonexistent table field, which is useful for catching typos, but has the disadvantage of disallowing a perfectly reasonable Lua coding practice. So this change checks whether the missing field is part of `HookVariables`, and if so, rather than throwing an error, it just prints a message to the log.
This fixes three issues where the Lua stack was not cleaned up properly:
- On hook execution, the return value was left on the stack
- For ADE initialization, the global tables were left on the stack
- In libRocket, a metatable was left on the stack
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 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 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 will provide a proper error message when such a function is called
that will mention the name of the function and that it is deprecated and
cannot be used anymore in the targetted engine version.
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 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 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.
The current scripting hook is pretty simple and straight forward but it
makes a couple of scripting applications harder to implement than
needed.
For example, a lot of scripts need to do some work every frame
for all or some objects. The script needs to manage an internal list of
all the objects that are affected by that list which includes removing
invalid objects to conserve resources. This effectively mirrors what the
engine already does and adds unnecessary overhead.
In these changes I added a generic event system which can be used by any
part of the code for providing callbacks when a specific event occurs.
As an example, I added hooks for the pre- and post-move events to the
object class which are called before and after physics are applied to an
object.
I integrated that feature into the scripting system so now a script can
simply register a function as a callback which will be called whenever
the target event is executed.
