When the script is not marked as `@tool` the static constructor is not
called and thus the variables contain `null` by default. But since some
validated operations requires a valid value, this would cause a crash.
This commit solves this by initializing the static variables with a
default value based on their types in the editor, when they are not
marked as `@tool`, so if some `@tool` script access them, they will have
a valid typed value, avoiding the crash.
It is generally expected that the base class is called before the
inherited clas. This commit implements this behavior for the implicit
ready function (`@onready` annotation) to make it consistent with the
expectations.
The parser and analyzer now track the dependencies of the script and
return the list when the resource loader ask for them.
What is considered a dependency:
- Any `preload()` call.
- The base script this one extends.
- Any identifier, including types, that refers to global scripts.
- Any autoload singleton reference.
This adds back a function available in 3.x: exporting the GDScript
files in a binary form by converting the tokens recognized by the
tokenizer into a data format.
It is enabled by default on export but can be manually disabled. The
format helps with loading times since, the tokens are easily
reconstructed, and with hiding the source code, since recovering it
would require a specialized tool. Code comments are not stored in this
format.
The `--test` command can also include a `--use-binary-tokens` flag
which will run the GDScript tests with the binary format instead of the
regular source code by converting them in-memory before the test runs.
This reverts commit c7f68a27ec.
We still think GDScript files need UIDs to allow safe refactoring,
but we're still debating what form those should take exactly.
So far there seems to be agreement that it shouldn't be done via an
annotation as implemented here, so we're reverting this one for now,
to revisit the feature in a future PR.
Fixes the issue by adding a mechanism by which the functions that were
previously disappearing can be profiled too. This is optional with
an editor setting, since collecting more information naturally slows the engine
further while profiling.
Fixes#23715, #40251, #29049
get_must_clear_dependencies() has a N^3*log(N) time complexity, and this can very quickly slow down the quitting process as more gdscripts are added in a project.
This change improves it to N^2*log(N).
Instead of using all the inverted dependencies, we do the same with all (non-inverted) dependencies, which is N times faster.
Fixes#85435
This patch fixes the user having to navigate away from the selected node which has the derived script attached and back to see the changes of the base script exports reflected in the property editor.
Previously the `p_reversed` parameter didn't influence the order
in a correct way.
Also script overridden _notification functions were not called in
the correct order.
To fix this some `notification` functions had to add a `p_reversed`
parameter.
This made it necessary to adjust cpp-bindings.
Co-authored-by: David Snopek <dsnopek@gmail.com>
* This implementation adds threads on the side of the client (script debugger).
* Some functions of the debugger are optimized.
* The profile is also now thread safe using atomics.
* The editor can switch between multiple threads when debugging.
This PR adds threaded support for the script language debugger. Every thread has its own thread local data and it will connect to the debugger using multiple thread IDs.
This means that, now, the editor can receive multiple threads entering debug mode at the same time.
This applies our existing style guide, and adds a new rule to that style
guide for modular components such as platform ports and modules:
Includes from the platform port or module ("local" includes) should be listed
first in their own block using relative paths, before Godot's "core" includes
which use "absolute" (project folder relative) paths, and finally thirdparty
includes.
Includes in `#ifdef`s come after their relevant section, i.e. the overall
structure is:
- Local includes
* Conditional local includes
- Core includes
* Conditional core includes
- Thirdparty includes
* Conditional thirdparty includes
Which allows editable data associated with a particular class instead of
the instance. Scripts with static variables are kept in memory
indefinitely unless the `@static_unload` annotation is used or the
`static_unload()` method is called on the GDScript.
If the custom function `_static_init()` exists it will be called when
the class is loaded, after the static variables are set.