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
Orchestrator presently is directly tied to the GDScript-based interface where implementation of input callbacks relies on overriding particular Godot virtual functions like _gui_input,_unhandled_input, and _unhandled_key_input. These callbacks provide the user with a reference to a specific InputEvent object that requires the called function to inspect the object and determine precisely what action to take, i.e.:
There are a couple of ways that Orchestrator could provide an abstraction to Godot's input system.
Custom node
The easiest solution is to build a custom node that takes the Ref<InputEvent> and decodes it to a series of various output flow pins based on type, additionally outputting multiple attributes about the event such as the keycode, position, pressed state, and the mouse button involved. Internally, this node is a glorified branch and type-cast abstraction.
Macro
Another relatively easy solution would be to delay this until we have the macro subsystem in play and then add a macro that effectively abstracts this behavior much in the same way as a C++ custom node would work.
Bake into the script binding
A more radical idea would be to bake this abstraction into the OScriptInstance implementation. For example, there could be a series of functions that are designed for each input event type, providing direct access to some common attributes for each event type such as mouse position, pressed/unpressed, keycode, etc. Then in OScriptInstance when the script is converted to a DAG, the instance checks whether such nodes are present and if so, wires up a Godot delegation.
For example, let's say there is this type of specialized function signature:
The OScriptInstance would then redirect all _gui_input, _unhandled_input, and _unhandled_key_input calls that refer to a key-based input to this specialized event node type. This reduces the need for the user to cast the event type before working with the event type.
Implementation ideas
No response
The text was updated successfully, but these errors were encountered:
Description
Orchestrator presently is directly tied to the GDScript-based interface where implementation of input callbacks relies on overriding particular Godot virtual functions like
_gui_input,
_unhandled_input,
and_unhandled_key_input.
These callbacks provide the user with a reference to a specificInputEvent
object that requires the called function to inspect the object and determine precisely what action to take, i.e.:There are a couple of ways that Orchestrator could provide an abstraction to Godot's input system.
Custom node
The easiest solution is to build a custom node that takes the
Ref<InputEvent>
and decodes it to a series of various output flow pins based on type, additionally outputting multiple attributes about the event such as the keycode, position, pressed state, and the mouse button involved. Internally, this node is a glorified branch and type-cast abstraction.Macro
Another relatively easy solution would be to delay this until we have the macro subsystem in play and then add a macro that effectively abstracts this behavior much in the same way as a C++ custom node would work.
Bake into the script binding
A more radical idea would be to bake this abstraction into the
OScriptInstance
implementation. For example, there could be a series of functions that are designed for each input event type, providing direct access to some common attributes for each event type such as mouse position, pressed/unpressed, keycode, etc. Then inOScriptInstance
when the script is converted to a DAG, the instance checks whether such nodes are present and if so, wires up a Godot delegation.For example, let's say there is this type of specialized function signature:
The
OScriptInstance
would then redirect all_gui_input
,_unhandled_input
, and_unhandled_key_input
calls that refer to a key-based input to this specialized event node type. This reduces the need for the user to cast the event type before working with the event type.Implementation ideas
No response
The text was updated successfully, but these errors were encountered: