Update all resources after modifying a resource class
Godot’s resources are quite powerful. However, modifying a resource class doesn’t automatically update any corresponding
.tres
files, unless you happen to edit a scene that uses that resource in some way. This doesn’t impact runtime behavior — the game still runs as expected. But it can impact version control and result in a messier diff where seemingly unrelated files are modified, which increases the chance of merge conflicts.
A simple way to address this is to update all resources by re-saving them after modifying a resource class and check everything in with the same git commit. Godot doesn’t have that functionality built in, but it’s easy to create a script to do this.
@toolextends EditorScript## Crawls the entire codebase, loads, and re-saves every resource.## Run this script with CTRL/CMD+SHIFT+X.func_run() -> void:forfilenamein_build_file_list("res://","tres",20):varres:Resource=ResourceLoader.load(filename)ResourceSaver.save(res,res.resource_path)staticfunc_build_file_list(path:String,suffix:String,recursion_depth:int) -> Array[String]:vardir=DirAccess.open(path)ifnotdir:push_error("An error occurred when trying to access path: %s" % [path])return []varfiles:Array[String]dir.list_dir_begin()varfile_name=dir.get_next()whilefile_name!="":ifdir.current_is_dir()andrecursion_depth:varsub_dir:String="%s/%s" % [path, file_name]files.append_array(_build_file_list(sub_dir,suffix,recursion_depth - 1))eliffile_name.ends_with(suffix):varfull_path="%s/%s" % [path, file_name]files.append(full_path)file_name=dir.get_next()returnfiles
Version 1.0 of the Inventory System is now available. It includes a few new additions since the closed beta: Lots of fixes found their way into this release as well:
I had a setup with nested CanvasLayer nodes. Toggling the visibility of the root CanvasLayer doesn’t hide any nested CanvasLayer nodes. My solution was to listen to the visibility_changed signal, find any CanvasLayer child nodes, and apply the same visibility to them.
Are you using @onready to reference nodes? There’s a better way! Here’s a simple example of how many tutorials use @onready to reference nodes: That script is attached to a CanvasLayer node with a ProgressBar called HealthBar. And yet, when running the scene, it will throw an error: This is because there’s actually a spelling …
Update all resources after modifying a resource class
Godot’s resources are quite powerful. However, modifying a resource class doesn’t automatically update any corresponding
.tresfiles, unless you happen to edit a scene that uses that resource in some way. This doesn’t impact runtime behavior — the game still runs as expected. But it can impact version control and result in a messier diff where seemingly unrelated files are modified, which increases the chance of merge conflicts.A simple way to address this is to update all resources by re-saving them after modifying a resource class and check everything in with the same git commit. Godot doesn’t have that functionality built in, but it’s easy to create a script to do this.
Related Posts
Inventory System v1.2 available
A few new features: Bug fixes:
Inventory System v1.0 available
Version 1.0 of the Inventory System is now available. It includes a few new additions since the closed beta: Lots of fixes found their way into this release as well:
Toggling Visibility of Nested CanvasLayers
I had a setup with nested CanvasLayer nodes. Toggling the visibility of the root CanvasLayer doesn’t hide any nested CanvasLayer nodes. My solution was to listen to the visibility_changed signal, find any CanvasLayer child nodes, and apply the same visibility to them.
Ditch @onready, use @export instead
Are you using @onready to reference nodes? There’s a better way! Here’s a simple example of how many tutorials use @onready to reference nodes: That script is attached to a CanvasLayer node with a ProgressBar called HealthBar. And yet, when running the scene, it will throw an error: This is because there’s actually a spelling …