allenwp
commented
7 months ago I've trimmed down the minimum repro a bit:
Custom resource script:
class_name MyResource extends Resource
@export var my_resource_export : MyResourceTest script:
extends Node
func _ready() -> void:
var res_1 : MyResource = MyResource.new()
var res_2 : MyResource = MyResource.new()
res_1.my_resource_export = res_2
res_2.my_resource_export = res_1
ResourceSaver.save(res_1, "user://file.tres")This results in the error message:
E 0:00:00:0680 test.gd:10 @ _ready(): Resource was not pre cached for the resource section, bug?
<C++ Error> Method/function failed. Returning: "null"
<C++ Source> scene/resources/resource_format_text.cpp:1881 @ _write_resource()
<Stack Trace> test.gd:10 @ _ready()And a saved file that looks something like this:
[gd_resource type="Resource" script_class="MyResource" load_steps=3 format=3]
[ext_resource type="Script" path="res://my_resource.gd" id="1_7vp5f"]
[sub_resource type="Resource" id="Resource_c1iwo"]
script = ExtResource("1_7vp5f")
my_resource_export = null
[resource]
script = ExtResource("1_7vp5f")
my_resource_export = SubResource("Resource_c1iwo")If these sort of cyclic references are not supported by ResourceSaver, then I believe that the error message Resource was not pre cached for the resource section, bug? is problematic because it does not make it clear to the developer that the issue is simply an unsupported cyclic reference. Additionally, as mentioned in the original issue, there may not be any documentation describing this limitation.
If these sort of cyclic references should be supported, then this is simply a ResourceSaver bug.
AThousandShips
robbertzzz
Tested versions
Reproducible in v4.3.dev5.official [89f70e98d], v4.2.1-stable, v4.2-stable, v4.2-dev1
Does not exactly reproduce in v4.1.4-rc2, v4.1-stable, or v4.0-stable, but a different undesirable behavior is seen instead (resulting file is blank, no error message)
System information
Godot v4.2.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 (NVIDIA; 31.0.15.3699) - Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz (12 Threads)
Issue description
One object of type Alpha contains references to objects of type Beta. Beta itself also references to Beta objects. The same Beta objects are referred to in both; that is, the Beta objects in the Alpha reference each other.
If you use ResourceSaver.save() to serialize an Alpha object to disc, a number of the references in the arrays in the Beta objects will instead be written as 'null'. For each such instance, the following error message will be produced:
I dug into the resulting .tres file and what seems to be happening is that as the ResourceSaver is writing out the references held in the Beta object, it only correctly references the other Beta objects if it has already seen them in the Alpha object. Otherwise, it can't find them, and writes null.
I tried saving as both .tres and .res, and with and without FLAG_BUNDLE_RESOURCES set; the same behavior was seen in all cases.
Here's an example .tres file produced by my minimum reproduction project (renamed so github would accept it): file.txt
If you read it, you'll notice that the further down the file you go, the fewer null values you see. The first beta object's references are all null. Then for the next one, they're all null except for the first one that was written to the file. And for the third, all null except for the two we've already written. Etc. This is a simple example, but I've spent considerable time going over a much more complex real-world example (from when I first encountered this) and the same pattern holds.
It seems likely that this is caused by the circularity of the references, but I can't find any documentation on the ResourceSaver, ResourceFormatSaver, or Resource pages indicating that this is supposed to be invalid or a known issue.
I tested with versions going back to 4.0; prior to 4.2, the behavior was different, but also incorrect: it would silently fail, producing a blank file and no error at all.
Steps to reproduce
Open the Minimum Reproduction Project I've provided, and run the Project. You'll see the error messages appear, and the broken file will be generated at "user://file.tres".
Minimal reproduction project (MRP)
Bug Minimum Reproduction.zip