Description
The original design inspiration for Orchestrator was to be as close to a statically based language as possible. The intent was that following this pattern would allow developers to learn the APIs and know what does and does not work together, which is often much more difficult to learn in a duck-typing language.
However, other visual scripting systems offer the option to inject an auto-typecast node at compile time, allowing users to connect arbitrary object pins. This helps reduce graph clutter and gives the user more ownership.
One open question is how to manage user connections.
For example, if a function's input argument is a Node3D object, but I want to connect that to a function called get_frustum(), which is only available on a Camera3D, then how exactly would the action's menu present that option to the user without prior knowledge of that context?
Implementation ideas
No response
Description
The original design inspiration for Orchestrator was to be as close to a statically based language as possible. The intent was that following this pattern would allow developers to learn the APIs and know what does and does not work together, which is often much more difficult to learn in a duck-typing language.
However, other visual scripting systems offer the option to inject an auto-typecast node at compile time, allowing users to connect arbitrary object pins. This helps reduce graph clutter and gives the user more ownership.
One open question is how to manage user connections.
For example, if a function's input argument is a
Node3Dobject, but I want to connect that to a function calledget_frustum(), which is only available on a Camera3D, then how exactly would the action's menu present that option to the user without prior knowledge of that context?Implementation ideas
No response