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.
Implements the feature request from issue #610.
As an aside, this PR also patches the `ship_set_subsystem_strength` function (which is only used by the debug console and in the event you fire at your training instructor) to use the same code as the `set-subystem-strength` sexp. This properly handles submodels blown off, sounds, etc.
Fixes a minor bug that incorrectly draws Rectangles to a scripted HUD gauge. The third and fourht arguments needed to be width and heigth, not x2 and y2.
This adds the following functions to the scripted gauge API: drawCircle, drawRect, and drawLine. Also note that I created an additional function, for HUDGauge:renderCircle_unfilled, becuase the precedent shown by having two functions for `gr_unfilled_circle` and `gr_circle` and adding a fourth argument to `renderCircle` seemed to affect a lot of other functions.
The new gauge can be accessed by the scripting API with which a function
can be set which will be called when this gauge is rendered. This can be
used for exposing the HUD gauge positioning and RTT options to the
scripting API without a lot of work needed for the script writer.
There is currently only one rendering function implemented since this is
only a proof of concept.
Switch from 3x specific is_arriving functions to a single with params
Change flag names; replace "ndl" with "dock_follower"
Change dock-arrival helpers to not set follower flag on leaders
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.
There's a number of issues fixed here:
* Radar blips of docked ships were the wrong colour in stage 1
* You could target docked ships in stage 1
* Docked ships thrusters were visible in stage 1
* Hyperspace warptype ship could initially appear at their
warp-destination, then spring back to the correct location to complete
the rest of their warpin (because a docked ship had higher speed than
the dock leader)
There may also be a number of other subtle bugs with docked warpin;
e.g. I suspect (but haven't tested) that AI turrets could fire on
docked ships during warpin
These should also be fixed
Lastly, fixes issue #1867
If various functions on l_Control_Info were called while Player was nullptr, FSO would CTD due to a null pointer dereference. This commit adds nullptr checks to avoid the problem.
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.
When using a string to define the appropriate control in the useButtonControl() function (in l_Control_Info), the command definition was being divided by 32 when the appropriate mathematical operator was modulo; as a result, the only controls that could actually wind up being referenced are these four: TARGET_NEXT, MAX_THROTTLE, END_MISSION, and MULTI_MESSAGE_HOSTILE. By using the modulo operator, the string lookup now appropriately references the relevant button.
This can be used by the various subsystems for cleaning up Lua
references before the Lua state is destroyed. This avoids having
dangling references to the Lua state which would cause segfaults later
on.
The first subsystem to use this is the dynamic SEXP system which had
dangling references due to keeping Lua references to the SEXP functions.
This fixes#1954.
These were all cases where the parameter was the new value when setting
a variable. The variables should always be initialized when that code is
reached but it is still better to check the pointers before using them.
These were found by @niffiwan.
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.
asarium