Build simple node scenes in code

[dbnicholson]

The method to instantiate a scene internally in 6d017d0 is clever, but the real classes and internal classes create a circular dependency that cause import errors. Since there are only a couple child nodes that are significantly updated by the exported variables, just create the whole scene in code.

There should be no functional changes besides dropping the internal scenes. The only change is that the simple nodes can only be added as a node type and not by the scene file. I don't think that will be missed.

https://phabricator.endlessm.com/T35494

[manuq]

Tested in 4.3 RC1 and it works as expected. I find it a bit limiting to have these scenes generated programmatically. They are not a sample of adding custom blocks to your own scenes anymore. All because we want them to work with "+ Add Child Node" instead of "🔗 Instantiate Child Scene". Can I be reminded again why we want the former, not the latter?

[manuq]

Works as expected in 4.3 RC1 but in the Debugger dock I see errors like this in both simple_character and simple_scoring:

E 0:00:00:0523   simple_character.gd:58 @ _init(): Parent node is busy setting up children, `add_child()` failed. Consider using `add_child.call_deferred(child)` instead.
  <C++ Error>    Condition "data.blocked > 0" is true.
  <C++ Source>   scene/main/node.cpp:1572 @ add_child()
  <Stack Trace>  simple_character.gd:58 @ _init()
                 block_code.gd:51 @ _update_parent_script()
                 block_code.gd:13 @ _ready()

[dbnicholson]

I think the reason to use a node type and not an instantiated scene is that it's much more friendly to add to a scene. The node insertion dialog shows an icon and an description (although we currently have none). Instantiating a scene only shows the file path. How would you even know what you were looking for if you just installed our plugin?

Thanks for finding that warning. I don't know why I wasn't seeing that. I've once again confused what I can do in _init() vs what I can do in _ready().

[manuq]

I think the reason to use a node type and not an instantiated scene is that it's much more friendly to add to a scene. The node insertion dialog shows an icon and an description (although we currently have none). Instantiating a scene only shows the file path. How would you even know what you were looking for if you just installed our plugin?

👍 thanks for the summary.

[dbnicholson]

I fixed the ready issues, and I also found that the child nodes need to be manually freed or they leak. I think this is working correctly now, but after having gone through this I really see the benefit of scenes. I'm fine if we keep it the way it is.

[dylanmccall]

I think the reason to use a node type and not an instantiated scene is that it's much more friendly to add to a scene. The node insertion dialog shows an icon and an description (although we currently have none). Instantiating a scene only shows the file path. How would you even know what you were looking for if you just installed our plugin?

👍 thanks for the summary.

I'll just add that another reason is it's frustrating for a learner to have to learn (and us to have to communicate) two different ways of adding nodes from the library depending on mysterious voodoo magic. In one of our test calls with the learning team earlier, I'd observed that this was a cause of some unnecessary confusion.

[manuq]

Just gave it a try on top of main branch and it works, merging.