Mono's MSBuild and System/VisualStudio's MSBuild expect a different format for surrounding property values with quotes on the command line.
xbuild does not seem to support semicolons in property values from the command line: https://xamarin.github.io/bugzilla-archives/16/16465/bug.html
It's a good time to just remove xbuild support entirely.
Previously, when running the project manager, we would try to load the API assemblies from the project and fail because we were not editing any project. This would make us try to copy the prebuilt API assemblies to the project. Since there is no project, it would try to copy them to the executable location. This would fail if Godot doesn't have permissions to write to that location.
This commit fixes that by instead trying to load the prebuilt API assemblies in the first place, if running the project manager.
This was a regression in 3.1 and later from the new inspector, where
PROPERTY_HINT_SPRITE_FRAME was not fully re-implemented. It's meant to
be a normal PROPERTY_HINT_RANGE which also automatically increments its
value when keyed in the animation player.
To avoid code duplication, I made the frames properties use the actual
PROPERTY_HINT_RANGE and introduced a PROPERTY_USAGE_KEYING_INCREMENTS
usage flag instead.
By default, an unhandled exception will cause the application to be terminated; but the project setting `mono/unhandled_exception_policy` was added to change this behaviour.
The editor is hard-coded to never terminate because of unhandled exceptions, as that would make writing editor plugins a painful task, and we cannot kill the editor because of a mistake in a thirdparty plugin.
Also allow lifting the decimal step formatting with a hint range step
of 0. A new `range_step_decimals()` is added for this to avoid breaking
compatibility on the general purpose `step_decimals()` (which still
returns 0 for an input step of 0).
Supersedes #25470.
Partial fix for #18251.
**Important:** This does not mean *yet* that C++11 features should be used
in contributions to Godot's codebase.
For now this change is done solely for feature branches working on Vulkan
support and GDScript typed instruction sets for Godot 4.0, which will both
use C++11 features and are based on the master branch.
The plan is to start porting the codebase to C++11 after Godot 3.2 is
released, following upcoming guidelines on the subset of new features that
should be used, and when/how to use them.
We will advertise clearly when C++11 contributions are open, especially
once we start a coordinated effort to port Godot's massive codebase. In the
meantime, please bear with us and good ol' C++03. :)
Also added support for SCons project-absolute paths (starting with #) and
warning about duplicates in add_source_files(), and fixed
default_controller_mappings.gen.cpp being included twice after first build
due to *.cpp globbing.
Part of #30270.
If both the core and editor API assemblies are missing or out of sync, Godot will only update the former and then abort when trying to load them again because the latter was not updated. Godot will update it correctly the next time it's started, but this should not be needed and it should work the first time. This commit fixes that.
Properly release added resource loader and save references. Otherwise PluginScript API
may cause "ObjectDB Instances still exist!" warnings and segmentation faults on exit.
"posmod" is the integer version of "fposmod". We do not need a "mod" because of the % operator.
I changed the default arg names from "x" and "y" to "a" and "b" because they are not coordinates. I also changed pow's arg names to "base" and "exp". Also, I reorganized the code in the VS built-in funcs switch statement.
Color table should exist for images with bit count <= 8. Importing 16-bit
BMP images could also likely have a color table but they're not currently
supported in Godot.
Remove the old API assembly invalidation system. It's pretty simple since now the editor has a hard dependency on the API assemblies and SCons takes care of prebuilding them.
If we fail to load a project's API assembly because it was either missing or outdated, we just copy the prebuilt assemblies to the project and try again. We also do this when creating the solution and before building, just in case the user removed them from the disk after they were loaded.
This way the API assemblies will be always loaded successfully. If they are not, it's a bug.
Also fixed:
- EditorDef was behaving like GlobalDef in GodotTools.
- NullReferenceException because we can't serialize System.WeakReference yet. Use Godot.WeakRef in the mean time.
