Godot @export var is Nil in _ready function

Godot Version



I created a health component and that health component has an export var for a health bar scene that I created. I drag the progress bar into the export slot in the inspector. I set the progress bar max value in the _ready() function of the health component but when I run the game it says that I can’t set max value of Nil. Am I missing something that I need to do to make this work? I am not sure what else I need to do other than drag the node to the export slot.

In the image below the script is the one that is attached to the HealthComponent. You can see the export var for the progress bar and I dragged the node in the scene tree to the export row in the inspector. You can also see the max_health set in _ready(), that is where it’s failing

Just a wild guess here, I think this has to do with the order Godot loads scenes in the scene tree from top to down. It might be that healthbar has not been loaded when the healthcomponent is looking for it.

Try adding healthbar as a child of healthcomponent.

From the tree order it should work. What is the error?

Does your progressbar have a property max_value?

Yeah I thought that the order was good since the HealthBar is before the HealthComponent. The error I am getting is:

Invalid assignment of property or key ‘max_value’ with value of type ‘float’ on base object of type ‘Nil’.

When I look at the Stack Variables the health bar is

Unfortunately that didn’t work. I am still getting the same error as above

Hmm, I use this technique often.

I guess you should make sure that progressbar is actually assigned to the node instance in the scene with the inspector.

Edit: Which you do…

I wonder if it’s a 4.3 bug.

this is a pretty common error most anyone face, but no idea why it got an error of null but the node is there

basically you call something too quick on _ready from a node that the method of property of called node is not yet existed. hence why it’s null

at your func _ready(): first line add this:

await get_tree().physics_frame

Yes, this is what I was thinking too. I was going to try and recreate it in 4.2 and see if I get this issue

try what i answered first, because it shouldnt be an engine bug, someone just got similar to this issue on other post.