Reparenting issue

[ember dew]

Hi all! When the player enters a new level in my 2D top down game, the new level scene spawns in the same tree with an offset (Vector2(0,5000)). I also reparent the player to the new scene because it's easier to manage the new level code locally there.

The issue arises when I reparent the player node, it seems to call its "ready" function. I don't want this behavior, is there any way to avoid it?

[onyx bloom]

Can you share the code that does the reparenting, both ways? I've not done much of that so it would be good to see how you did it rather than assume from googling it

The other tool that might be useful here is remote tree debugging. Start your game, then in the editor switch to the "Remote" tab in the scene view.

This will show you a live view of the actual node tree that's running in the game, including any objects spawned or moved by scripts. You can use this to confirm that the tree looks how you think it should while the game is running.

You can even pause the code by pressing pause next to the play button in the top right, and click on remote nodes to view and edit their values.

[ember dew]

Sure! The whole process is a bit complicated as there's many moving parts, but I'll do my best.

In the pictures you can see the "rest scene" (one with orbs) and the "combat scene" (houses). When you enter an orb, a function is called that:

1. Adds the combat scene (with offset) as a child of the root node
2. Reparents and teleports the player to the combat scene

Orb code snippet:

func _on_encounter_orb_area_entered(area: Player) -> void:
    call_deferred("_add_combat_scene", area)

    var new_scene = combat_scene.instantiate()
    get_tree().root.add_child(new_scene)
    new_scene.global_position = Vector2(0, 0)
    
    reparent_player(area, new_scene)
    teleport_player(area, new_scene)

func reparent_player(area, new_scene):
    area.reparent(new_scene.allies, true)

When teleporting from combat back to the rest scene after the fight is done, you also enter an orb with the same script (different references)

Aaaand as I was writing this, I noticed that there are 2 players in my "allies" node lol. I remember checking "remote" before and it worked, only spawned one player. Haven't touched that part of code in a week, looks like something changed, I'm gonna investigate.

oh my god, I forgot I added another player directly into the scene for testing 🤦‍♂️

[onyx bloom]

So when the game starts, the "rest" scene is created, my guess is that has a player instanced in it?

[ember dew]

ready doesn't get called twice on reparent

[ember dew]

yes

[onyx bloom]

out of curiosity, does ready get called when you do a reparent? This is me trying to learn how this works, was the issue it being called twice, or at all?

In my mind ready is when it enters the tree for the first time but i dont reparent stuff often so im not sure

[ember dew]

doesn't look like it. Phew, thought I had to rewrite my entire system

[onyx bloom]

ok, good to know

[ember dew]

I heard that you should never reparent nodes. But it's so convenient for me here that I'm doing it anyway. Seems better than storing a million variables in some autoload object

[onyx bloom]

i've also heard people say you "should never use" a lot of things, as long as you understand the consequences you can use whatever you like without shame if it lets you make the thing work

like Singletons, tons of people swear against those and I use them all the time

[ember dew]

yeah, such is everything in code. All has positives and negatives you have to weigh out. I'm only doing this for fun so if it works it works 🤷‍♂️

[onyx bloom]

tbh of all the things to say not to do, reparenting nodes is a silly one to me, this looks like a perfect use case. You preserve all data on the player and if you reuse the rest scene you keep all the data in there too with no extra mess

[ember dew]

True, and even more true for multiplayer it seems like. I don't have to bother with syncing tons of info, at least for now

[onyx bloom]

good luck 🙂