reduz
commented
7 years ago I think this would be better as something specific to gdnative. We could call it "native modules" or something like that.
On Apr 24, 2017 2:27 AM, "Thomas Herzog" notifications@github.com wrote:
Extensions
After talking to @touilleMan https://github.com/touilleMan and @reduz https://github.com/reduz in Paris (it was awesome!!!) I'm writing down this proposal.
GDNative is a nice way to use third party libraries in your game or just optimize performance critical code, but it could also be used to add "extensions" to Godot (for the lack of a better name, "plugin" and "add-on" are already taken 😛 ) Current situation
A GDNativeScript represents one class in a GDNativeLibrary. To have any effect, this script must be attached to any object. This is cool to write game code or wrap third party code in a class.
The current way to "extend" Godot is via plugins (or more precisely, "editor plugins"). These plugins can do a lot of awesome things, but they all only run in the editor. GDNative scripts can be used to make plugins as well, but they can't do anything that will have an impact on the running game. Proposal
[image: extension] https://cloud.githubusercontent.com/assets/5209613/25318699/7d9c0810-2894-11e7-865f-c4ceae5f6c84.png
Have a new project settings tab for "extensions". Extensions are GDNativeLibraries that don't need to expose any classes, they just get run and that's it.
These extensions get loaded at startup, in the editor as well as in a game. Implementation of an extension
A regular GDNativeLibrary, but it contains a special function godot_native_extension_init and godot_native_extension_terminate that get called at startup and shutdown of Godot.
The C API (modules/gdnative/godot.h and modules/gdnative/godot/) will contain new functions, like godot_extensionregister importer(godot_extension_importer importer). The godot_extension_importer type would just be a struct with function pointers. Loading and installing
A new directory called "extensions" containing subfolders for the different extension. In those folders a file "extension.cfg" or something like that. This file specifies the GDNativeLibrary to use to load the extension.
- extensions
- fbx_loader
- extension.cfg
- fbx_library.tres
- python_language
- extension.cfg
- python_library.tres
When the editor or game starts the extensions get loaded.
The Asset Lib could feature a new type of asset: "extension" and install that in the right place. Once installed then the extension would get initialized, editor restart should not be required. (the Asset Lib downloader needs to initialize the initialization process 😄 ) Use cases
- downloadable scripting languages in the AssetLib (with editor support)
- new resource importers
- possibly more that I can't think of right now 😄
WDYT?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/8505, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z23Oo0Lp0h6J8Z_LPd2tooQdF_biSks5ry-xogaJpZM4NFlw4 .
karroffel
akien-mga
Zylann
bojidar-bg
RameshRavone
touilleMan
HummusSamurai
Extensions
After talking to @touilleMan and @reduz in Paris (it was awesome!!!) I'm writing down this proposal.
GDNative is a nice way to use third party libraries in your game or just optimize performance critical code, but it could also be used to add "extensions" to Godot (for the lack of a better name, "plugin" and "add-on" are already taken 😛 )
Current situation
A GDNativeScript represents one class in a GDNativeLibrary. To have any effect, this script must be attached to any object. This is cool to write game code or wrap third party code in a class.
The current way to "extend" Godot is via plugins (or more precisely, "editor plugins"). These plugins can do a lot of awesome things, but they all only run in the editor. GDNative scripts can be used to make plugins as well, but they can't do anything that will have an impact on the running game.
Proposal
Have a new project settings tab for "extensions". Extensions are GDNativeLibraries that don't need to expose any classes, they just get run and that's it.
These extensions get loaded at startup, in the editor as well as in a game.
Implementation of an extension
A regular GDNativeLibrary, but it contains a special function
godot_native_extension_initandgodot_native_extension_terminatethat get called at startup and shutdown of Godot.The C API (modules/gdnative/godot.h and modules/gdnative/godot/) will contain new functions, like `godot_extension_register_importer(godot_extension_importer importer)
. Thegodot_extension_importer` type would just be a struct with function pointers.Loading and installing
A new directory called "extensions" containing subfolders for the different extension. In those folders a file "extension.cfg" or something like that. This file specifies the GDNativeLibrary to use to load the extension.
When the editor or game starts the extensions get loaded.
The Asset Lib could feature a new type of asset: "extension" and install that in the right place. Once installed then the extension would get initialized, editor restart should not be required. (the Asset Lib downloader needs to initialize the initialization process 😄 )
Use cases
WDYT?