The behavior for Basis and Transform2D is unchanged, and Transform gets new behavior. All of the behavior is identical to GDScript's behavior.
(cherry picked from commit 0a39c7b354)
The code was attempting to dynamic cast the native instance to Reference after
the managed instance was disposed. As the managed instance acts as a Ref,
the native instance was freed during that disposal.
This made the dynamic cast fail and we attempted to memdelete a second time.
The fix is to make the dynamic cast before disposal.
Because of the weird case with multi-threading and ResourceLoader, it can be the case that a resource is GCed while being referenced again in the main thread. In such cases, a new unsafe reference is created before the finalizer thread removes the previous one.
As our script class parser is error prone, we should not impede the build from continuing because of a parsing error.
This should be reverted in the future once we switch to Roslyn.
- `EditorNavigationMeshGenerator` was being registered as part of the Core API,
even after d3f48f88bb. We must make sure to
set Editor as the current ClassDB API type before creating an instance.
- The `VisualScriptEngineSingleton.constant` property has a property hint string
that's different between tools and non-tools builds. This commit makes the
hint string to no longer be set in `_bind_methods`, and to instead set it in
`_validate_property`. This way it's ignored when calculating the API hash.
- `JavaClassWrapper` is now registered in ClassDB on all platforms,
using a dummy implementation on platforms other than Android.
This fixes API portability between Android and other platforms.
- Updated `--class-db-json` command to ignore non-virtual methods that start
with an underscore (see: 4be87c6016).
Added guards to all C# script interface calls to attach the current thread
for the current scope if the thread is not already attached.
This is far from ideal, as attaching the thread is not cheap and all managed
thread local storage is lost when we detach the thread at the end of the calls.
However, it's the best we can do for now to avoid crashing
when an unattached thread tries to interact with C# code.
Commit 4d727f1ee6 made it possible for vararg
methods to return void. This broke the C# bindings generator which was
assuming in one place that vararg methods always return Variant.
Up until now, 'GD.Print' would convert parameters first to
Variant and only then to String. This meant parameters that cannot be
converted to Variant would be printed as "Null".
This commit makes 'GD.Print' fallback to 'System.Object.ToString()'
if the parameter could not be converted to Variant.
The same applies to all 'GD.Print' variants:
'GD.PrintS', 'GD.PrintT', 'GD.PrintErr' and 'GD.PrintRaw'.
Happy new year to the wonderful Godot community!
We're starting a new decade with a well-established, non-profit, free
and open source game engine, and tons of further improvements in the
pipeline from hundreds of contributors.
Godot will keep getting better, and we're looking forward to all the
games that the community will keep developing and releasing with it.
Previously we had a placeholder solution called 'Managed' to benefit from
tooling while editing the a part of the C# API.
Later the bindings generator would create the final 'GodotSharp' solution
including these C# files as well as the auto-generated C# API.
Now we replaced the 'Managed' solution with the final 'GodotSharp' solution
which is no longer auto-generated, and the bindings generator only takes
care of the auto-generated C# API.
This has the following benefits:
- It's less confusing as there will no longer be two versions of the same file
(the original and a generated copy of it). Now there's only one.
- We no longer need placeholder for auto-generated API classes, like Node or
Resource. We used them for benefiting from tooling. Now we can just use the
auto-generated API itself.
- Simplifies the build system and bindings generator. Removed lot of code
that is not needed anymore.
Also added a post-build target to the GodotTools project to copy the output to
the data dir. This makes it easy to iterate when doing changes to GodotTools,
as SCons doesn't have to be executed anymore just to copy these new files.
MSBuild on Windows uses the system .NET Framework BCL instead of Mono's. Because
of this, it may not be able to find the Mono.Posix assembly, so it's better
not to depend on it. We needed Mono.Posix to call Syscall.access, so we can
replace this with an internal call that does the same in C++.
Up until now debug builds would always wait up to 500 ms during initialization
to give time for debuggers to attach to the game.
We no longer want this as it increases startup time unnecesarily.
The way forward is to setup the debugger agent as client instead of server.
This way it's the game that connect to the debugger, not the other way around.
If server mode is still desired, suspend=y can be used to indefinitely wait
for the debugger to attach. This all can be specified with the environment
variable 'GODOT_MONO_DEBUGGER_AGENT' when launching the game.
