Engine: replace a "plugin return value" hack with something appropriate #2403
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Necessary for #2313 (indirectly).
There is this very old hack which I invented while porting script VM to 64-bit back in 2012. When I've been rewriting script VM to work with RuntimeScriptValue struct, instead of a plain int32, plugins were becoming an issue, because there was no way to change the return values of their functions without modifying plugin API (and each existing plugin). And if we keep plugin functions cast to something returning an int, then we cannot know if that's a pointer, and which kind of a pointer that is (which exactly dynamic object type).
Back then I introduced a "temporary" hack: have a GlobalReturnValue object, which is assigned whenever plugin does anything related to the managed objects: create, register, resolve a handle, add reference, and so forth. Then hope that it is the value that the plugin is intending to return from its function. Silly as it is, this naive solution actually worked, for the actively used plugins at least. That's why it was forgotten about and never replaced.
But of course this is not a correct solution, simply because a plugin does not have to return a dynamic object that it touched last, it may return something completely different, previously saved instead.
The new solution I'm trying here is based on a simple but more logical assumption:
Therefore, we try the plugin function's return value as a address, and ask for its respective IScriptObject (dynamic object manager). If we succeeded, then we may assign a RuntimeScriptValue as a "Script Object". If we fail, we assign one as a "Plugin Argument", which may be anything else.
TEST LIST: