As we leap into spring, we're pleased to announce Orchestrator's next development snapshot build 2.1.dev1. This release will coincide with the Godot 4.3 release in May or June. Let's dive into the highlights of this release and what you can expect in future development builds.
Jump to the Downloads section and give it a spin now, or continue reading to learn about the highlights and other improvements in this release.
New Features
Android support
Orchestrator's goal is to provide visual scripting tooling to all users, regardless of the type of game or platform your games are targeting. With Orchestrator 2.1, you can now create games and publish them to mobile devices using the Orchestrator plug-in. The plug-in supports builds based on Android arm32
and arm64
platforms.
We are super excited to add mobile support for the community. We are looking to bring this to Orchestrator 2.0 later this month in a stable build update, and would welcome any community feedback!
Create / Destroy any Godot object
When Orchestrator 2 first released, you were not able to create new instances of objects, which meant that if you needed that type of logic, you needed to call into a GDScript
function to access this. Well, the wait is over with the addition of two new nodes called Create Instance and Free Instance.
The Create Instance node is designed to mirror the new()
function from GDScript or other languages where you create a new instance of an object. This new node is a huge improvement because it opens doors that were previously closed to Orchestrator, such as creating threads, accessing network peer objects, dynamically adding objects to your scene, and more.
The Free Instance node is a simplified variant of free()
that is designed to accept any type of Godot object, and it will deallocate the instance for you. If the object is a Node, it will be queued for deletion at the end of the frame. If the object is referenced counted, it will be unreferenced, and if the object is a pointer, it will be deleted. It truly simplifies knowing whether to use free()
vs queue_free()
from the GDScript world.
We're interested to know what doors this opens, so all the feedback is most welcomed!
New Signal Connections UI
Have you wondered which event callback or user-defined function in your Orchestration is linked to a signal in you scene? You're not alone, and Orchestrator has this covered. You can now quickly identify which functions are linked to signals directly from the component panel.
The green indicator button shows which functions are being used as signal callbacks. You can also click on the green button to open the signal connections dialog, identical to what you can access using the Gutter icons in GDScript:
New BitField Pin User Interface
Bitfields are a great way to assign flags to some value and use the least amount of memory as possible. However, they are also used not only to flip individual single bits in a value, but they can also include names that represent the enabling of multiple bits in the value.
A great example is in the PropertyUsageFlags
bitfield where PROPERTY_USAGE_DEFAULT
implies both Storage and Editor Visible.
We've improved the bitfield pin interface for function arguments so that the popup dialog separates the singular bit options from the multi-bit options. Additionally, using the PropertyUsageFlags
example from above, if you check the open for PROPERTY_USAGE_DEFAULT
, it will enable the STORAGE
and EDITOR
bits with a single click.
Usability Improvements
The following are a set of usability improvements in 2.1.dev:
When spawning Call Function nodes, function arguments now use their Godot metadata default values rather than the data type's default value. For example, if an int
field defaults to a -1
, it will now initialize as -1
rather than 0
(GH-215).
Spawning of function overrides such as _ready
or _process
will not be centered in the graph viewport after the node has spawned (GH-204).
With the Script tab open, changing the current active Scene would focus a new GDScript if the root scene node had a GDScript attached. This behavior has been implemented for Orchestrator's scripts, so if the Orchestrator main view is open and you change scenes with an Orchestration on the root node, the graph viewport will update (GH-207).
It was unclear which node to pick for certain constants or singletons such as Input
. This has improved as certain node types expose keywords that are now searchable to bring that node into focus when searched. For example, searching for Input
will now show the Engine Singleton. (GH-222).
There were some corner cases where the spawning of Call Function nodes did not respect the existence of a return value from the function call. This has been fixed, and you must place a new node instance for the method metadata to be recorded correctly. (GH-240).
Any autoloads you've registered in the project are now shown in the All Actions view under the category Project > Autoloads
. This makes accessing autoload objects easier and quicker. You can continue to use the Get Autoload node but these are just shortcuts that spawn the node with the given autoload preset. (GH-253.
Property nodes correctly resolve the underlying return class type. For example, if you accessed a property on an autoload, you may have noticed that it did not provide the correct context when dragging from the property node's output pin. With this fix, you should be able to access context-specific functions, signals, and properties for that object.
Any existing property nodes will need to be recreated so that the property metadata updates correctly. (GH-266).
Users were unable to place Emit Signal nodes for built-in Godot and user-defined signals on other objects. This has been fixed and you can now spawn Emit Signal nodes for any object, including signals on the current orchestration. (GH-254).
The Print String node UI in non-export builds blocks mouse interactions with widgets behind the UI. This has been changed, and widgets in the top-left corner will correctly receive mouse events even when the Print String UI is visible. (GH-273).
The Make Callable node was not properly constructing the underlying Godot Callable object, preventing users from using the Connect
function. This has been fixed and the Make Callable node is fully functional. (GH-248).
When enabling the highlight_selected_connections
option in the Orchestrator Settings panel, not only were the connected nodes highlighted, but all connection wires remained fully visible. This has been adjusted and the connection wires will now be dimmed along with any non-directly connected nodes. (GH-205).
The actions available in the All Actions dialog are now fully context sensitive when users drag from the instantiate scene output pin. This allows you to access any script exported variables or functions on the instantiated scene's root node. (GH-206).
Fixed several superfluous logged warning messages (GH-230, GH-232).
🔽 Downloads
Download the Orchestrator 2.1.dev1 plug-in.
We also have demos available that can be downloaded based on your platform:
Known issues
With every release, we acknowledge that there will be problems we couldn't resolve in time. Some issues have been identified, fixes are being worked on, while others may remain unknown.
You can check the list of GitHub issues to learn if the problem that you are experiencing has been reported. We appreciate new reports and confirmations of existing issues, as they help us prioritize tasks based on user needs.
What's next?
This release only scratches the surface of what we have planned for Orchestrator 2.1. Future updates will include the following new features and improvements:
- Improved variable subsystem, supporting any Godot object type
- Prefab support using Macro/Function libraries for code reuse across projects.
- Text-based storage formats for improved version control support
- Support for FileAccess and DirAccess singletons
- Method chaining with Call Function nodes
- Godot 4.3 Editor Script Debugger support
- Support for
class_name
, @icon
, and other script annotations
- Improved in-editor documentation integration
- Support for
@onready
variables
- Undo/Redo support
We're also actively backporting many new features from this development build to Orchestrator 2.0, which we plan to release in the coming week for those who prefer to rely on stable builds rather than preview builds.