Tool mode in GDscript
Scripts don't run inside the editor, and only the exported properties can be changed. In some cases, it is desired that they do run inside the editor (as long as they don't execute game code or manually avoid doing so). For this, the tool keyword exists and must be placed at the top of the file:
If a class inherits from Reference, then instances will be freed when no longer in use. No garbage collector exists, reference counting. By default, all classes that don't define inheritance extend Reference. If this is not desired, then a class must inherit Object manually and must call instance.free(). To avoid reference cycles that can't be freed, a weakref function is provided for creating weak references.
It is often desired to send a notification that something happened in an instance. GDScript supports the creation of built-in Godot signals. Declaring a signal in GDScript is easy using the signal keyword.
These signals can be connected in the editor or from code like regular signals. Take the instance of a class where the signal was declared and connect it to the method of another instance:
It is also possible to bind arguments to a signal that lacks them with your custom values:
This is useful when a signal from many objects is connected to a single callback and the sender must be identified:
Finally, emitting a custom signal is done by using the Object.emit_signal method:
Coroutines with yield
GDScript offers support for coroutines via the yield built-in function. Calling yield will immediately return from the current function, with the current frozen state of the same function as the return value. Calling resume on this resulting object will continue execution and return whatever the function returns. Once resumed the state object becomes invalid. Here is an example:
Hello my dear world
It is also possible to pass values between yield() and resume(), for example:
Hello world cheers!
Coroutines & signals
The real strength of using Yield is when combined with signals. Yield can accept two parameters, an object, and a signal. When the signal is received, execution will recommence. Here are some examples:
Coroutines themselves use the completed signal when they transition into an invalid state,
my_func will only continue execution once both the buttons are pressed.
When using nodes, it's common to desire to keep references to parts of the scene in a variable. As views are only warranted to be configured when entering the active scene tree, the sub-nodes can only be obtained when a call to Node._ready() is made.
This can get a little cumbersome, especially when nodes and external references pile up. For this, GDScript has the onready keyword, that defers initialization of a member variable until _ready is called. It can replace the above code with a single line:
The assert keyword can be used to check conditions in debug builds. These assertions are ignored in non-debug builds.