ResourceSaver.save not saving 0 int values in 4.5 RC2

[palepeak]

Tested versions

• Reproducible in 4.5 RC2, 4.5RC1
• Not Reproducible in 4.4.1 Stable

System information

Godot v4.5.rc2 - Windows 10 (build 19045) - Single-window, 2 monitors - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 (NVIDIA; 32.0.15.6094) - AMD Ryzen 5 3600X 6-Core Processor (12 threads) - 63.93 GiB memory

Issue description

ResourceSaver.save is not saving any int fields with values of 0.
The saved tres file has the fields omitted from the file entirely.

Steps to reproduce

Use ResourceSaver.save to save any resource with int fields.
Have the int fields be set to 0
Check output file and confirm the field is not present
Have the int fields be set to any none 0 value
Check output file and confirm the field is now present

Minimal reproduction project (MRP)

sandbox.zip

[StamLord]

I tried to reproduce this in v4.5.rc2.official [2dd26a0] and I think I know what is happening.

If I create the resource in my project's folder "res://OneIntPath.tres" and double click the resource I see it hase a "value=0" despite it not existing if I open the resource in a text editor:

I thought it might be an optimization where a missing value (that exists on the class) is assumed to be 0.
I added a "test" var initialized to 3 and it was missing too but assumed to be 3:

I believe that any value that is the same as the default is being omitted as if I change test to anything else before saving results in the value appearing:

Class

class_name OneIntResource extends Resource

@export var value: int = 0
@export var test: int = 3

Change before save

var t = OneIntResource.new(0)
t.test = 12
	
ResourceSaver.save(
	t, # Works with any value other than 0
	file_path
)

File in text editor

[gd_resource type="Resource" script_class="OneIntResource" load_steps=2 format=3]

[ext_resource type="Script" path="res://TestResource.gd" id="1_64h27"]

[resource]
script = ExtResource("1_64h27")
test = 12

[palepeak]

Ah good find, I've confirmed as well. I guess the issue is the default is assumed to be 0 even if I have an argument default in the _init override.

class_name OneIntResource extends Resource

@export var value: int

func _init(val: int = 3) -> void:
	value = val

In the above example, the resource will never be saved with value = 0, but will always be loaded as value = 3

[beicause]

This is an optimization, default values are not saved since

• Fix ResourceSaver saving default value of Resource #107049

[palepeak]

@OzelotVanilla @RandomShaper @akien-mga
I see y'all are the original authors and reviewers, what are your thoughts?
I think this optimization might cause a lot of confusion, especially with the example:

class_name OneIntResource extends Resource

@export var value: int

func _init(val: int = 3) -> void:
	value = val

Which would make saving the resource with 0 impossible.
This is the convention I've been using in my project since I can get an initialized resources with correct default values using:
var default_resource: OneIntResource = OneIntResource.new()
while also being able to pass any arguments in to set any fields if needed:
var set_resource: OneIntResource = OneIntResource.new(5)

[beicause]

@export var value: int

The value is 0 by default although it is not saved, no?

[palepeak]

The value is 0 by default, but it will not be saved because of the optimization.

[gd_resource type="Resource" script_class="OneIntResource" load_steps=2 format=3]

[ext_resource type="Script" path="res://TestResource.gd" id="1_sb6kc"]

[resource]
script = ExtResource("1_sb6kc")

If this resource is loaded, our _init override will be used.

func _init(val: int = 3) -> void:
	value = val

Since the resource file does not provide a value field, the default parameter will be used. This results in the resource being loaded as OneIntResource.new(3) essentially. That's what I'm guessing is happening?

[palepeak]

Just double checked with this modified script for the minimal reproduction project.

const file_path: String = "user://OneIntPath.tres"
# Called when the node enters the scene tree for the first time.
func _ready():
	ResourceSaver.save(
		OneIntResource.new(0), # Works with any value other than 0
		file_path
	)
	var result = ResourceLoader.load(file_path)
	print(result.value)

It will always print 3

[beicause]

You can make value default to 3. That should make it work as expected.

This might be a relatively edge case, you are setting value to 3 by default in _init but the default value of the property is 0.

[OzelotVanilla]

(Notice: I am still a beginner for Godot Engine, and for that PR, I just commit a code suggested by another project member. So, I am not sure what I have found is guaranteed to be correct. I would be happy if you point out my mistake)

I would like to point out a behaviour when I was doing my project. GDScript seems to use the values stored in .tres file as a value-for-overwrite. The building of an instance may go through a process like:

1. Build an empty object with member variable assigned by default value (a zero value such as 0 for int or "" for String, or the user-specified value like @export var test: int = 3 mentioned above)
2. Use the value stored in .tres file to overwrite. Example: test = 4 will make that variable set as 4.

I discovered this behaviour while I realised _init arguments is not the key-value entries stored in .tres file, as a result no wonder _init is not responsible for initialising when deserialising from .tres file 😢.

Providing this as an example (from OzelotVanilla/AdaptiveMusicUsingGraph@78bfc81):

For these lines:

## Array saving reference to node, sorted by node's id, from small to big.
@export var node_array: Array[MusicNode] = []:
    get = getAllNodes,
    set = loadFromNodeArray # This line was added to solve the not-loading issue
var node_dict: Dictionary[int, MusicNode] = {}

Even I had an _init like this, without the set line above, it will not load:

func _init(
    node_array: Array[MusicNode] = [],
    edge_array: Array[MusicEdge] = [],
    starting_node_id: int = -1
) -> void:
    pass

As the people who create that PR, I would like to agree with the behaviour of omitting default values of member variable, since it would make the .tres file smaller. I may suggest that add something like @export_no_omit to force create a key-value pair in .tres file.

However, I think there could be documentation to explain that loading of .tres is not calling _init, but overwriting values as I mentioned before.

PS: For _init, I found many built-in class tend to leave it zero-arg. I remembered I used a built-in function before, which can init an instance by providing class or script path as argument. But I could not pass _init argument of that class (it would be called like class_got.new() inside that built-in function). Therefore, I would like to suggest that GDScript has a convention that leave _init zero-arg, and assign values after initialisation.

[palepeak]

I am confused by this part:

However, I think there could be documentation to explain that loading of .tres is not calling _init, but overwriting values as I mentioned before.

From my experience, loading of .tres is calling _init. If I make the _init log being called:

func _init(val: int = 3) -> void:
	print("_init called %s" % [str(val)])
	value = val

Then my tests show that _init is called for loading .tres

func _ready():
	ResourceSaver.save(
		OneIntResource.new(0), # Prints 0
		file_path
	)
	var result = ResourceLoader.load(file_path) # Prints 3

This can also be reproduced with debug break points.

I assume Godot is not calling _init with the values from the .tres but I assume Godot uses a zero-arg _init as a starting point, which is where my bug comes from. My zero-arg _init still has a default value (3), but the actual value (0) is not present in the .tres since it was omitted for being the default value.

[palepeak]

I think conceptually the issue I have with this optimization is:

• The default value optimization does not respect default values defined in _init
• There is no way to know that default values will be optimized out
• The optimization assumes a default value, even if one is not set, as in:
  @export var value: int
  vs
  @export var value: int = 0

But I also recognize the issues with my approach of overloading _init with additional arguments since it messes with a lot of assumptions with the loading process.
Overall though, I do think Godot will be more resilient if resource parameters ares always saved and used during load, instead of assuming that omitting is equivalent to having the field set to it's default value.

[beicause]

_init is always called, then the saved properties are set.

Default values are not saved so the setters are not called, so the value is 3.

In this case, I am confused why ResourceLoader.load called the parameterized constructor instead of the parameterless constructor.

[OzelotVanilla]

By the way I just tested with my project and I found:

_init with node_array: []
   At: res://addons/adaptive_music_using_graph__plugin/core/data_type/MusicGraph.gd:51:_init()
loadFromNodeArray with node_array: [MusicNode@{id: 0, name: "MusicNode 0", strategy_slots: "[StrategySlot@{title: "Input", location: "left"}, StrategySlot@{title: "Eval Type Not Set", location: "right"}]", music_segment_path: "", }, MusicNode@{id: 1, name: "MusicNode 1", strategy_slots: "[StrategySlot@{title: "Input", location: "left"}]", music_segment_path: "", }]
   At: res://addons/adaptive_music_using_graph__plugin/core/data_type/MusicGraph.gd:138:loadFromNodeArray()
_init with node_array: []
   At: res://addons/adaptive_music_using_graph__plugin/core/data_type/MusicGraph.gd:51:_init()
_init with node_array: []
   At: res://addons/adaptive_music_using_graph__plugin/core/data_type/MusicGraph.gd:51:_init()

This is triggered by _edit of an EditorPlugin, when I click a .amug.tres file (that my plugin should handle).

PS: I was not using ResourceLoader for a non-empty .tres file. Using Godot v4.5 beta 7.

[palepeak]

I've replaced overloading the _init function with a static initialize getter and that addresses all my concerns. Thanks for all the help and explaining!