Integrate Qodot an engine module (either core or independent)

[fire]

Is there any interest in making Qodot's .map import as a core or independent C++ module for Godot?

The main benefit of using GDscript/GDNative is that it is easily downloadable from the asset library. However, the GDscript and GDNative interfaces are still deficient in Godot 4.0 during the transition period.

One can distribute the entire Godot Engine as a single executable. If Qodot was a C++ module, one could do that too.

I want to do the work but wanted to hear from others.

[fhomolka]

There have been talks of turning it into a GDNative module, some minor mentions in the Discord server.
I'm currently in the process of re-writing it ino C#, because the I work on project uses C#, however, I was looking to port it to GDNative afterwards, simply because a few DLL/so/DynLib files are a lot neater than several gdscript files.

[Shfty]

Separating Qodot's business logic from Godot / GDNative is something I've been looking at, though in Rust rather than C++.

You can find the current state of things here, which is more or less feature complete with a few rough edges:

https://github.com/Shfty/quarchitect - Map building core
https://github.com/Shfty/qodot-next - GDNative interface
https://github.com/Shfty/qodot-next-plugin - Godot plugin files

(Note that these are not drop-in compatible with regular Qodot - lots of things have changed with the resource pipeline.)

In the bigger picture I want to generalize to the point where Qodot-style map building can be easily integrated with any engine, but the current state of things is more 'next gen Qodot' than it is 'turnkey map building solution'.
I've started the process of pulling the pieces out into their own Rust modules (see https://github.com/Shfty/ogre) that can be refactored and made generic / more robust, but progress is slow on account of a few different work-life things at present.