this post was submitted on 01 Oct 2023
10 points (100.0% liked)

Godot

5697 readers
45 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

!roguelikedev@programming.dev

Credits

founded 1 year ago
MODERATORS
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] ICastFist@programming.dev 2 points 1 year ago* (last edited 1 year ago) (6 children)

Tried your code on a ready entity of my project, and indeed, @var anchors: Array[Anchor] can't be exported if it's in the same script.

What you could do, however, is initialize anchors as an empty array, @export var anchors = [] - This solves half of the problem, as you still won't be able to add Anchor objects within the editor, because they "don't exist".

The likely solution in this case is making that Anchor class a standalone .gd file and add it to the Autoload list (Project Menu -> Project Settings -> Autoload tab). With this done, your original @export var anchors: Array[Anchor] will now work, because now that Godot autoloads it (makes it globally accessible), it "exists"

EDIT - Here's the doc on _get_property_list https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-get-property-list - From the example there, it added new things that don't "exist" that should now show up on the editor. The thing is, it doesn't specify if a locally created class would also work there.

#Might still be worth a shot, eh?

func _get_property_list():
var properties = []
    properties.append({
        "anchor_offset": Anchor.offset,
        "anchor_connected": Anchor.connected,
        "anchor_end": Anchor.end
    })
return properties
[–] Jayjader@eldritch.cafe 5 points 1 year ago (5 children)

@ICastFist @Bezier I agree with your overall explanation, but I would instead recommend using the class\_name directive instead of adding it as an auto-load.

Auto-load will make it that a single Anchor instance always exists in the root scene, and that Anchor elsewhere in your code will always reference that single(ton) instance.

If you want Anchor to behave like other built-in classes in your scripts and the editor, you need to give it a class\_name and *not* use the same name ("Anchor") for an auto-load.

[–] ICastFist@programming.dev 2 points 1 year ago (4 children)

Had to look up how to do that, as apparently the docs don't have that kind of information. I did come across this SO question. So, the solution would be:

#anchor.gd
class_name Anchor

var offset: Vector3
var connected: Node3D
var end: bool

And that would create this new, readily accessible class throughout the project, correct?

[–] Jayjader@eldritch.cafe 3 points 1 year ago

@ICastFist also yes, the docs aren't that great at providing info on this in the reference.

There *is* a good page in the manual, however: https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html

OP @Bezier you probably want to check this out if you haven't found it already by now, specifically the "Custom variable types" section.

load more comments (3 replies)
load more comments (3 replies)
load more comments (3 replies)