Defaults to "Auto", which detects the casing based on the
preference of the currently selected language (C# for example
prefers PascalCase whereas GDScript prefers snake_case).
- Create CSharpScript for generic C# types.
- `ScriptPathAttributeGenerator` registers the path for the generic type definition.
- `ScriptManagerBridge` lookup uses the generic type definition that was registered by the generator.
- Constructed generic types use a virtual `csharp://` path so they can be registered in the map and loaded as if there was a different file for each constructed type, even though they all share the same real path.
- This allows getting the base type for a C# type that derives from a generic type.
- Shows base scripts in the _Add Node_ and _Create Resource_ dialogs even when they are generic types.
- `get_global_class_name` implementation was moved to C# and now always returns the base type even if the script is not a global class (this behavior matches GDScript).
- Create `CSharpScript::TypeInfo` struct to hold all the type information about the C# type that corresponds to the `CSharpScript`, and use it as the parameter in `UpdateScriptClassInfo` to avoid adding more parameters.
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
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>
- Do not reload scripts from non-collectible assemblies
- Do not load GodotTools as collectible
- Do not attempt to reload the same project assembly forever
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
* Works for binary and text files.
* Makes EditorQuickOpen work with custom resources again.
* Information is cached and easily accessible.
Properly fixes#66179. Supersedes #66215 and supersedes #62417
**WARNING**: This required breaking backwards binary compatibility (.res and .scn files). Files saved after this PR is merged will no longer open in any earlier versions of Godot.
As many open source projects have started doing it, we're removing the
current year from the copyright notice, so that we don't need to bump
it every year.
It seems like only the first year of publication is technically
relevant for copyright notices, and even that seems to be something
that many companies stopped listing altogether (in a version controlled
codebase, the commits are a much better source of date of publication
than a hardcoded copyright statement).
We also now list Godot Engine contributors first as we're collectively
the current maintainers of the project, and we clarify that the
"exclusive" copyright of the co-founders covers the timespan before
opensourcing (their further contributions are included as part of Godot
Engine contributors).
Also fixed "cf." Frenchism - it's meant as "refer to / see".
Non-exhaustive list of case-sensitive renames:
GDExtension -> GDNative
GDNATIVE -> GDEXTENSION
gdextension -> gdnative
ExtensionExtension ->Extension (for where there was GDNativeExtension)
EXTENSION_EXTENSION ->EXTENSION (for where there was GDNATIVE_EXTENSION)
gdnlib -> gdextension
gdn_interface -> gde_interface
gdni -> gde_interface
Android was the last platform to still attempt to disable RTTI (for binary
size), but both the Android editor and now the ICU library used by templates
need RTTI.
There could still be the possibility to support this for non-ICU template
builds (i.e. without the TextServerAdvanced module), but since this isn't one
of the build configurations we test regularly it's pretty risky to keep this
option only for that specific use case. And our code is already littered with
`dynamic_cast`s which weren't guarded with `!defined(NO_SAFE_CAST)`.
Scripts that are instantiated at some point will always be recreated
if they ever become placeholders to prevent non-tool scripts
instantiated manually by users to become placeholders, if they
do become placeholders due to errors that prevent instantiation
(such as a missing parameterless constructor) these scripts
will also be recreated replacing the temporary placeholder.
If a script is marked as a tool but becomes a non-tool script
in a rebuild, the script will become a placeholder and will
no longer be considered applicable to be replaced by an instance
since the user explicitly removed the Tool attribute.
Changed the signal declaration signal to:
```
// The following generates a MySignal event
[Signal] public delegate void MySignalEventHandler(int param);
```
Previously, for each scripts class instance that was created from code
rather than by the engine, we were constructing, configuring and
assigning a new CSharpScript.
This has changed now and we make sure there's only one CSharpScript
associated to each type.
The editor no longer needs to create temporary instances to get the
default values. The initializer values of the exported properties are
still evaluated at runtime. For example, in the following example,
`GetInitialValue()` will be called when first looks for default values:
```
[Export] int MyValue = GetInitialValue();
```
Exporting fields with a non-supported type now results in a compiler
error rather than a runtime error when the script is used.
We're targeting .NET 5 for now to make development easier while
.NET 6 is not yet released.
TEMPORARY REGRESSIONS
---------------------
Assembly unloading is not implemented yet. As such, many Godot
resources are leaked at exit. This will be re-implemented later
together with assembly hot-reloading.
The main focus here was to remove the majority of code that relied on
Mono's embedding APIs, specially the reflection APIs. The embedding
APIs we still use are the bare minimum we need for things to work.
A lot of code was moved to C#. We no longer deal with any managed
objects (`MonoObject*`, and such) in native code, and all marshaling
is done in C#.
The reason for restructuring the code and move away from embedding APIs
is that once we move to .NET Core, we will be limited by the much more
minimal .NET hosting.
PERFORMANCE REGRESSIONS
-----------------------
Some parts of the code were written with little to no concern about
performance. This includes code that calls into script methods and
accesses script fields, properties and events.
The reason for this is that all of that will be moved to source
generators, so any work prior to that would be a waste of time.
DISABLED FEATURES
-----------------
Some code was removed as it no longer makes sense (or won't make sense
in the future).
Other parts were commented out with `#if 0`s and TODO warnings because
it doesn't make much sense to work on them yet as those parts will
change heavily when we switch to .NET Core but also when we start
introducing source generators.
As such, the following features were disabled temporarily:
- Assembly-reloading (will be done with ALCs in .NET Core).
- Properties/fields exports and script method listing (will be
handled by source generators in the future).
- Exception logging in the editor and stack info for errors.
- Exporting games.
- Building of C# projects. We no longer copy the Godot API assemblies
to the project directory, so MSBuild won't be able to find them. The
idea is to turn them into NuGet packages in the future, which could
also be obtained from local NuGet sources during development.
