Add @no_storage property usage annotation

[cgbeutler]

Describe the project you are working on

Editor plugin using custom resources

Describe the problem or limitation you are having in your project

I have several resources that I don't want saved. Currently, I have to overload the _get_property_list function, which is very verbose.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Add an annotation that can give quick access to the "storage" usage flag of a property. This would allow you to create quick editor-only exports that don't get saved and thus don't get loaded when the game loads.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The annotations proposal had mentioned adding @export_group and @export_category (see comment on issue 828). I imagine this annotation would be implemented in a similar way to those. It should be even simpler, since it just sets the PROPERTY_USAGE_STORAGE flag without messing with any other settings. I don't care much what its called. Calling it @no_storage seems simple enough. I could also see calling it @export_no_storage or @export_storage(bool). Having @export_storage(bool) could be useful if other flags maybe stomp the default usage settings (seems like everything pretty much sticks to defaulting to storage, though.)

If this enhancement will not be used often, can it be worked around with a few lines of script?

The usual workaround of _get_property_list would still work.

Is there a reason why this should be core and not an add-on in the asset library?

I assume other addon/plugin writers may use it. This feature may have no demand, which I would understand too. In that case I'd wait for custom annotations.

[KoBeWi]

With the new _validate_property() method (added in 4.2), you can @export a property and then customize its usage flags. While it's longer than a dedicated annotation, it's much less verbose than _get_property_list().

@export var something = 1
func _validate_property(property):
	if property.name == "something":
		property.usage &= ~PROPERTY_USAGE_STORAGE

Is it enough to resolve this proposal?

[cgbeutler]

Is it enough to resolve this proposal?

That still seems more like a workaround.

I have seen a lot of confusion around storage and also think this proposal would help clear up bad practices. For example, Ive seen a lot of folks double-storing data on a parent and child, not understanding that the parent getter is also storing things the moment they exported it. Having a storage flag in the docs would help clarify how some of the underlying data stuff works.

[KoBeWi]

But the description of @export macro already states that it makes data saved to disk. I doubt adding another macro would clarify anything.

[cgbeutler]

But the description of @export macro already states that it makes data saved to disk. I doubt adding another macro would clarify anything.

Oh, sorry, not saying thats the reason to keep it. The reason to have an @no_storage is because it's a basic use case to export something with no storage. The core libraries even do it themselves in a lot of places. It's nice for having editor endpoints that are accessors while the data representation itself is stored separately.