NodePath problem

jbskaggs

screenshot

Screenshot shows the problem.

Here is the code:

extends Spatial




# Slowly rotate towards object in 3D space
func turn_face(target, rotationSpeed, delta):
	var global_pos = global_transform.origin
	var marble_pos = $Node5Marble.global_transform.origin
	var wtransform = global_transform.looking_at(Vector3(marble_pos.x, global_pos.y, marble_pos.z),Vector3(0,1,0))
	var wrotation = Quat(global_transform.basis).slerp(Quat(wtransform.basis), rotationSpeed*delta)
	
	global_transform = Transform(Basis(wrotation), global_transform.origin)

$Node5Marble is seen as null. This script is called by Node2Rabbit2

It is a child in same tree as the calling node- see screenshot.

Any ideas what I am doing wrong?

cybereality

You generally shouldn't have loose code, outside of functions. That's the problem on line 2 of the script. If you want to call "turn_face" it has to be in a built-in function, like _ready(). Though if you change it to "onready var" it might work, but I would still consider it poor practice.

jbskaggs

@cybereality said: You generally shouldn't have loose code, outside of functions. That's the problem on line 2 of the script. If you want to call "turn_face" it has to be in a built-in function, like _ready(). Though if you change it to "onready var" it might work, but I would still consider it poor practice.

So it needed time to load the various things.

Thank you about code practice :)

cybereality

Right. The script is loaded almost immediately, but the nodes themselves need more time to load (especially if it's a complex tree, or they have lots of assets). So if you call a function loose at the top of the script, it happens before the scene is created, in which case the nodes probably don't exist (or maybe they do, depending on the order things get called, but this could break next time you run the app or on someone else's computer). That is the point of the _ready() function. So that the tree is created and valid, and then you can run your initialization code.

xyz

It's not about time. It's about order of instantiation.

Class code that's outside of any function will run immediately upon object instantiation.

Instantiation happens from top to bottom, as nodes are listed in the editor scene tree. So any code that runs on instantiation will only "see" nodes that are listed "before" it, as they've already been instantiated. Conversely, nodes listed "after" it will not yet exist at that moment.

In your specific case, at the time the engine instantiates your Node2Rabbit2 it immediately tries to access a child Node5Marble. This child doesn't exists at that time as it yet has to be instantiated - hence the error.

That's why all code that deals with initialization of children is typically put into ready(). This function is by design called once as soon as the node and all of its children have been instantiated and added to the scene tree. Code inside ready() is thus guaranteed to "see" all of node's children.

Erich_L

@xyz said: It's not about time. It's about order of instantiation....

Do you have any source to cite? Not to be rude, just would like to read more about how the engine works, especially this stuff that will directly relate to how we code in gdscript. I learned the hard and slow way about this particular point.

Uhhhgggg I used to just get on forums to troll. Now look at me. I feel disgusting.

jbskaggs

Thank each of you for helping me, and the info about instantiation is very helpful to me.

xyz

@Erich_L The only source I have is the official Godot documentation :) ... and possibly the Godot source (code) itself :) I also have some production experience with embeding a coroutine-based python scripting engine into a c++ opengl application.

Not sure what exactly you find confusing. It's actually rather simple. Godot operates like any other object oriented real time software. Objects need to be created and initialized, and then their references must go into some sort of data structure that manages them. It all typically happens in a sequential order. Godot lets you inject some script code at various stages of this process via callbacks like init(), ready(), _enter_tree()...

The order of things happening is deductible if you carefully read introductory chapters in Godot docs and also reference pages for key base classes like Object and Node, and descriptions of initialization related callbacks which are virtual methods of these classes.

That said, I already "complained" earlier that docs should include a technical getting-started chapter that's aimed at people with experience in development who are just getting started with Godot, with emphasis on engine architecture.

Last but not least :) when dealing with any kind of middleware, investing time in trial and error experimentation is a must if you aim to fully grok how things actually work. Especially with complex systems like game engines.

Erich_L

@xyz The docs say what there is in the engine and show nicely how it can be used. I don't see it explaining, taking this node example, what the engine does with this stuff once you've set it up in the editor. Perhaps because from their point of view it shouldn't really matter; it should just work. The reality though is that some of these things have a direct impact on how we code. I understand your experience gives you a better understanding. I guess I am wishing there was an article somewhere titled "How Godot Processes your Game". In my dreams it would give insights specifically in places that will prompt game developers to work in a way more... uhhh... "compatible" with Godot.

xyz

@Erich_L said: I guess I am wishing there was an article somewhere titled "How Godot Processes your Game". In my dreams it would give insights specifically in places that will prompt game developers to work in a way more... uhhh... "compatible" with Godot.

Yeah, this is an excellent idea! Something like that would fit nicely into docs as well - 'How Godot ticks' :) Maybe you should go ahead and try to write it while at the same time learning the stuff. Often the best articles are written that way.

I'll point out that I too am a Godot noob. And while prior experience surely helped to grasp things faster, I was utterly confuddled when started tinkering with it. To be honest I'd never recommend this type of game engine to someone with little programming experience. if this type of environment is your first serious encounter with a programming language, it could get very confusing and reinforce some bad programming practices. This is not really Godot's fault. Same goes for Unity, UE or anything in this category. Engines are imho just too heavyweight a tool for people without at least some basic computer science knowledge. But it's hard to resist as they come with a seductive promise of 'making games' :)

Anyway, for anyone who might be interested here's a very simple script that can help understand the order of initialization. It can be attached to all nodes of interest in the scene:

extends Node

var foo = print(get_instance_id(), " '", get_name(), "' property initialization")

func _init():
	print(get_instance_id(), " '", get_name(),  "' _init()")

func _enter_tree():
	print(get_instance_id(), " '", get_name(), "' _enter_tree()")

func _ready():
	print(get_instance_id(), " '", get_name(), "' _ready()")

And here's the output for just two nodes in a parent-child relationship. Note how nodes don't even have their names initialized before they are added to the scene tree:

1193 '' property initialization 1193 '' init() 1194 '' property initialization 1194 '' init() 1193 'Parent' enter_tree() 1194 'Child' enter_tree() 1194 'Child' ready() 1193 'Parent' ready()

cybereality

Right. That makes sense.

Erich_L

@xyz said:

@Erich_L said: I guess I am wishing there was an article somewhere titled "How Godot Processes your Game". In my dreams it would give insights specifically in places that will prompt game developers to work in a way more... uhhh... "compatible" with Godot.

Yeah, this is an excellent idea! Something like that would fit nicely into docs as well - 'How Godot ticks' :) Maybe you should go ahead and try to write it while at the same time learning the stuff. Often the best articles are written that way.

Ahhhh!! hahaha. I think that was the underlying intent of this thread here. You can tell I didn't get very far. I'll write if you guys edit :p

cybereality

I just got tripped up by this now. The ready is only valid for children of a parent. I assumed ready (or onready) meant the whole game was ready. But this is not the case. It is only ready for that branch of the tree. Meaning parents can access their children. But you cannot access siblings reliably. Lost about 30 minutes debugging that (because it was working intermittently, probably a race condition).

jbskaggs

@cybereality said: I just got tripped up by this now. The ready is only valid for children of a parent. I assumed ready (or onready) meant the whole game was ready. But this is not the case. It is only ready for that branch of the tree. Meaning parents can access their children. But you cannot access siblings reliably. Lost about 30 minutes debugging that (because it was working intermittently, probably a race condition).

And how do you work around this?

xyz

@cybereality Documentation is a bit ambiguous about ready(). In one place it states that ready() is called once all nodes are added to the scene tree, while in the other it says it's called when all of the node's children are added (and their _ready() callbacks finish execution, in reverse cascading fashion).

Not sure if there is some asynchronous execution involved there. I'd say the order of initialization is strictly sequential by design. But I may be wrong here. My experience is same as yours - only the node's child branch is guaranteed to "be there" when _ready() is entered. With asynchronous initialization this too would become unreliable. By 'initialization' here I mean addition to the scene tree. Actual object construction though may still happen in parallel.

Btw have you by chance tried to separately test for siblings that are listed before the node vs siblings listed after the node?

xyz

@jbskaggs said:

@cybereality said: I just got tripped up by this now. The ready is only valid for children of a parent. I assumed ready (or onready) meant the whole game was ready. But this is not the case. It is only ready for that branch of the tree. Meaning parents can access their children. But you cannot access siblings reliably. Lost about 30 minutes debugging that (because it was working intermittently, probably a race condition).

And how do you work around this?

You work with it, not around it. As this is how the system is designed. If you need everything in the scene to be there, possible way is to wait one frame at startup using yield: yield(VisualServer, "frame_post_draw")

cybereality

I guess the solution is to only get references to nodes that are the children of the current object, which is what you should be doing anyway as a good practice. It's weird, because I have been using get_node() for arbitrary objects in the scene (parents or siblings) but I had a lot of problems with it just now.

When I had the issue, I was working on a fullsceen fade-in script (just a black ColorRect with a tween on it). Now that I am looking at it, I don't think it was an async issue. My test scene, the menu, had the fade-in scene on it, but the parent of that node had the script to start the fade. And that worked. But on my main game scene, the script to start the fade was on a sibling node to the fade-in. Which did not work. Although the function would get called, the fade's internal nodes were not ready and were null and resulted in a crash. So I had to make sure that the main game script was on the root node, that way it could call all the children.

But that strange part was that the game was working before, even with the sibling nodes being called in the main script. But I think the difference was that the fade was saved as a scene (so I could use it in different places) while the other nodes in the game were loose in the tree. So it appears that saved scenes behave differently than loose nodes. In any case, only calling down the tree is what you should be doing, so I would say nothing is broken.

xyz

I played with it a bit. Looks like indeed any ready() callback sees the whole scene. enter_tree() callbacks for all nodes in the scene fire before the first ready() callback. At that point, all the nodes are there, in their proper places. However if one node's ready() relies on initialization that happens in another node's ready(), it can assume that only children's and preceding siblings' ready() callbacks have been executed. Pretty straightforward and as expected. Didn't test for instanced scenes though.

xyz

So here's a little chronology for @Erich_L's future article ;) In pseudocode:

for each node, sequentially:
   create node object 
   initialize script-level variables
   call _init()

# at this point all nodes are nameless and float in thin air 
# they don't know anything about each other

for each node, sequentially:
	name the node
	link the node into the scene tree
	call _enter_tree()  

for each node, sequentially:
	call _ready() but propagate the call to children first

cybereality

Here is an example of the problem I'm talking about.