Life cycle of GDExtension nodes in the Editor ?...

Question

Hello ! 😃

I have a question about the life cycle of nodes implemented in GDExtension (C++ in my case), in particular in the editor.

I just finished the tutorial with the GDExtension C++ example :
https://docs.godotengine.org/en/stable/tutorials/scripting/gdextension/gdextension_cpp_example.html#doc-gdextension-cpp-example

Just in case, you can find the C++ node implementation below :

#include "gdexample.h"
#include <godot_cpp/core/class_db.hpp>

using namespace godot;

void GDExample::_bind_methods() {
}

GDExample::GDExample() {
    // Initialize any variables here.
    time_passed = 0.0;
}

GDExample::~GDExample() {
    // Add your cleanup here.
}

void GDExample::_process(double delta) {
    time_passed += delta;

    Vector2 new_position = Vector2(10.0 + (10.0 * sin(time_passed * 2.0)), 10.0 + (10.0 * cos(time_passed * 1.5)));

    set_position(new_position);
}

By the end of the tutorial, I was surprised to see my node floating around without having to run the game, in the editor 2D viewport.

In GDScript, to achieve the same thing, I would need to add the @tool annotation.

Questions :

1. Is it normal and expected, that the _process method of my GDExtension node gets executed in the editor ? (and not only in runtime ?)
2. If it is, can it be the source of unexpected side-effects in the editor ? (e.g. node properties being edited and overridden in the scene)

Have a nice day 🙂

Rosana

Answer 1

I'm working on a C++ gdextension, I'm new to godot. I find that the editor instantiates the nodes that are part of the scene. When I run the game it creates another set of instances, I believe. When stopping the game, the instances are deleted. But not the ones instantiated in the editor. It's easy to see what happens if you put a std::cout in the constructor and destructor of your nodes, as well as in the _process method. I think the editor has to instantiate nodes, otherwise it won't be able to show their properties and allow you to interact with your nodes.

Yes this can have all kinds of side effects, but it all depends on what your nodes do. In my case, my gdextension node creates hundreds of child nodes (that I do not want to show up in the editor), which use external libraries. Originally I had the code to create the child nodes in the constructor of the gdextension node, which means that all those child nodes were created when opening the editor. The child nodes use the external libraries, which contain static variables with static initialisers, which in the end caused segmentation faults. It took quite some time to figure out what happened.

I 'fixed' this by adding a key stroke listener to my gdextension node, such that child nodes are only created after pressing a key, which you can do only when running the game. I'm curious to know if there is a better approach.

Microwave

Answer 2

In fact I just found the answer to my question here: https://mcmap.net/q/6048/godot-in-a-gdextension-module-_ready-is-called-in-the-editor

Microwave

Answer 3

Thanks for the heads-up.

Kommunarsk 's answer on your other post was very insightful, so I'm putting it here again :

Yeah, nodes you write with gdextension are lower level than gdscript and comparable to an engine node. Engine node's run in the editor and their callbacks are called because they are nodes in a scene tree.
You can guard game play behavior like :

if (!Engine::get_singleton()->is_editor_hint()) {
    // Your game play only code.
}

From my understanding, engine nodes also get processed in the editor (and GDExtension are treated like them).
As explained in the Reddit comment below, even Godot's engine nodes have some safe-guards to be processed differently whether in editor or in-game (see Camera2D processing for example) :

Rosana