-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
Allow us to extend a scene instead of a script #6769
Comments
Inherited scenes are probably what you want. It's pretty much extending a scene with additional nodes not present in the base scene after all. |
yes but I want to apply logic to them and call them by name |
Since this topic is raised again, I will briefly explain the essence of the problem. When you have a scene that has a script with a global class attached to its root, you have 4 ways to create this entity. In editor: 1. Press the "Add Child Node" button (plus icon) and select your class in the dialog. In code: 3. load("res://my_scene.tscn").instantiate() 4. Use the class constructor. MyScene.new() The problem is that in cases 1 and 4 this will only create the root node, not the entire scene. Case 1 is more of a matter of discipline, although it can lead to accidental errors and be inconvenient for large teams (if someone is not very familiar with Godot). Case 4 can be worked around with a static method (see #1935 for an example). The inconvenience in a small boilerplate and in the fact that you have to remember for which classes you should call the constructor, and for which static method. Exactly. And in my opinion, the solution proposed in #1935 takes into account all these 4 scenarios. |
You can use scene inheritance and script inheritance in parallel, but a script cannot be inherited from a scene and vice versa. |
exactly. and I am suggesting that scenes can be serialized into new node types with logic and inheritance people usually don't create scenes without a script being attached so why not make the scene hold onto logic like how gamemaker objects? it's basically just serializing the scene logic loop into it's own signals |
These are different branches of inheritance. Scene is |
I'm not stupid. Yes I know that is the current implementation, doesn't mean it is required to stay this way. What I am looking for is..
like I said this could be done by using signals as the main scene loop and serializing the signals as part of the scene |
As for this reply I was a bit busy when I typed it. |
As I experimenting more with this I realize it might just be possible to do with built in scripts if they were made to be able to inherit from other built in scripts. Right now it looks like built in scripts need a file path to inherit from something. If builtin scripts registered scene templates with class_name instead of just the script it would work great and solve most of my problems. Basically...
And since built in scripts don't support inheritance currently, it's mostly backwards compatible. EDIT: oh nvm I just realized nodes other then the root of the scene can have built in scripts.. :/ |
is need for using 2 files (scene+script) instead of one the only problem you want to solve |
A scene cannot inherit a script, but can only have it attached to the root node. The same goes for the opposite case, even more so: if in theory we can make GDScript work the way you want it to, then for most other languages we can't do it in principle, it's too crude an injection into the type system. You can use scene inheritance in parallel with class inheritance:
|
yes but I also want to register my scene under a global name instead of just the script. It doesn't have to be class_name that does it, I am just looking for some way to export my scene as a template that I can then create through the new node dialog. |
For scenes currently you must use the "Instantiate Child Scene" button, not "Add Child Node". If we implement #1935, then all 4 ways will give the same result. I will try to implement it soon. |
I opened this which might partially fix the issue #2307 |
I'm closing my bad proposals |
Describe the project you are working on
A spaceship game
Describe the problem or limitation you are having in your project
I am trying to extend a scene with additional logic and global type name.
I tried using build in scripts but they aren't tied to the scene and have limitations like not being able to be inherited or named
Normal scripts create a bunch of file system bloat and both normal script and built scripts can be removed making the extended scene logic not tied with the type of scene it is.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
My proposal would allow users to create a scene and then register it as a class_name through the editor,
Then programmers could add embedded code that would be part of the scene root instead of a script that clutters the filesystem or could be removed or added to something that it doesn't work on
This also means when you extend a scene you are actually extending a completed object instead of just logic that may or may not work.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
There would be a extend option under the root of the scene which opens up a script editor.
Not to be confused with extend script.
Extended scene code would take priority over scripts.
Native Type -> Scene Type -> Script Type
If this enhancement will not be used often, can it be worked around with a few lines of script?
I would probably be used more often then scripts to tell you the truth
Cons:
Pros:
Is there a reason why this should be core and not an add-on in the asset library?
It would be a alternative way to use godot and would be easier to work with
Also people are already looking for a way to tie scenes and scripts together this might be one of the ways to do it
The text was updated successfully, but these errors were encountered: