godot: Circular dependency causes resources to be missing on export

Similar issue happened to my project. (Using Godot 4.1.1.stable.mono)

I have “sceneA”, which has a script with an [Export] reference to “sceneB”. Similarly, “sceneB” also has a script with a reference to “sceneA”. This relationship caused the issue for me, but I don’t know if it’s the only thing that does.

On reloading of the project, such relationship breaks every scenes it was involved in, causing the error as in the original post. Furthermore, if other scenes have any reference (either by script, or nested in the tree) to scenes broken this way, those will break too. This has caused all but one of my scenes to break.

I managed to resolve it by editing the .tscn files and removing all PackedScene references, but I’m afraid to move forward with the project since the same thing could happen again anytime, in a bigger scale, and I wouldn’t be able to notice it until the project is reloaded and everything breaks.

For what it’s worth I worked through this issue with my project.

The errors were pointing to the script property attached to the root node:

In game.tscn

[node name="Game" type="Node2D"]
script = ExtResource("1_3emra")

I removed the script = ... line, and then further above I removed the line with the matching id: Also in game.tscn

[ext_resource type="Script" path="res://scripts/game.gd" id="1_3emra"]

After that I was able to load the scene, and the script was not attached. I was able to add it back, generating a new id and everything seems to work again. Hope this is helpful!

   at: load (core/io/resource_format_binary.cpp:696)
ERROR: Failed loading resource: res://.godot/exported/133200997/export-ac4b7ec5c7c6a50838ddcd1f4e057820-candy_placer.scn. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:223)
ERROR: Can't load dependency: res://game/objects/candy_placer.tscn.
   at: load (core/io/resource_format_binary.cpp:696)
ERROR: Failed loading resource: res://.godot/exported/133200997/export-ccb27609e01d6460664dd431ed388159-bedroom.scn. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:223)
ERROR: Can't load dependency: res://game/levels/bedroom/bedroom.tscn.
   at: load (core/io/resource_format_binary.cpp:696)
ERROR: Failed loading resource: res://.godot/exported/133200997/export-be6198c9d492642daf2a2b8a18326593-bedroom_level.scn. Make sure resources have been imported by opening the project in the editor at least once.
   at: _load (core/io/resource_loader.cpp:223)

Still exists for me, please do not close

After digging for an hour on understanding why I was receiving this error on my project, the reason was in one of the scenes there was a weirdly missing reference to another scene.

In short my game is structured as follow:

• On each level, once the player reaches the goal, the next scene is loaded.
• In the last scene I have added a button that, when clicked, it brings the player to restart playing from the first level. This is where I was getting the error Make sure resources have been imported by opening the project in the editor at least once because, for some reason, Godot wasn’t able to find the first scene.

To solve the problem I had to modify the scene file, manually by removing the missing reference of the scene. Now all the scenes are loaded normally without issues.

Probably, this might not be the answer for Robert but it seems that this issue depends on how files are handled.

I just encountered this error in my project and found the problem, at least for me.

TL;DR: A Resource referenced Script, and the code in that Script loaded the Resource referencing it. Circular dependency during GDScript parsing.

I had a custom Resource with a reference to a Script, i.e., a .gdscript file. For one of those resources, the Script it referenced called preload() with a path to the Resource referencing it. This created a circular dependency that broke GDScript parsing. Changing it to load(), so it loaded at runtime and not during parsing, did not resolve it - I had to remove the circular reference entirely.

Hopefully this helps others who encounter this. I’m not quite sure why a script referencing a Resource that references back to the script breaks parsing, at least with a runtime call to load().

I was able to trace my issue and potentially solve it:

After troubleshooting, I found my version of the error occurred only with specific image files that were shared by multiple materials. For example, Guard_BLUE and Guard_RED both use the same texture in their materials: guard_packed1_diffuse_r1.png. When objects using or sharing those materials are loaded using ResourceLoader.load_threaded_request, the error is thrown. It even causes the mesh in question to disappear from the scene.

Reading in the docs, a particular piece of information became apparent - if a resource is already loaded, Godot will not load it again. So what I ended up doing was this:

1. Use the Debug panel to trace where the offending texture is. In my case, it was guard_packed1_diffuse_r1.png.
2. Right click on the texture and click “View Owners.” This will show which materials and which scenes were using it.
3. Find the texture in the Scene and right click -> “Make Unique.” This makes a unique version of the texture that shouldn’t conflict with the texture already loaded. Alternatively, you can reimport the object with NO embedded images and manually assign materials in Godot.
4. If you can’t find the texture or have a huge scene, I was able to find it by opening up the scene in text format in VsCode and searching via a string match.

This seems to have resolved my issues with this error. It may not apply to many of you, but it’s useful information to know that resources, particularly textures, CANNOT be loaded more than once in a scene, unless explicitly marked to do so by making them “Unique”. My suggestion would be to make this information part of the warning / error message, so users can know where and how to troubleshoot this.

To add on, my game could export from all 4 ways described in my first comment originally, then it stopped working one day out of nowhere…

I can confirm this issue on my end and @rob-williams is 100% right on the cause. #85922 doesn’t solve this issue either, so it’s still a problem.

Here’s a quick example of a potential recursion issue:

class_name Character
extends CharacterBody2D


const JUMP_VELOCITY = -400.0

# Get the gravity from the project settings to be synced with RigidBody nodes.
var gravity = ProjectSettings.get_setting("physics/2d/default_gravity")
var speed = 300.0


static func make(p_speed : float) -> Character:
	var pack_scene = preload("res://Character.tscn")
	var instance = pack_scene.instantiate()
	instance.speed = p_speed
	return instance

func _physics_process(delta):
	# Add the gravity.
	if not is_on_floor():
		velocity.y += gravity * delta

	# Handle jump.
	if Input.is_action_just_pressed("ui_accept") and is_on_floor():
		velocity.y = JUMP_VELOCITY

	# Get the input direction and handle the movement/deceleration.
	# As good practice, you should replace UI actions with custom gameplay actions.
	var direction = Input.get_axis("ui_left", "ui_right")
	if direction:
		velocity.x = direction * speed
	else:
		velocity.x = move_toward(velocity.x, 0, speed)

	move_and_slide()

This is a simplified version of a issue I have had in a much larger project. Basically, the static func is defined as a shorthand constructor for quickly instantiating a scene with specific args. This script is attached to the root node, but the attachment point is likely unimportant. Notably, this flags an error at resource_format_text.cpp:284 which gives no user feedback but debugging found that it returned ERR_BUSY. I’m still digging around to determine which method down the chain is returning ERR_BUSY but I can at least provide a minimum reproduction project.

recursive_parse_error.zip

If we could, it would be nice to update the issue’s title to reflect this recursion situation unless other potential causes can be determined. This is the only sure fire way I know to reproduce this bug – and even then, there are occasions where it inexplicably works. This inconsistency, and the ERR_BUSY return, gives me the feeling that there’s some threading issue at play here.

I’ve experienced this issue and have been able to semi-reliably recreate the error and recover from it. Replication project here

I’ve got exactly the same issue with a similar case where I use TP point to load a new map. For my test the A map tp to B and the B to A. My A scene was causing the trouble. I’m using @export too with PackedScene as type. Edit: with godot 4.1.1 as well.

@aurumboros TP stands for? Anyway which node are you using for loading the levels because to me it was a problem with the node I used for loading the next level.

Sry, TP stands for “Teleport”. To solve the issue -> I used a global dictionnary with some enums and the path to the scenes I want. I load the scene only when needed and it solves the issue.

In my previous setup, a “TP node” from a “scene A” referenced “scene B” thanks to @export Packed Scene with some coordinates to load the scene and teleport the player. Then in the “scene B” a node has a reference of the “scene A” with coordinates too. And the reference from A -> B and B -> A break the scenes until you remove the reference in the .tscn

This could be due to a similar cause as https://github.com/godotengine/godot/issues/55711, or due to texture compression project settings if this is a 3D project that uses VRAM compression for any textures (as is done by default).

@RobertSzaszak @hunterkepley Please upload a minimal reproduction project to make this easier to troubleshoot.