You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A JavaScript code block has by default "runtimeScene" as the first argument, then an optional "objects", then eventsFunctionContext.
In practice, this "runtimeScene" is NOT the runtime scene for objects and behaviors. Instead, it's the instance container.
We should probably not encourage using runtimeScene inside a function of a behavior and object. Instead, we could:
keep runtimeScene for JS functions in scene events
keep only eventsFunctionContext for JS functions in scene events and expose getInstancesContainer() on eventsFunctionsContext. Make an invisible const runtimeScene = this._instanceContainer.getScene() to keep compatibility.
(bonus not linked to JS functions) Rework code generation to use eventsFunctionsContext.getInstancesContainer() instead of runtimeScene?
If we search "runtimeScene" in all .cpp/.h files, usage is already fairly low.
The text was updated successfully, but these errors were encountered:
Solution for "runtimeScene" Refactor
Problem Overview:
Currently, the runtimeScene argument in JavaScript functions is misleading because it actually represents the instance container, not the runtime scene itself. This can lead to confusion, especially in behaviors and objects.
Proposed Solution:
1.Restrict runtimeScene Usage
Keep runtimeScene only for scene events, where it genuinely refers to the runtime scene.
Avoid using runtimeScene in JavaScript functions for behaviors and objects.
Add getInstancesContainer() in eventsFunctionContext
Introduce a method getInstancesContainer() in eventsFunctionContext to access the instance container explicitly.
example:
eventsFunctionContext.getInstancesContainer = function () {
return this._instanceContainer;
};
Modify Code Generation
Update the code generator to replace runtimeScene with getInstancesContainer() where needed.
If backward compatibility is required, we can introduce
Like:
const runtimeScene = this._instanceContainer.getScene();
4.Audit Existing Code
Search for runtimeScene usage in all .cpp and .h files.
Refactor instances where runtimeScene is used incorrectly, replacing it with eventsFunctionContext.getInstancesContainer().
Before Refactor:
function exampleFunction(runtimeScene, objects, eventsFunctionContext) {
const variable = runtimeScene.getVariables().get("myVariable");
}
After Refactor:
function exampleFunction(objects, eventsFunctionContext) {
const instancesContainer = eventsFunctionContext.getInstancesContainer();
const runtimeScene = instancesContainer.getScene();
const variable = runtimeScene.getVariables().get("myVariable");
}
Improvements:
Clarity: Clearer distinction between the instance container and the runtime scene.
Consistency: Standardized approach across behaviors, objects, and scene events.
Backward Compatibility: Older projects won’t break during the transition.
A JavaScript code block has by default "runtimeScene" as the first argument, then an optional "objects", then
eventsFunctionContext
.In practice, this "runtimeScene" is NOT the runtime scene for objects and behaviors. Instead, it's the instance container.
We should probably not encourage using runtimeScene inside a function of a behavior and object. Instead, we could:
runtimeScene
for JS functions in scene eventseventsFunctionContext
for JS functions in scene events and exposegetInstancesContainer()
on eventsFunctionsContext. Make an invisibleconst runtimeScene = this._instanceContainer.getScene()
to keep compatibility.eventsFunctionsContext.getInstancesContainer()
instead ofruntimeScene
?The text was updated successfully, but these errors were encountered: