-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GDScript: Add @export_storage
annotation
#82122
GDScript: Add @export_storage
annotation
#82122
Conversation
I think export_storage is the best option as it says what the annotation does do, not what it doesn't do. But this invites back the debate about the name and function of export annotations, kinda. Well, maybe this can give us closure. |
Using something like "no editor" like the flag could be the most uniform, but I think that hidden risks being confusing Edit: as in, either first option with |
Perhaps a new annotation would be more clear? For example: @serialize var data: MyData # == PROPERTY_USAGE_STORAGE |
I would prefer that the annotation name start with |
The intent for this functionality is often to save some data with the scene/resource file without exposing it to the inspector. So I think |
Yes, this looks like a good option to me. But the question is what default flags we can add in the future, and whether we will later regret not choosing |
I think |
bdcb7dc
to
6d35dee
Compare
@export_hidden
annotation@export_storage
annotation
6d35dee
to
8ceeb1a
Compare
modules/gdscript/tests/scripts/parser/features/export_variable.gd
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from a few comments, I'm approving the design of this (and implementation seems fine as well).
8ceeb1a
to
c6464d3
Compare
Since #82843 now disallows using @ export to hold node reference in resource, will this be a viable option? Will this bypass the error? |
This doesn't change the underlying issue of the access of So I'd say this PR doesn't change that PR at all |
So this annotation will still forbid users from having duplicatable node variable in resource? The warning is there because of exported variable having node path, not reference. I was hoping using this annotation wouldn't trigger that warning. Since there's no way users can assign node path in the resource anyway. |
It's not possible to store a |
e60668b
to
e63dacf
Compare
e63dacf
to
138a58f
Compare
This needs a rebase (and a review from the @godotengine/gdscript team). |
138a58f
to
3a3a201
Compare
As shared by @dalexeev during the GDScript meeting, this PR seems to overlap with #72912. Maybe we should only expose We all agree that we should not have features that overlap too much. |
Note that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thanks! |
I'm not sure about the name:
@export_hidden
,@export_storage
or@export_no_editor
.Also
PROPERTY_USAGE_NO_EDITOR
is currently the same asPROPERTY_USAGE_STORAGE
, but in the future we may add other default flags (PROPERTY_USAGE_NO_EDITOR
isPROPERTY_USAGE_DEFAULT
withoutPROPERTY_USAGE_EDITOR
).vs