This also fixed a potential memory leak in ccInstance::CreateEx().
From upstream 30167df0690e0a771a8eb4f14a4d6a72da526b49
Also remove unreachable code (same condition checked twice in a
function) as that caused a compilation error with the changes above
otherwise. This change is part of upstream commit
881d31966cf7600c9b5628fff4c194d628196f4a
It's illegal to reference an inactive member of a union and the types
are not layout compatible (and even not of the same size).
Instead, store every value in a integer of pointer size and cast
pointers to and from it.
This should really fix bug #13557.
call_function returns from PluginMethod::operator() which returns a
NumberPtr.
Its two calls also expect a NumberPtr but the function returned an int.
This should fix bug #13557.
This potentially allows to access any metadata while passing string pointer around the script functions.
As a consequence: never wrap external buffer, always allocate your own.
From upstream 043758b1bb5116f038c5c597d17fe9524b92b3c2
The script handling part of the engine appeared to be too fragile and dependent on
a precise timing of **deleting** a ccInstance.
For example, restoring a saved game may execute in the midst of the call to
RunScriptFunction(), at the "post script cleanup" stage, while there are still references
to ccInstance on the engine's call stack (and few other places). If anything prevents
ccInstance's disposal at this moment, that would in turn lead to logical errors due to
the game scripts "instances" counting. The most outstanding consequence is that the
script exports are kept pointing into the deleted memory and not re-registered after the save is restored.
Overall, the script handling part of the engine would benefit from a major refactor,
with a goal to make it safe and consistent, but this is not something I might do at the moment.
From upstream 1f6abf4b678f77825c710d4ae18b57ff8f882c93
After the updates to cc_instance this should now work
From upstream b1e4f75141ce88b3146f55ecd9d7a95378428072
and 49e8aa0b566dea4ce025f9530a9f2392dbe67a33
I realized this recently that SUOs were not registered in the script exports
properly. In AGS standards the object having a memory buffer should
register that buffer's address directly, so that it could be read and written
to directly. That is how strings, arrays, and any other structs are exported.
This also how the engine plugins can access the data if they use script API
to retrieve it.
There have not been any script API working with custom structs earlier,
but there is since 3.5.0 (few functions returning managed Point struct).
Plugins won't be able to use them correctly without this fix.
From upstream 9658c71528676acb386e2c638e782cc4e7d2afe5
This removes an excessive separation between "static managers" and "dynamic managers",
and let use the single ICCDynamicObject interface when working with both kinds.
Simplifies RuntimeScriptValue and StaticArray classes.
Picked out most common implementation into CCBasicObject, which is inherited by
AGSCCDynamicObject and AGSCCStaticObject.
From upstream 781632881dd64af2b57b789617da15107bca9451
The idea is that the old variants have internal names with number
(signifying number of args), while the latest variant has a name without number.
Make sure there's a distinct function for each variant, and older vars are calling later ones in a sequence.
These calls likely to be inlined.
From upstream ca48926a37e848a1bcc162f77cc81e63ec7a1ca0
This might happen when assigning a local pointer variable, which was not cleaned either with ZEROMEMORY or MEMINITPTR.
from upstream a989f3ed0150fc0218c47b3d7ac3c655d072e78a
Hubert Maier
Thierry Crozat
Le Philousophe
D G Turner
Walter Agazzi