▲ 10 ▼ [Question] [Solved] Persistent variables in tool script (suppo.fi) submitted 2 years ago* (last edited 2 years ago) by Bezier@suppo.fi to c/godot@programming.dev 6 comments fedilink hide all child comments My script sets this value in editor. How can I keep the the changes when saving the scene? class Anchor: var offset: Vector3 var connected: Node3D var end: bool var anchors: Array[Anchor] I found this issue, so I tried fiddling with _get_property_list(), but that didn't work. It also doesn't seem that I can export the var. Thanks
[–] Bezier@suppo.fi [S] 3 points 2 years ago (1 child) Thanks for that link, I now have learned why it didn't originally work (and that other features like reference counting aren't employed by default!). The solution, if anyone needs this in the future: # Separate file extends Resource class_name Anchor @export var offset: Vector3 @export var connected: Node3D @export var end: bool It adds namespace pollution, but I'll deal with it by prefixing it with the original script's class. permalink fedilink source parent hideshow 2 child comments replies: [–] Jayjader@eldritch.cafe 2 points 2 years ago @Bezier yeah it's good to know about the differences between Object and RefCounted when you're making custom data containers. Personally, I've been suffixing my custom/"game object" resources with "-Rs", as in I have PlayerRs, FileRs, DownloadRs, etc. The namespace pollution is definitely part of the trade-off from just preloading wherever you need the class. permalink fedilink source parent
[–] Jayjader@eldritch.cafe 2 points 2 years ago @Bezier yeah it's good to know about the differences between Object and RefCounted when you're making custom data containers. Personally, I've been suffixing my custom/"game object" resources with "-Rs", as in I have PlayerRs, FileRs, DownloadRs, etc. The namespace pollution is definitely part of the trade-off from just preloading wherever you need the class. permalink fedilink source parent