-
-
Notifications
You must be signed in to change notification settings - Fork 21.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gdextension declarative property #68479
Gdextension declarative property #68479
Conversation
For my understanding, was it possible to add/remove/rename properties for extensions at runtime before this PR (i.e. dynamic list)? Also, in light of future extension reloading (#66231), reloading would likely be done on a per-class level, requiring re-registration of the entire class including methods and properties? |
In theory yes given extension's However I'm pretty sure this is not a feature but an implementation detail: having dynamic property is going to make things much more complex (think of the property view in the editor :/), on top of that all Godot internal classes don't have dynamic property and hence nobody is going to think about correctly handling that (e.g. avoiding querying the property list once and keeping it in cache). So I think this API given the wrong kind of assumption and should be corrected ;-)
GDExtension has been developed together with Godot-CPP, in the latter the callback always return the same thing. From what I understand the choice of using callback was just due to how you implement type specialization in C++.
Yes, that seems logical to me given GDExtension registration of methods/properties leads to registration into ClassDB, which will forget everything when the related class is unloaded. |
If I understand correctly what you mean by dynamic properties, doesn't Curve do that? And I'm sure I've been seen other Godot classes where the properties returned by godot/scene/resources/curve.cpp Lines 561 to 587 in 140f039
|
How does Godot even know that the property/method list has changed? For this dynamic-ness to be remotely useful, it needs to call those callbacks prohibitively often -- meaning the extension library code has to do smart caching (aka duplication) or will waste performance just copying the same data over and over. Wouldn't a better design be GDExtension library notifying Godot about a change in properties, for example simply by providing the new properties through a |
You call |
…ype_func in GDExtension This function pointer is needed to stay close to internal Godot's ScriptInstance class. Besides, by removing this function pointer, we had to do property list create/free each time we want to access type which is quadratic complexity :/
… for Godot-CPP in CI
cd19b61
to
7e21128
Compare
Wow thanks for pointing this out @raulsntos ! I didn't know about this So of course this PR is pointless if property can be updated dynamically ! (I'll create a new PR with only the revert of the change on GDNativeExtensionScriptInstanceInfo then) |
According to the PR review meeting, this seems not needed anymore. Closing. |
See godot-rust/gdext#19 (comment)
ping @Bromeon
On top of that, I've reverted the change on
GDNativeExtensionScriptInstanceInfo
I made in #67750, I thought it would be simpler to have a similar interface between GDExtension and GDNativeExtensionScriptInstanceInfo, but after deeper investigation it turns out it is much better to haveGDNativeExtensionScriptInstanceInfo
being just a proxy over Godot's internalScriptInstance