When a ScriptClassDesc_t for is initialized (SCRIPTDESC), it recursively
invokes its parents initializers in order to obtain their pHelper
member.
Initialization is only done once, so repeated initialization is skipped.
Initialization includes assignment of a vector of ScriptHook_t's
(DEFINE_SCRIPTFUNC/BEGIN_SCRIPTHOOK), which must be initialized
beforehand.
Both of these use (static) globals; Within a translation unit,
initialization order is defined to be the same as the order of
declaration. So within a translation unit we must define all
ScriptHook_t's before the ScriptClassDesc_t using them.
A problem occurs with the parent initialization though, since there is
no defined order between translation units, meaning initialization of a
ScriptClassDesc_t can happen before its ScriptHook_t's, despite being
the correct order within its translation unit.
On MSVC it seems this issue is benign. On GCC/Linux however the
initialization of a ScriptHook_t essentially cleared whatever happened
during the initialization of the ScriptClassDesc_t, meaning many hooks
simply didn't work.
This situation is remedied by delaying the initialization of the
ScriptClassDesc_t's ScriptHook_t vector to only when the constructor of
it is invoked from its translation unit. This is accomplished simply by
adding a boolean parameter to the function (GetScriptDesc()) that is
true in the global constructor invocation, and false by default
(including when doing parent ScriptClassDesc_t initialization).
When false, a valid ScriptClassDesc_t pointer is still returned, which
is all that is needed for the initialization of the child
ScriptClassDesc_t. The value of the returned pointer is a fixed memory
location, and does not change due to the delayed initialization.
The script-helper must be initialized eagerly though, for the search of
a base-class helper. This also changes the SCRIPTDESC slightly to
accommodate the eager initialization of helper instance pointer.
Fixes#244.
The string argument refers to memory managed by the Squirrel VM. It has
no guarantee that the string will continue to exist after the hook, from
which this can be called, has finished executing.
To fix this, allocate memory to copy the string into and manage it as
needed.
They were broken, and only add for Quaternions was implemented, for
which there is a working QuaternionAdd() script function instead.
Fixing it seems like unnecessary work.
Instead of temporary allocating dynamic memory, which subsequently is
copied into another dynamically allocated piece of memory, provide a
temporary buffer on the stack.
The script value inserted into the VM still needs to allocate
dynamically though...
A few sites are adapted to not create a ScriptVariant_t from a temporary
Vector to avoid dynamic allocation there too.
cf. mapbase-source/source-sdk-2013#321
When assigning a null value in getVariant(), make sure a previous
SV_FREE is not carried over.
In SqurrelVM::ReleaseValue(), make sure SV_FREE is not kept after
Free()ing a value.
Type FIELD_HSCRIPT is removed, it never sets SV_FREE.
All dynamic memory is now free`d via free(). For strdup(), this would be
the conformant way in standard C++. It matters not in Source, since both
use the same global allocator of the engine, but it is tidier.
Vector and QAngle are now allocated via malloc() instead of new to
provide symmetry.
This function is used to color impact particles.
On Linux I've noticed that this function sometimes is not successful on
retrieving the surface color, leaving an odd color to render the
particles with. The engine function TraceLineMaterialAndLighting() even
has a boolean return value indicating success.
GetModelMaterialColorAndLighting() does not though, but I still observe
failures (the color parameter is not modified). The color is initialized
with an invalid value. If it detects that retrieving the color failed
(engine function said so or the invalid value was left in place), this
now hamfistedly assumes a lightish grey color, but at least still
correctly (presumably) incorporates lighting information.
When this situation is detected, a warning is also printed to the
console. Because why not.
When a Vector or QAngle rvalue reference is returned from a VScript
function, the constructed ScriptVariant_t must not store the pointer to
it since it is, per convention, a temporary reference. Only do that for
lvalue-references, but do a copy when constructing from or assigning a
rvalue reference.
