Custom Resource.tres not updating values when the Resource.gd script values are changed

[ozgur-kalay]

Tested versions

Godot v4.3.stable - Windows 10.0.26100 - GLES3 (Compatibility)

System information

Godot v4.3.stable - Windows 10.0.26100 - GLES3 (Compatibility) - Radeon RX 580 Series (Advanced Micro Devices, Inc.; 31.0.21921.1000) - 12th Gen Intel(R) Core(TM) i7-12700K (20 Threads)

Issue description

When changing the default value of a variable in a custom resource script (.gd), existing .tres resource files display the new default value correctly in the Inspector, but at runtime, the old value is still applied.

Example:

• health_resource.gd { var value: int = 10}
• player_health.tres { displays 10 in the inspector }
• print(player_health} output = 10

Change the value:

• health_resource.gd { var value: int = 20}
• player_health.tres { displays 20 in the inspector }
• print(player_health} output = 10

Steps to reproduce

1. Create a custom resource script "health_resource.gd".

2. set a variable in health_resource.gd, eg: var value: int = 10

3. Create a resource file "player_health.tres" from health_resource.gd:

   • The Inspector correctly displays value = 10.
   • At runtime, print(player_health.value) outputs = 10.

4. Modify the script to change the default value.

5. var value: int = 20

6. Observe the changes in the Inspector:

   • Open "player_health.tres".
   • The Inspector now displays "value = 20".

7. Run the game and print the value:
   print(player_health.value)

   • Expected output: 20
   • Actual output: 10 (old value)

Additional Notes

• The .tres file retains the old value even though the "Inspector" shows the updated default.
• Even when explicitly modifying the .tres file, the old value is applied at runtime.
• Deleting and recreating the .tres file applies the new default correctly.

Minimal reproduction project (MRP)

Basic starter project.

[AThousandShips]

Please upload an MRP to help testing this, this would likely be related to specific configuration in your project so an example of code where you have confirmed this happens is necessary

[JekSun97]

I confirm this happens on 4.3 stable and 4.4 beta1. Change the value of the variable "value" to 50 instead of 10 in the resource script new_resource.tres, you will see 10 instead of 50 when you run the project. I also tried Ctrl+S but it didn't change anything.

bug.zip

[btgs-0]

Correct me if I'm misunderstanding, but I think I see why this functions the way it does. A user may not necessarily want an underlying script change to cascade to all child resources. What if you had:

• enemy_health.tres: value = 100
• enemy_2_health.tres: value = 30
• player_health.tres: value = 45

Changing the underlying health_resource.gd script would wipe out all of the values set for each resource, wouldn't it? i.e. changing health_resource.gd value = 10 would mean:

• enemy_health.tres: value = 10
• enemy_2_health.tres: value = 10
• player_health.tres: value = 10

[klianc09]

I can confirm this still happens in v4.5.1.stable.official [f62fdbde1] but only with the setup in the bug.zip above (where no separate .gd file is created but only an "inline" script that's stored in the resource (idk what's the official name for that). When the script is stored in a separate .gd script then this issue does not appear.

Correct me if I'm misunderstanding, but I think I see why this functions the way it does. A user may not necessarily want an underlying script change to cascade to all child resources.

This is regarding default values, when no explicit value has been set in the child resources. You want default values to cascade, or else what's the point of default values.

[Nallebeorn]

From what I can tell this only happens because running the project (or pressing Ctrl+S) doesn't save the resource's built-in script (which you can tell from the (*) in the script list if you expand it enough). The inspector updates even without saving the script, but new_resource.tres doesn't. If you explicitly save the built-in script (Ctrl+Alt+S, or File->Save) before running, the new value is printed correctly.

This would make this issue a consequence of #113166 that @klianc09 just raised.

[klianc09]

Yeah that makes sense.

The initial issue (CASE A: for the case when the script is in a .gd file, just as described in the OP) was still present in v4.4.1 (which was the version I initially encountered the issue with) but has since been fixed in v4.5.1.

Now, CASE B (the case with the built-in script) is definitely related to #113166 but not completely the same. The remaining problem here isn't that the resource doesn't save, but that the inspector shows the new value already, although the script didn't actually save yet. (but maybe fixing that should also be part of #113166, IDK)

[Nallebeorn]

The remaining problem here isn't that the resource doesn't save, but that the inspector shows the new value already, although the script didn't actually save yet.

I'm not sure the inspector showing the new value without saving is a bug. On its own, that seems quite intuitive and convenient, and it behaves the same when editing exports in a standalone script. Not really familiar with the internals, but I think the inspector simply updates as soon as the script is reparsed -- the delay is affected by idle_parse_delay for example, so it happens at the same time as error checking.