It's been just over a month since the launch of Orchestrator 2, the ultimate visual scripting plug-in for Godot 4.2+. We're happy to report that we have a new stable build of Orchestrator that provides not only a substantial number of bug fixes but also incorporates usability improvements and non-compatibility, breaking new features.
Please read on to learn about the new features in Orchestrator 2.0.1.stable, or jump to Downloads to download the plug-in from GitHub directly. The plug-in has also been updated on the Godot Asset Library and should be available soon.
Highlights
This release includes 42 contributions, which is pretty significant for a maintenance release. You can review all the changes on the releases page.
We've included a short overview of the most relevant changes.
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.0.1, you can 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 and welcome any community feedback!
Improved default value resolution on functions
In Godot, it's common practice for some arguments to be defined with default values, which avoids setting a value when calling that function. Unfortunately, the default values resolution was incorrect in 2.0.stable, which could lead to some corner cases where a function's behavior may have been unexpected.
For existing Orchestrations, you can correct this by removing and re-adding the node to the graph. This will refresh the node's method metadata so the function arguments are populated with the correct default values.
Create / Destroy any Godot object
When Orchestrator 2 was first released, you could not 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. The wait is over with adding two new nodes called New Object and Free Object.
The New Object 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 massive improvement because it opens doors previously closed to Orchestrator, such as creating threads, accessing network peer objects, dynamically adding objects to your scene, and more.
The Free Object node is a simplified variant of free() designed to accept any 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; if the object is a pointer, it will be deleted. It simplifies knowing whether to use free() vs queue_free() from the GDScript world.
We want to know what doors this opens, so all feedback is most welcome!
Access to many Godot static functions
In Godot, numerous static function calls exist in classes like FileAccess and DirAccess to create instances of these types.
The long wait is over, and you can now access these and other classes that expose static functions to work with files, directories, and more.
These new options are available in the All Actions dialog window.
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:
Method chaining
In some programming languages, method chaining can help significantly reduce verbosity and improve the readability of what you may be trying to accomplish in fewer lines of code. This also applies to visual scripting tools.
In Orchestrator 2.0.1.stable, if a function accepts a Target argument where you provide the object that the function call is to be made on, these nodes can be toggled into chain mode, where an output pin will be included on the node passing the input Target value as an output.
The chain property can be toggled via the Inspector view.
Recently opened orchestrations
We've added the ability to track the recently opened orchestrations on the Orchestrator File menu.
The last 10 opened orchestrations will be tracked there.
Note: This history is lost if you remove the .godot folder.
Support variable function arguments
Several built-in Godot functions support variable arguments, meaning you can add additional arguments to the function call. Some examples include:
These functions now correctly render the [+] button to add additional arguments to the function call.
If you have placed nodes that should render with the [+] button and do not, select the "Refresh" context-menu option on the node in the graph to reconstruct the node's metadata.
Improved call function return value resolution
There were some use cases where a function call that should return a value always returned null.
In other situations, functions that defined a return value did not show an output pin for the output value.
We have unified this logic and fixed these bugs so that if a function has a Variant return, the pin is shown, and the output value is populated.
All actions dialog usability improvements
One of the first changes to the All Actions dialog was to make it slightly easier to find specific items that may be of interest or accessible from a node with a name that isn't obvious. Specific constant names and user-defined autoload are now searchable from the All Actions dialog search.
Additionally, through feedback, we identified that the virtual functions _set and _get were often confused with their respective non-virtual counterparts, making it unclear which to use.
We've permanently hidden the _set and _get virtual functions.
Init events are now processed
It was identified that the runtime was not calling Init Event functions, preventing the code in those events from executing when the Orchestration started. This has been fixed, and Init Event functions are now executed again upon creating the Orchestration.
Better Filesystem dock integration
In the Godot editor, users can perform several file actions in the FilesystemDock, such as renaming files, moving them between folders, creating or renaming folders, and removing files. Orchestrator was not correctly reacting to these events, which could lead to situations where you needed to close all open files or restart the editor.
This is now fixed, and file renames, deletions, or the moving of files between folders is now supported.
What's next?
We are halfway through the Orchestrator 2.1 features, including testing and preparing the Orchestrator for Godot 4.3, which will be released in late May or early June. We are planning a 2.1.dev2 in the next couple of weeks, which will most likely be based on the Godot 4.3 dev/release candidate snapshots, so stay tuned.