Dynamically finding and loading resources from the Filesystem for Android and Web Exports
A little while ago, I created a type of AudioManager to make it easier to work with sound files in bulk: Rather than assigning audio streams by hand, I was doing it programmatically; reading the contents of a directory and using
load()
to get the resources. It worked great and saved a lot of time over assigning hundreds of sound resources by hand. While this worked during development and for Windows exports, it failed on Android and Web exports.
Godot Engine 4 will, at export time, relocate these resources. So if you are reading directly from the directory where you’re expecting a file to exist, it may no longer be there after the project is exported. Instead, you will find the same file with a “
.remap
” suffix added in its place. Just strip off that “.remap” suffix and use
ResourceLoader.load()
, which understands the resource mapping and can retrieve the proper resource for you.
The reason for the resource remapping is that some platforms require assets to be bundled in specific ways or stored in specific locations. The original asset has been moved, but Godot will instead have the same filename with an added “.remap” suffix to indicate that.
If you need to load something dynamically, use the ResourceLoader, and if you’re trying to discover content, scan the directory, and strip off the .remap suffix.
As long as you’re aware of this pitfall, you should be able to handle resources in your Godot game dynamically.
I’ve abstracted this into a general-purpose resource finder:
class_nameGGResourceFinderextends RefCounted## Iterates over files in a directory## making it easy to load contents from disk at run-time.#### This finder helps find resources that are remapped for Android## and Web exportsstaticfuncfind(directory:String,suffix:String) -> Array[String]:varfiles:Array[String] =_dir_contents(directory,suffix)files.sort()returnfiles## Recursively find files from a directorystaticfunc_dir_contents(path:String,suffix:String) -> Array[String]:vardir=DirAccess.open(path)if!dir:print("GGResourceFinder: 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!="":file_name=file_name.replace('.remap','')ifdir.current_is_dir():files.append_array(_dir_contents("%s/%s" % [path,file_name],suffix))eliffile_name.ends_with(suffix):files.append("%s/%s" % [path,file_name])file_name=dir.get_next()returnfiles
This script can then be used to find scenes from a particular directory. This may be relevant if you’re looking to support mods or DLCs in your Godot game since the game will have to have some way to discover and load the new content.
Anyway, path remapping is something to be aware of. I feel like that’s one of those things that’ll sneak up on you. Everything works great up until exporting, then suddenly everything’s broken for trying to be too data-driven. Some additional reading:
Just a couple of days ago, Godot 4.0 alpha 17 was announced. Today, Godot Engine 4.0 beta 1 was released. Be sure to check out the announcement. There are lots of improvements across the board; rendering, lighting, physics and navigation, animation, and scripting.
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 …
The first alpha of the inventory system v2 is now available. For v2, a lot of refactoring work has been done with a focus on improving the developer experience. As part of that, the naming convention of the addon classes was streamlined and is more consistent now. The GDScript documentation comments have been improved significantly …
The latest version includes a few new enhancements, and an experiment: The sequencer demo uses inventory instances to hold music notes, which can be played back. This was inspired by music trackers that were popular in the 90s, such as Scream Tracker and Impulse Tracker. The sequencer isn’t meant to be a production-ready digital audio …
Dynamically finding and loading resources from the Filesystem for Android and Web Exports
A little while ago, I created a type of AudioManager to make it easier to work with sound files in bulk: Rather than assigning audio streams by hand, I was doing it programmatically; reading the contents of a directory and using
load()to get the resources. It worked great and saved a lot of time over assigning hundreds of sound resources by hand. While this worked during development and for Windows exports, it failed on Android and Web exports.Godot Engine 4 will, at export time, relocate these resources. So if you are reading directly from the directory where you’re expecting a file to exist, it may no longer be there after the project is exported. Instead, you will find the same file with a “
.remap” suffix added in its place. Just strip off that “.remap” suffix and useResourceLoader.load(), which understands the resource mapping and can retrieve the proper resource for you.The reason for the resource remapping is that some platforms require assets to be bundled in specific ways or stored in specific locations. The original asset has been moved, but Godot will instead have the same filename with an added “.remap” suffix to indicate that.
If you need to load something dynamically, use the ResourceLoader, and if you’re trying to discover content, scan the directory, and strip off the .remap suffix.
As long as you’re aware of this pitfall, you should be able to handle resources in your Godot game dynamically.
I’ve abstracted this into a general-purpose resource finder:
This script can then be used to find scenes from a particular directory. This may be relevant if you’re looking to support mods or DLCs in your Godot game since the game will have to have some way to discover and load the new content.
Anyway, path remapping is something to be aware of. I feel like that’s one of those things that’ll sneak up on you. Everything works great up until exporting, then suddenly everything’s broken for trying to be too data-driven. Some additional reading:
Related Posts
Godot Engine 4 reaches beta
Just a couple of days ago, Godot 4.0 alpha 17 was announced. Today, Godot Engine 4.0 beta 1 was released. Be sure to check out the announcement. There are lots of improvements across the board; rendering, lighting, physics and navigation, animation, and scripting.
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 …
Inventory System 2 Alpha 1 available
The first alpha of the inventory system v2 is now available. For v2, a lot of refactoring work has been done with a focus on improving the developer experience. As part of that, the naming convention of the addon classes was streamlined and is more consistent now. The GDScript documentation comments have been improved significantly …
Inventory System v1.8 available
The latest version includes a few new enhancements, and an experiment: The sequencer demo uses inventory instances to hold music notes, which can be played back. This was inspired by music trackers that were popular in the 90s, such as Scream Tracker and Impulse Tracker. The sequencer isn’t meant to be a production-ready digital audio …