- Now there is only one solution that contains both GodotSharp and GodotSharpEditor project. Previously we had one solution for each project
- GodotSharpEditor reference GodotShatp with a 'ProjectReference'. Previously it was a 'Reference' to the assembly
- This also simplifies the command line option to generate this solution: 'godot --generate-cs-api <OutputDir>'
- `modules\mono\csharp_script.cpp(576): warning C4099: 'CSharpScriptDepSort': type name first seen using 'class' now seen using 'struct'`
- `modules\mono\signal_awaiter_utils.cpp(144): warning C4003: not enough actual parameters for macro 'ERR_FAIL_V'`
- `modules\mono\editor\net_solution.cpp(101): warning C4129: '%': unrecognized character escape sequence`
- (several) `modules\mono\glue\cs_compressed.gen.h(222): warning C4129: 'E': unrecognized character escape sequence`
- If there is a solution and C# project at startup, make sure API assemblies are up to date.
- Fix prebuilt assemblies only being used when building the game project, and not in other instances.
- Bundle editor dependencies:
- 'GodotSharp': Root data directory for the editor
- 'Tools': Editor dependencies. Only GodotSharp.dll for now.
- 'Api': Prebuilt GodotSharp and GodotSharpEditor API assemblies.
- 'Mono': Mono files to bundle with the editor.
- 'bin': (Optional, not used for now) Mono bin directory.
- 'etc': Mono configuration files.
- 'lib': Mono dependency shared libraries.
- 'lib/mono/4.5': Framework assemblies.
- Added build option to copy the required files from the mono installation to 'GodotSharp/Mono'. Enable with 'copy_mono_root=yes'. Disabled by default.
- Export template dependencies:
- 'data_AppName'/'data_Godot':
- 'Mono': Mono files to bundle with the game.
- 'etc': Mono configuration files.
- 'lib': Mono dependency shared libraries.
- The data directory is generated when compiling and must be bundled with the export templates. In the case of OSX, the data directory must be placed inside the 'osx.zip' export template.
- In OSX, alternative location for directories (needed for app bundles) are:
- 'data_AppName/Mono/etc' --> '../Resources/GodotSharp/Mono/etc'
- 'data_AppName/Mono/lib' --> '../Frameworks/GodotSharp/Mono/lib'
- The editor can bundle prebuilt API assemblies.
- Generate them with a tools build by running: `--generate-cs-core-api <GodotSharp_OutputDir> --generate-cs-editor-api <GodotSharpEditor_OutputDir> <GodotSharp_OutputDir>/bin/Release/GodotSharp.dll` (This command will be simplified in the future and both projects will be in the same solution)
- Build the solutions and copy the output files to '#bin/GodotSharp/Api'.
- Fixed API assembly being added twice during the export process.
- thread_local.h: 'delegating constructors only available with -std=c++11 or -std=gnu++11'
- mono_reg_utils.cpp: 'extra tokens at end of #endif directive'
- mono_bottom_panel.cpp: '<fieldB> will be initialized after <fieldA> when initialized here'
- bindings_generator.cpp: 'name lookup of 'i' changed (...) matches this 'i' under ISO standard rules (...) matches this 'i' under old rules (...)'
This enhancement is specially noticeable in OSX, since it includes Mono's install location (both official and homebrew). This makes it possible to build Godot with Mono on OSX without pkg-config (pkg-config is bundled with Mono, but it's not added to PATH, so finding it would require finding the Mono root directory first).
This allows more consistency in the manner we include core headers,
where previously there would be a mix of absolute, relative and
include path-dependent includes.
When a Reference managed instance is garbage collected and its finalizer is called, it could happen that the native instance is referenced once again before the finalizer can unreference and memdelete it. The workaround is to create a new managed instance when this happens (at least for now).
- We no longer generate RID and NodePath C# classes. Both will be maintained manually.
- We no longer generate C# declarations and runtime registration of internal calls for the following classes: RID, NodePath, String, GD, SignalAwaiter and Godot.Object (partial base).
- We no longer auto-generate the base members of Godot.Object. They will be maintained manually as a partial class.
This makes it easier to maintain these C# classes and their internal calls, as well as the bindings generator which no longer generates C# classes that don't derive from Godot Object, and it no longer generates the Godot.Object base members (which where unreadable in the bindings generator code).
- Added missing 'RID(Object from)' constructor to the RID C# class.
- Replaced MONO_GLUE_DISABLED constant macro with MONO_GLUE_ENABLED.
- Add sources in module/mono/glue even if glue is disabled, but surround glue files with ifdef MONO_GLUE_ENABLED.
First of all, this fixes the handling of exceptions so the engine actually notices them,
it was broken in 4172fa03b5.
Next, unhandled exceptions now do NOT cause an abort(). They're logged now,
so before #16987. The pending exception thing still works though.
This average is not a proper approximation of a grayscale value,
get_v() is better suited for that.
If we want a real to_grayscale() conversion, it's somewhat more
involved: https://en.wikipedia.org/wiki/Grayscale
Remove the deprecated Gray() from C# bindings as it conflicts
with new named color constants.
- Count and panel per script.
- Ability to disable warnings per script using special comments.
- Ability to disable warnings globally using Project Settings.
- Option to treat enabled warnings as errors.
Ignacio Etcheverry
Ignacio Etcheverry
Ryan Schmitt
Ben Rog-Wilhelm
Michael Alexsander Silva Dias
Rémi Verschelde
Mads Ynddal
Kelly Thomas
Aaron Franke
zochris
Sophie Tauchert
Fabio Alessandrelli
luz.paz
exts
Juan Linietsky
Pieter-Jan Briers
Justin Abene
Teashrock
George Marques