Alternative to checking if editor is active directly in the process

[richardbonneau]

Just wondering why you wouldn't use the following to prevent process from running in the editor as every single node would basically be checking on every tick and returning nothing as opposed to disabling the process completely from the get go

GDExample::GDExample() { if (Engine::get_singleton()->is_editor_hint()) { set_process_mode(Node::ProcessMode::PROCESS_MODE_DISABLED); } }

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

void GDExample::_process(double delta) { UtilityFunctions::print("Hello from GDExample::_process", delta); }

[vorlac]

Hah, nice... didn't know that existed. I didn't really use the editor too much and never got to the point where performance was even close to an issue so I didn't worry about this stuff too much. It's nice to see there's a way to disable node processing conditionally though, that would have come in handy when I was more active on this project.

With that being said, i did hear that the 4.3 release included a way to set up nodes in gdextension in a way that just defines them as tools (run in the editor) vs runtime nodes (inactive during editor). I haven't looked into anything about it yet though.

Either way, if you want to submit a PR for your suggestion I can merge it in if it works out well.

[Mangonels]

As orlac said, you don't need to do this kind of trickery anymore since godot 4.3, ClassDB introduced register_runtime_class

The only reason I didn't switch all the class registrations from register_class to register_runtime_class for the 4.3 update is that the project breaks for some reason derived from doing it (also, there's a static class or something in there idk how to convert yet), so I thought I just wouldn't touch it since even though stuff is running in editor, the game itself works fine in both preview and exported runtimes.

Feel free to try for yourselves and PR if you find how to register them properly.