Skip to content
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

Closed
Shadowblitz16 opened this issue Apr 28, 2023 · 17 comments
Closed

Allow us to extend a scene instead of a script #6769

Shadowblitz16 opened this issue Apr 28, 2023 · 17 comments

Comments

@Shadowblitz16
Copy link

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:

  • Can't be edited in external editor
  • Can't be dynamically attached and removed
    Pros:
  • Strong coupling of code with scene
  • Less filesystem bloat
  • Can't be removed so it can be used as a interface
  • It's easier to work with for beginners due to working with less components

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

@Calinou
Copy link
Member

Calinou commented Apr 28, 2023

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.

@Shadowblitz16
Copy link
Author

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

@KoBeWi
Copy link
Member

KoBeWi commented Apr 28, 2023

Build-in scripts can be named, but it only affects how they are displayed in the editor.

Related/duplicate to #1909 and #1935

@dalexeev
Copy link
Member

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.
2. Press the "Instantiate Child Scene" button (link icon) and select the scene file.

In code:

3. PackedScene.instantiate().

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.

Related/duplicate to #1909 and #1935

Exactly. And in my opinion, the solution proposed in #1935 takes into account all these 4 scenarios.

@Shadowblitz16
Copy link
Author

Shadowblitz16 commented Apr 29, 2023

Build-in scripts canbe named, but it only affects how they are displayed in the editor.

Related/duplicate to #1909 and #1935

They can't be inherited though
Also that only links the script to the name not the actual scene itself which means it's a incomplete object

@dalexeev
Copy link
Member

You can use scene inheritance and script inheritance in parallel, but a script cannot be inherited from a scene and vice versa.

@Shadowblitz16
Copy link
Author

Shadowblitz16 commented Apr 29, 2023

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

@dalexeev
Copy link
Member

These are different branches of inheritance. Scene is Node, script is Script, they cannot inherit from each other. We discussed this earlier in your and @willnationsdev proposals.

@Shadowblitz16
Copy link
Author

Shadowblitz16 commented Apr 30, 2023

These are different branches of inheritance. Scene is Node, script is Script, they cannot inherit from each other. We discussed this earlier in your and @willnationsdev proposals.

I'm not stupid. Yes I know that is the current implementation, doesn't mean it is required to stay this way.
I am also not suggesting breaking backwards compatibility.

What I am looking for is..

  • class_name pointing to a scene not a script (as in the scene is the template not the script)
  • having permanent logic attached to the scene it points to (as in can't be removed from inherited scenes)
  • allowing to inherit and extend the logic attached to the scene by inheriting the scene (as in not limited like built in scripts)

like I said this could be done by using signals as the main scene loop and serializing the signals as part of the scene

@Shadowblitz16
Copy link
Author

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

As for this reply I was a bit busy when I typed it.
The problem with using scripts and scenes inheritance in parallel is again the scene without the script is pointness.
Also again that's two different inheritance trees we have to maintain

@Shadowblitz16
Copy link
Author

Shadowblitz16 commented Apr 30, 2023

@KoBeWi @Calinou @dalexeev

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...

  • built in script + inherited scene => node template from scene
  • file script + inherited scene => node template from script

And since built in scripts don't support inheritance currently, it's mostly backwards compatible.
The only thing that would be changed is that built in scripts with class name would no longer just tie the script it would also tie the scene

EDIT: oh nvm I just realized nodes other then the root of the scene can have built in scripts.. :/
I am trying I really desire this feature I just don't know how to go about it

@me2beats
Copy link

me2beats commented May 1, 2023

is need for using 2 files (scene+script) instead of one the only problem you want to solve

@dalexeev
Copy link
Member

dalexeev commented May 1, 2023

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:

base_scene.tscn
base_scene.gd

inherited_scene.tscn
inherited_scene.gd

@Shadowblitz16
Copy link
Author

is need for using 2 files (scene+script) instead of one the only problem you want to solve

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.

@dalexeev
Copy link
Member

dalexeev commented May 3, 2023

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.

@Shadowblitz16
Copy link
Author

I opened this which might partially fix the issue #2307

@Shadowblitz16
Copy link
Author

I'm closing my bad proposals

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants