Added support for generic type exported properties in gdscript

[pouleyKetchoupp]

This change allows scripts to use untyped properties. Their type can be changed in the inspector the same way as for elements in Array or Dictionary.

This implementation uses properties of type TYPE_NIL with the existing usage flag PROPERTY_USAGE_NIL_IS_VARIANT.

Syntax for property list:

{
	"name": "generic_var",
	"type": TYPE_NIL,
	"usage": PROPERTY_USAGE_DEFAULT | PROPERTY_USAGE_NIL_IS_VARIANT,
	"hint": PROPERTY_HINT_NONE,
	"hint_string" : "",
}

Syntax for exported variable:
export(Variant) var generic_export_var

Property in the inspector:

[bojidar-bg]

Why not handle this using PROPERTY_USAGE_NIL_IS_VARIANT?

[pouleyKetchoupp]

Why not handle this using PROPERTY_USAGE_NIL_IS_VARIANT?

I guess I could! Thanks for the feedback.

I'm going to test and see if it causes any problem, since this flag is used for slightly different cases than the ones my changes handle. And if everything works fine, I'll add it to the documentation too.

[pouleyKetchoupp]

Done. I've also updated the PR description.

[aaronfranke]

@pouleyKetchoupp Is this still desired? If so, it needs to be rebased on the latest master branch.

[pouleyKetchoupp]

Rebased on master and fixed. I think this feature is still needed as afaik there's no other way for scripts to use Variant properties.

If needed, I can write a proper proposal for this feature, but given that it's not very complex and doesn't change a lot of code it seems like a faster process can be applied.

Here are some details about the use case:
It's needed for any script system that works with generic types. I'm using it for an action sequence system for cutscenes implemented in gdscript. It supports condition nodes which compare values of any type set in the inspector with a variable from a database and that would be very cumbersome to implement without generic type properties.

[aaronfranke]

@vnen What do you think about this? I know there was a discussion of an any type in GDScript, and I think that feature should be harmonized with this one to use the same words (ex: either the generic type is Variant or here we would have export(any)). EDIT: It's Variant for sure, this isn't changing.

[Xrayez]

@vnen What do you think about this? I know there was a discussion of an any type in GDScript, and I think that feature should be harmonized with this one to use the same words (ex: either the generic type is Variant or here we would have export(any)).

Worth mentioning that I've implement VariantResource class for this purpose in goostengine/goost#30 in 3.2. Treating this as a resource allows property hints and usage to be configured from within the resource as well, and of course allows to store such a thing as a regular resource on disk (also being able to generate resource previews etc.)

I can make a proposal about this upon pre-approval from the core developers. Of course this could be just an alternative to allowing exporting Variant type via script in GDScript 2.0.

[Xrayez]

I also have a dedicated PR to expose PROPERTY_USAGE_NIL_IS_VARIANT to scripting in #43185, which this PR also exposes.

[fire]

Is this pr still valid?

[pouleyKetchoupp]

AFAIK it's still valid, at least to re-use the inspector part of it and possibly for 3.x. I can port it to master if it makes sense to @vnen and doesn't interfere with the plans for gdscript 2.0.

[Pennycook]

Is anybody still working on this?

I'm currently working around the lack of this feature by using _get_property_list and two properties (one denoting the type, another storing the Variant) which feels like a hack.

It's surprising to me that the Inspector provides support for untyped Arrays, allowing selection of the type for every element individually, but does not support the case of a single value.

[aaronfranke]

Closing because this PR has conflicts and the original author is no longer interested in working on it. However, if anyone wants this feature, you are welcome to salvage it and work on it further.

[Pennycook]

Closing because this PR has conflicts and the original author is no longer interested in working on it. However, if anyone wants this feature, you are welcome to salvage it and work on it further.

@aaronfranke, I'm interested in salvaging this. What's the right way to do that? Open a new PR?

[aaronfranke]

@Pennycook Yes, you will need to grab the changes, rebase them, compile, fix the bugs, test, push them to a branch on your fork, and open a PR.