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

  • Silicon Dryad@eldritch.cafe
    link
    fedilink
    arrow-up
    5
    ·
    10 months ago

    @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.

    • I Cast Fist@programming.dev
      link
      fedilink
      English
      arrow-up
      2
      ·
      10 months ago

      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?

      • Silicon Dryad@eldritch.cafe
        link
        fedilink
        arrow-up
        3
        ·
        10 months ago

        @ICastFist more or less, but you still probably want your Anchor to extend something, be it Object, Node, Node2D, Control, etc.

        If your anchors are going to be part of the scene tree, as in you’re adding them as node children of (an)other node(s), then you will need to at least extend Node. If you want your anchors to have a position, then Node2D (or 3D depending on how you need it to behave). If your anchors are part of your ui, then Control might directly be the best, and so on.

        If your anchors are not going to be part of the tree itself, but just stored and/or passed around by nodes as data, I would encourage you to give this page of the docs a read: https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html

        • Bezier@suppo.fiOP
          link
          fedilink
          arrow-up
          3
          ·
          10 months ago

          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.

          • Silicon Dryad@eldritch.cafe
            link
            fedilink
            arrow-up
            2
            ·
            10 months 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.