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 PR fixes a bug where an invalid lua font handle would not be properly returned as invalid. An invalid handle is returned properly if the font name is invalid, but not if the index is invalid, thus this PR fixes that.
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 adds some auto-closing code to the scripting API of the CFile
system. If a file has to be auto-closed then an error will be displayed
to let the the script writer know that something is wrong.
This should not break existing scripts since causing file handle leaks
should never happen and if it does, this will make it easier to find
these issues.
When setting LUA_ADDITIVE_BUTTON_CONTROL, the setButtonControlMode() function (in l_Base) would return "LUA OVERRIDE BUTTON CONTROL", and when setting LUA_OVERRIDE_BUTTON_CONTROL, "LUA ADDITIVE BUTTON CONTROL" would be returned. This commit simply swaps these back so that the appropriate return value is with the corresponding enum value.
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.
Nobody ever thought to add a reset-post-effects SEXP to complement set-post-effects, so this remedies that. Also, a few minor edits were made to the scripting documentation.
This adds a playback property for making the movie loop to the start
when the end is reached. The way this is done is by simply keeping the
decoder running even if the end of the movie is reached. Then the movie
is reset to the beginning and decoding continues. The player detects
this reset by examining the frame times which keeps the playback
constant.
This also includes support for this in the movie scripting API.
This is similar to the other changes I already posted. Here the sound
instance handles are converted to their own handle type which will make
it easier to use the sound API.
This adds an API for the scripting system which allows it to load and
display movie files using the standard movie player code which includes
multi-threaded frame decoding.
The bounds check was not correct for 1-based indices. I moved the
Lua->C++ index conversion before the bounds check so that it makes
more sense.
Also, atoi isn't a reliable way for converting a string to an integer.
Ideally it wouldn't be an optional argument at all, but that would break backwards-compatibility, so instead it'll just return an invalid ship handle instead of calling ship_create() with a class of -1. In addition, the Assert from ship_create() meant to guard against invalid ship_type values is now an Assertion that actually says what the invalid value of ship_type was, to make future debugging easier.
This converts the previous int handles to a strongly-typed wrapper
handle which will make the API more self-documenting and will ensure
that wrongly used handles are detected at compile time.
I already found a few mistakes with these changes which I also fixed
here.
This adds a scripting API which can be used for adding and removing
background from a mission similarly to the existing SEXPs but with full
support for floating point numbers.
This was requested by Axem on Discord.
This adds a new class which allows to create type safe resource handle
types. At the moment, the engine uses ints pretty much everywhere for
providing handles to resources created by the specific subsystems. Since
all ints are the same to the C/C++ typesystem it is perfectly legal to
pass a sound handle to the graphics API as a buffer handle which will
obviously cause issues.
This adds a new type called "ID" which is a wrapper class for a generic
handle but with added type safety. An instance of this class cannot be
passed to a function expecting another type of handle which provided
compile-time type safety for these APIs.
As an initial test I converted the game sound handles to this new type.
I already found a bug in the mainhall system thanks to this new type.
The mainhall used the game sound handles as sound instance handles which
probably meant that that specific code never really worked right. I
removed the code since there was no better alternative for fixing it.
The current particle system uses dynamic allocation of particle
instances for keeping track of particle instances. This adds unnecessary
overhead in case the code does not need a handle to this particle which
is the case in pretty much all instances.
The new non-persistent particles are stored in a standard vector without
dynamic allocation which should make the processing steps using this
vector much faster and allow better scalability in case more particles
are used by a mission.
Since atoi return 0 on error the code tries to access the waypoint list
with index -1 which causes an assert in the lookup code. This fixes that
by using the error detection capabilities of strtol.
Taylor Richards