Ability to export a variable without showing it in the inspector

[Zylann]

I am making a custom node and an editor plugin to edit it. This involves a few variables in the node that I need to export so the data is saved. But some of them make little sense in the editor, are too hard to be edited this way, or are impossible to be checked for changes (array/dict). So I need to hide them... but if I remove export, the data is lost.

If it doesn't exists already, could we have a way to hide exported variables in the inspector?
Note: the Unity equivalent is [HideInInspector].

[neikeq]

You can override _get_property_list and return your properties specifying only the PROPERTY_USAGE_STORAGE usage (the default one if PROPERTY_USAGE_DEFAULT which is the equivalent to PROPERTY_USAGE_STORAGE | PROPERTY_USAGE_EDITOR).

Example:

func _get_property_list():
    return [
        {
            "name": "Prop1",
            "type": TYPE_STRING,
            "usage": PROPERTY_USAGE_STORAGE
        },
        {
            "name": "Prop2",
            "type": TYPE_VECTOR2,
            "usage": PROPERTY_USAGE_STORAGE
        },
        {
            "name": "Prop3",
            "type": TYPE_INT,
            "usage": PROPERTY_USAGE_STORAGE
        }
    ]

[Zylann]

Thanks for the solution :)
But if I do that, export becomes useless and I have to rewrite all variables that had it inside this method, even if I want to hide only a few. Sounds like a lot to write in a scripting language where a shortcut already exists, isn't it?

Also, how do I specify a Material type?

[neikeq]

AFAIK You don't have to rewrite your variables if the property name is the same as the variable.

About specifying it as a Material type you use hint and string_hint for that.

Example:

var my_material

func _get_property_list():
    return [
        {
            "name": "my_material",
            "type": TYPE_OBJECT,
            "usage": PROPERTY_USAGE_STORAGE,
            # Here we specify it's a resource type
            "hint": PROPERTY_HINT_RESOURCE_TYPE,
            # Now we specify the concrete type (which is "Resource" by default IINW)
            "string_hint": "CanvasItemMaterial"
        }
    ]

[neikeq]

If you want to make this possible with the export keyword, I would rename the issue to something more clear, like requesting the ability to specify the property usage (PROPERTY_USAGE_*) in export.

[timoschwarzer]

I think there should be someting like export silent (int) var whatever = 0

[Zylann]

export hidden (int) var whatever = 0 ?

[bojidar-bg]

@Zylann Why not put them the other way around? hidden export(int) var whatever = 0

Also, here are a few more variations (only some of them involve a new token):

hidden export(int) var whatever = 0 # New token - hidden
export(hidden, int) var whatever = 0
export(storage, int) var whatever = 0
export(PROPERTY_USAGE_STORAGE, int) var whatever = 0 # @neikeq
storage(int) var whatever = 0 # new token - storage
export(int) var _whatever = 0 # notice the underscore -- backward compatible?
property my_material(CanvasItemMaterial, PROPERTY_USAGE_STORAGE) # new token - property

[timoschwarzer]

Yes, hidden or invisible or whatever. Just some keyword before or after export

[henriiquecampos]

I think we need to pass another argument to export the variable. In my case I want to show a variable only if a condition fits, if not, the variable is hidden.

[neikeq]

IINW, @reduz had plans to modify the export keyword to be more similar to PropertyInfo.

[Zylann]

@henriiquecampos In Unity this is done easily due to the inspector being shown through immediate mode GUI (actual code, then). If it were to be possible to hide or show a variable dynamically in Godot, you would either expose it from another panel, or show/hide it dynamically with custom script code (if that's possible). a hidden keyword would then just be a shortcut to say "this one will always be hidden", otherwise no keyword can cover dynamic change.

I'm curious about what @reduz plans are :)

[arypbatista]

It would be really useful to have some way to hide an export variable. When working with script inheritance there are some export variables that make sense on parent scripts but automatically handled by sub-scripts. Both intended to be used by the user.

Another work around is for all parent scripts to be abstract classes and only subclasses to export variables, but well...

[Calinou]

Bugsquad note: This issue still seems to be relevant as of commit d87307d. There is a workaround available, but the proposed hidden keyword hasn't been implemented yet.

[KoBeWi]

Souns like a candidate for annotations (#20318)
@export would have current behavior
@serialize could work like hidden export

[mrzapp]

Is anyone on this feature? If not, I'll try to make time and make a pull request

[timoschwarzer]

@mrzapp Doesn't seem like someone is working on it. But before proceeding, I'd recommend you to talk with the maintainers (@reduz @vnen) about which proposal they'd prefer.

[koodikulma-fi]

Stupid question: Does not set_meta in practice function like a hidden export variable ? 1. The data is serialized and saved along the scene or resource just like an export variable, 2. But unlike export vars, it's hidden from the "editor user" but can still be read with get_meta.

[Zylann]

meta has a different purpose. There is no point relying on it with a script you already know, the point is, you can set/get meta on any object without having to put a script on it, or even know if it has one.

[Flavelius]

This seems to have been reported in 2016 and i want to add that it's still very much wanted. Now that c# is there and _GetPropertyList is bugged for it, the workaround mentioned above can not be applied. Being able to hide but serialize properties is a not so uncommon requirement.

[KoBeWi]

A proposal was created that basically covers this issue: godotengine/godot-proposals#1056
So closing, move the further discussion there.