C# export typed enum's are corrupted when in a collection or array form.

[rpcesar]

Version:
v3.2.3.stable.mono.official

OS/Device
Windows 10 PC. High end.

Issue Description:
When exporting a collection of enumerators as a List or Array ([]), the properties inspector gives the ability to add and populate a list of of said enumeration. You can save and load the class, and the properties remain in tact. However if you attempt to access said variable at any point (even in its original property setter) , the results (value) are corrupted. The LENGTH of the collection or array is correct, but the data is not correct. I am seeing this issue with ANY exported collection of enumerations right now. Note that AFAIK enumerations work, in general. Collections work, in general. But collections and enumerations, together, bring back faulty data.

Steps to reproduce:
Create a script that subclasses Node. Create an enum type. Create a property or public exported variable of a collection type or array type on that node. Drag the node into the project. Set up a list of the enumerations. Save it. Write any code at any location that accesses said variable. Observe said variables contents. (or just see image)

Note the image above image is from a right as soon as the remote debugger attached and it was setting the value from the serialized scene.

[rpcesar]

I was able to do a bit more diagnostics on this, and I have a workaround and a hint as to whats happening.

If you export an array, the node inspector will represent it as an intpool.
If you export as a list, the node inspector represent it as an Array. (what looks right)
In both cases you can save and load these lists in the inspector, they serialize fine. they LOOK fine from the editor.
But when the scene consumes the values you have initialized, it does not correctly marshal them to the appropriate exported types. It reeks of an unmanaged cast to a generic collection interface, and my bets (working on testing this) is its really a Godot.Collections.Array being improperly cast through the CLR as a generic List interface.

A workaround for this is to only use the Godot.Collections.Array type for the lists being exported, at least so far as enumerations are concerned.

[NathanaelMangold]

@rpcesar is there a workaround for GDScript as well?

[rpcesar]

@rpcesar is there a workaround for GDScript as well?

I am not aware that this problem applies to GDScript, if it does I have not tested with or for it.

[NathanaelMangold]

Yeah. Enums seem to be pretty buggy in the inspector for C# and GDScript

[NathanaelMangold]

@Calinou This is still not fixed in Godot V3.4.stable for GDScript like mentioned in #52140

[Calinou]

@Calinou This is still not fixed in Godot V3.4.stable for GDScript like mentioned in #52140

This issue will only be fixed in 3.5 as #53942 was merged too late for 3.4 (it was in feature freeze). If you want to make sure of this, try building a Mono-enabled editor from source using the 3.x branch on GitHub.

[raulsntos]

That PR doesn't fix this issue, this issue should be fixed in 3.4 by #53627 which was merged in time, I think #52140 is actually not a duplicate of this one and probably should not have been closed.