The GDScript version above makes the `number` property read only whenever
`is_number_editable` is false.
```gdscript
func _validate_property(property: Dictionary):
if property.name == "number" and not is_number_editable:
property.usage |= PROPERTY_USAGE_READ_ONLY
```
The C# version is similar, but omits the negation, so the Number property is
made read only whenever `is_number_editable` is true.
This adds the negation to the C# example, making it match the GDScript
example.
The following is the currently generated `EditorImportPlugin.cs`:
```csharp
public virtual Error _Import(string sourceFile, string savePath, Dictionary options, Array<string> platformVariants, Array<string> genFiles)
{
return Error.Ok;
}
```
This fixes the type signature in the documentation's example to match the
actual type signature.
Before, multiple capability events would instantiate the same object
over and over as long as its bit was set. This caused issues with
hotplug and device suspension.
`GDExtension::open_library` has a check in it to see if the library was loaded
from a temp file, and if it was to restore the original name as that is the one
we actually care about. This check is breaking extension reloading on Mac when
the library path is to a framework folder, as the file inside the framework
will not generally be the same name as the folder.
This check also shouldn't be necessary even on Windows, which is the only
platform that uses `generate_temp_files`, since disposal of the created temp
file is handled within `OS_Windows::open_dynamic_library`, and
`GDExtension::open_library` (which is the only function to call
`open_dynamic_library` with a `p_data` argument) only cares about the original
library file path and has to do extra work to remove the name of the temp file.
Instead, I have removed that check and set `OS_Windows::open_dynamic_library`
to return the name of the original file and not the name of the copy.
This fixes GDExtension reloading on macOS. I do not have a Windows machine
available to test that it still works properly on Windows, so someone should
check that before merging this.
In future work we may want to expose an isStylus or similar for
XR Trackers, though that is likely outside the scope of this commit
which is the core extension work.
Vendor Ref: https://logitech.github.io/mxink/OpenXR.html
Fixes#89119
Add dummy LightmapInstance and Lightmap resources for headless rendering
Prevents the RenderingServer from crashing when it accesses
lightmap_instance->base_data