It’s something that’s pretty nice once you’ve implemented these lifecycles a bunch.
The tree turns out to be a great place to keep things, and you get several levels of control. Here’s how I think about it now.
`_init`: constructor. I usually use this to create dynamic child nodes
`_enter_tree`: now we have a parent; subscribe to signals, copy initial config, etc
`_ready`: I can be sure that all child nodes have called _ready, so anything I depend on there is… er, ready
`_exit_tree`: cleanup, especially anything we did with the parent and other ancestors. usually symmetric to `_enter_tree` if I’m using them
I just did a find all in my biggest recent project, and I never actually use `queue_free` or `free` for explicit memory management. Most of the times when I’ve thought I needed to, I actually was creating a bug
The tree turns out to be a great place to keep things, and you get several levels of control. Here’s how I think about it now.
`_init`: constructor. I usually use this to create dynamic child nodes
`_enter_tree`: now we have a parent; subscribe to signals, copy initial config, etc
`_ready`: I can be sure that all child nodes have called _ready, so anything I depend on there is… er, ready
`_exit_tree`: cleanup, especially anything we did with the parent and other ancestors. usually symmetric to `_enter_tree` if I’m using them
I just did a find all in my biggest recent project, and I never actually use `queue_free` or `free` for explicit memory management. Most of the times when I’ve thought I needed to, I actually was creating a bug