!is_inside_tree() is true

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By HorseGorilla

I added_child the room through the map and then added_child the door to the orientation. If you go through the door to another room, the room becomes call_deferred(“remove_child”) .

But in this case ‘can_process: Condition “!is_inside_tree()” is true. Returned: false’ is displayed. Other than this, it easily moves from room to room without any problems.

I’m not sure if this problem arises by calling remove_child like a door instanced in a room.

The tree order always changes the position after add_child statement in the room’s _ready() function just once. After that → the statement is tree_entered() and _ready() is called.

Sorry for not being able to show you the code. Thank you in spite of my poor English skills.

+) Is there a problem with a function that is called separately when creating an instance? This function is called for the purpose of saving variables only.

:bust_in_silhouette: Reply From: klaas

your description is somewhat hard to read (no offence).

This error often occurs when you attach a node to the tree via add_child and immediately call a function that expects the node to be in the tree. Because add_child takes a tiny while to actually put the node in the tree.
What you want is to ensure this has properly happend. Wait until the signal “tree_entered” or even better “ready” has been emited before doing anything with the newly attached node.

Thank you.

But I tried that and I still get the error !is_inside_tree() .

I’ll post a link to my code here. I’m not familiar with github, so please forgive me for uploading it as a drive.


HorseGorilla | 2021-08-10 13:32

please provide the whole error message with the line number and script name of the occurance.

klaas | 2021-08-10 16:04


Sorry, the lines aren’t even numbered, and the errors are so vague it drives me nuts.

However, although an error message appears, there is no other problem. I just hate to see that red color. Of course, if the project becomes huge, it may come out mixed with other problems.

HorseGorilla | 2021-08-10 16:59

After browsing through your code i guess the “problem” is caused by the remove_child. All nodes to process get collected, then all process calls are executed. If the remove_child gets executed before the removed child process call the nodes process call will fail in this cycle.
You would have to disable processing on the child one cycle before removing … or ignore the error, it would cause no harm anyway.

my two cents:
… i would prefer to not add and remove childs if not absolutly necessary. Fiddling around with the scene tree isnt ideal. Turn off processing, physics and visibility should do it too.

klaas | 2021-08-10 17:55

Then, after removing all the doors and players in Room.gd exiting_tree() , can I finally remove myself?

Thanks for the advice. I wanted a game like the Binding of Isaac, so I implemented it this way.

HorseGorilla | 2021-08-10 19:16

I dont see any necessity to add/remove all this objects. The player can reside on a layer above the scenery without any need to remove and attach it all the way. The doors can be parented to the rooms and when leaving only the room has to be “turned off”. This would be way more simpler and the “timing” problems would not occure.

But there are many ways to archive this … there is no right or wrong here

klaas | 2021-08-10 20:05

Thanks for the helpful comments. Really.

I think the door is supposed to open when all the enemies die anyway.

Enemies will also follow you with a map arrangement in the room. (AStar2D)

So, after hearing your valuable opinions, I thought it would be very good to widen the position of the room or to process the visible and physics_process(false) when leaving the room. It seems to prevent memory leaks that can occur when creating and removing each time.

Thank you very much. (My English was lacking.)

HorseGorilla | 2021-08-10 20:20