Extra constructor call when using inheritance in Godot

Question

I'm trying to design a character system for my game. Considering I'll need a player and non-player characters - and non-player characters will further come in many more forms, making use of inheritance sounds almost necessary.

Right now, I'm trying to make every instance hold a dictionary of context options and I need the dictionary to be modified with every level of inheritance. From the documentation I learned that the constructor implicitly calls the parent constructor, and so does the _ready() function as noted here.

... but first I wanted to test it, so I set up following scenes (slightly simplified):

New scene: Character

• Character (Type: Character - here I'm not sure why, should be just KinematicBody)

... with the attached script:

extends KinematicBody

class_name Character

func _init():
    print_debug(self.to_string(), " Character _init()")

func _ready():
    print_debug(self.to_string(), " Character _ready()")

New inherited scene: Player

• Player (Inherits: Character.tscn, Type: KinematicBody)

... and detatched the Character.gd script and attached a new script:

extends Character

class_name Player

func _init():
    print_debug(self.to_string(), " Player _init()")

func _ready():
    print_debug(self.to_string(), " Player _ready()")

... and I instantiate one Player scene as a child scene in my main scene (through editor, not code).

---

For some reason, whenever I instantiate Player, Godot consistently prints this:

[KinematicBody:1422] Character _init()
   At: res://scenes/characters/Character.gd:22:_init()
[KinematicBody:1422] Character _init()
   At: res://scenes/characters/Character.gd:22:_init()
[KinematicBody:1422] Player _init()
   At: res://scenes/characters/player/Player.gd:26:_init()
[KinematicBody:1422] Character _ready()
   At: res://scenes/characters/Character.gd:30:_ready()
[KinematicBody:1422] Player _ready()
   At: res://scenes/characters/player/Player.gd:34:_ready()

However, when I instantiate only Character in its place, the output is as I'd expect:

[KinematicBody:1425] Character _init()
   At: res://scenes/characters/Character.gd:22:_init()
[KinematicBody:1425] Character _ready()
   At: res://scenes/characters/Character.gd:30:_ready()

Where is the extra _init() call coming from? Sounds like something that could make a lot of mess if I didn't notice this and blindly used it.

Also why does Player show as a Type: KinematicBody when hovering over it in the scene inspector and not like Type: Player, the same way Character shows as Type: Character - or why don't they both show up as Type: KinematicBody?

Edit

Following @Vaillancourt's suggestion, I placed breakpoints at each of the print_debug() calls. Stepping through the code, the last 4 prints behave as expected - first there's the Character constructor, implicitly called from the Player constructor, then the body of the Player constructor itself. This is clear from the backtrace. Same for the _ready() calls. But before this, there's always one extra Character constructor call not called from the Player constructor.

Same goes when I put multiple Player instances into the scene. Both had the correct constructor calls preceded by one extra, separate call.

Putting a Character instance along with a Player instance to the scene resulted in a - once again - malfunctioning Player (three _init() and two _ready() calls) and a correctly functioning Character (just one _init() and one _ready() call).

Answer 1

Updated version of the initialization process (old version):

Node instancing

1. If the Node is an scene instance, do Scene instancing for the corresponding scene, and take the root node. Otherwise, create a new Node instance.

2. Script Change. If the Node script is different to the one we want (either it didn't have because we just created a new node, or it has a different one set by scene instancing):

   1. Change the Script.

   2. If the script has new variables, allocate them. Initialize variables which are not onready to their default value if specified, zeroed otherwise.

   3. Send script_changed signal.

   4. Call _init on it. Base class _init runs first.

3. Set properties (initialize export variables, and any custom setters run if the value is not the default, even if the value is the same it has). I think should consider "Script change" a property that is being set, but it is such an special case.

Scene instancing

1. Do Note instancing for the notes, from the root to the leafs.

2. Connect IDE signals. Including connections from and to future children.

3. Parenting. From root to the leafs:

   1. Add the node to its parent.

   2. NOTIFICATION_PARENTED (18).

4. NOTIFICATION_INSTANCED (20). On the root node.

5. Current scene handing. If instancing the current scene:

   1. Add the root node as child to the root Viewport.

   2. NOTIFICATION_PARENTED (18). On the root node.

   3. Entering the scene tree. From root to leafs:

      1. NOTIFICATION_ENTER_TREE (10).

      2. Call _enter_tree on it. Base class _enter_tree runs first.

      3. Send tree_entered signal.

   4. Ready mechanism. From leafs to root:

      1. NOTIFICATION_POST_ENTER_TREE (27).

      2. Initialize any onready variables.

      3. Call _ready on it. Base class _ready runs first.

      4. NOTIFICATION_READY (13).

      5. Send ready signal.

---

You have a stored scene Character.tscn where you have a KinematicBody that has a script Character.gd.

And then, in another scene, you have an instance of that scene. And to that instance you set a script Player.gd.

So, when that scene instantiates, it loads and instances the other scene (Character.tscn), which has Character.gd. Then Godot runs _init() on it:

[KinematicBody:1422] Character _init()
   At: res://scenes/characters/Character.gd:22:_init()

Then Godot sets the new script (Player.gd). And Godot runs _init() on it, which has to run _init() on the parent class first:

[KinematicBody:1422] Character _init()
   At: res://scenes/characters/Character.gd:22:_init()
[KinematicBody:1422] Player _init()
   At: res://scenes/characters/player/Player.gd:26:_init()

And then Godot moves on to running _ready. Which runs on the parent class first:

[KinematicBody:1422] Character _ready()
   At: res://scenes/characters/Character.gd:30:_ready()
[KinematicBody:1422] Player _ready()
   At: res://scenes/characters/player/Player.gd:34:_ready()

---

You can confirm the change of script by printing (self.get_script() as GDScript).resource_path. With that added to your debug prints, this is how it looks like:

[KinematicBody:1201] Character _init() res://Main/Character.gd
   At: res://Main/Character.gd:6:_init()
[KinematicBody:1201] Character _init() res://Main/Player.gd
   At: res://Main/Character.gd:6:_init()
[KinematicBody:1201] Player _init() res://Main/Player.gd
   At: res://Main/Player.gd:6:_init()
[KinematicBody:1201] Character _ready() res://Main/Player.gd
   At: res://Main/Character.gd:9:_ready()
[KinematicBody:1201] Player _ready() res://Main/Player.gd
   At: res://Main/Player.gd:9:_ready()

---

You have the current scene, so Godot goes over scene instancing for it, which does node instancing on its nodes from root to leafs. Which encounters a node that is an instance of Character.tscn. So Godot goes over scene instancing for Character.tscn, which does node instancing on its nodes. There Godot sets the script character.gd. Since the script changed (from none to character.gd) Godot and calls _init on it. That is the first _init call.

After scene instancing for Character.tscn finished, scene instancing for the current scene continues. So it changes the script to player.gd. Since the script changed (from character.gd to player.gd) Godot calls _init on it, but first it calls _init on the base class. So you get two more _init calls.

Afterwards, since we are loading the current scene, it reaches the ready mechanism, where Godot calls _ready. Which are also two calls because Godot call _ready on the base class first.

---

A few extra notes:

• When the script changes, there is a script_changed. But if you connect to it from the current scene, you will not get it. This is because the IDE signals has not been connected yet at the time. However, the IDE signals for Character.tscn would have been connected for the second script change (from character.gd to player.gd).
• The values of the properties of the node are not lost when switching scripts.
• I don't think there is a way to know ahead of time if the script will be changed.