The `PROPERTY_USAGE_READ_ONLY` flag only makes the property read-only in the inspector, but the property also has the `PROPERTY_USAGE_NO_EDITOR` flag which means it won't show up in the inspector. So it does nothing, while still making it editable from scripting.
To make it read-only for scripting too, this PR removes the setter from the `PropertyInfo`. And since the `set_capture_included` method is now unused, it was also removed.
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.
C# uses `long`s to access many native values. With `PtrToArg<m_enum>` and
`PtrToArg<bitfield<m_enum>>` this isn't a problem, as C++ code converts
through a `*(int64_t*)` cast in assignment, so all 64-bits are initialized.
However, with `PtrToArg<char32_t>`, value assignment happens through an
`*(int *)` cast, leaving 32 bits uninitialized where `int` is 32 bits. On
platforms where `int` is 16 bits, there are presumably 48 bits uninitialized,
though there are very few platforms where this is still the case.
The easiest way to see the practical effects of this is by looking at
`EventInputKey.Unicode`:
```csharp
public override void _Input(InputEvent @event) {
if (@event is InputEventKey keyEvent) {
if (keyEvent.IsPressed() && !keyEvent.Echo) {
var raw = keyEvent.Unicode;
var value = raw & 0xffffffff;
GD.Print($"Key pressed: raw: {raw}; masked: {(char) value} ({value})");
}
}
}
```
Pressing 'a' emits the following line:
```
Key pressed: raw: -3617008645356650399; masked: a (97)
```
Examining execution flow in gdb shows this conversion going through the
following line:
```
PtrToArg<char32_t>::encode (p_ptr=0x7ffcd5bb4b18, p_val=97 U'a') at ./core/variant/binder_common.h:221
221 *(int *)p_ptr = p_val;
```
Here, `p_val` is still 97, which is the value `InputEventKey.Unicode`
is expected to have. After assignment, `p *(int64_t *)0x7ffcd5bb4b18` displays
`-3617008645356650399`, with only the lower 32 bits being properly assigned,
and is the value we see from C#.
With this patch applied, the above testing `_Input` now prints:
```
Key pressed: raw: 97; masked: a (97)
```
Thank you to blujay1269 for asking about an unexpected value they saw in
`EventInputKey.Unicode`, which prompted this investigation.
