Open rosshadden opened 4 years ago
None of those are NativeScript bindings, they're engine modules (except Python) that add fully-featured subclasses of ScriptLanguage
/Script
/ScriptInstance
for their language. NativeScript is a different, much more minimalistic, thing. It doesn't allow adding languages to the Attach Script dialog or the internal editor, and strictly requires .gdnlib/.gdns files, because it's designed to never even know about your source files.
There are partial solutions for NativeScript bindings, like editor plugins or build scripts that auto-generate .gdns/.gdnlib files, or import source files as .gdns resources (for C++, Rust, and D).
I'm guessing the binding authors are unlikely to migrate to an engine module or PluginScript - it'd require a lot of rewriting and extra work, and would introduce some disadvantages over NativeScript. Improving NativeScript itself might be a more realistic option. Related issue: godotengine/godot-proposals#119
Interesting, thank you for the detailed explanation.
There are partial solutions for NativeScript bindings, like editor plugins or build scripts that auto-generate .gdns/.gdnlib files, or import source files as .gdns resources (for C++, Rust, and D).
I think that idea :point_up: combined with a godot proposal I opened in 2018 and migrated yesterday to godot-proposals, as well as the proposal you linked would make the Nim+Godot workflow much better.
None of those are NativeScript bindings, they're engine modules (except Python) that add fully-featured subclasses of
ScriptLanguage
/Script
/ScriptInstance
for their language.
Wait, also EcmaScript?
Yes, that one is an engine module and doesn't use GDNative or NativeScript.
Some other gdnative libraries have raised the bar quite a bit in terms of usability / user experience since this project was first created. I will list some examples:
.gdns
files (or embedding in scenes).gdnlib
fileAre we able to add any of these improvements to this project?