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
Arguably, more fun than writing code is removing code. I was assembling a split-screen multiplayer UI. The goal behavior is to show/hide the appropriate displays for the players, depending on how many players there are. Initially, the code to update the UI was very simple, because I started with two players. In that case, you …
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 …
Any sufficiently large code base needs documentation. Documentation tends to come in all sorts of shapes and sizes. Among them are high-level architecture and design docs, class and method interface documentation, and inline comments to explain optimized or complex algorithms so the reader doesn’t have to parse the logic in their head (often, this is …
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
A GDScript refactoring exercise
Arguably, more fun than writing code is removing code. I was assembling a split-screen multiplayer UI. The goal behavior is to show/hide the appropriate displays for the players, depending on how many players there are. Initially, the code to update the UI was very simple, because I started with two players. In that case, you …
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 …
Generating documentation for GDScript
Any sufficiently large code base needs documentation. Documentation tends to come in all sorts of shapes and sizes. Among them are high-level architecture and design docs, class and method interface documentation, and inline comments to explain optimized or complex algorithms so the reader doesn’t have to parse the logic in their head (often, this is …
Inventory System v1.2 available
A few new features: Bug fixes: