Provide a reliable way to see original resources in a directory #96590
Conversation
|
If you'll allow me to scrutinize the function name: if the function essentially lists files and not directories, perhaps an alternative name could be:
|
|
It lists both files and directories, it just appends a "/" to the end of the directory, I forgot to make note of this, will do so. |
|
Would this also mean that we wouldn't have to deal with .remap in exported games? Looks great! Looking forward to seeing this improvement! |
|
So I compared editor results with exported results and got this: Editor Exported Exported Notes:
Other than that seems to work correctly. |
|
Does this PR fully supersede #59334? |
|
Well my PR lists resource files together with non-resource files and excludes folders. But that's just alternative implementation, it's fully superseded. |
When exporting a project, resources are often moved, converted or
remapped (source import files are gone, text scenes are converted to binary,
etc).
This new function allows to list a directory and obtain the actual original
resource files.
Example
```GDScript
var resources = ResourceLoader.list_directory("res://images")
print(resources)
```
Result will be something like:
```
["image1.png","image2.png","image3.png"]
```
instead of
```
["image1.png.import","image2.png.import","image3.png.import"]
```
|
Applied changes suggested. |
| while (!d.is_empty()) { | ||
| bool recognized = false; | ||
| if (dir->current_is_dir()) { | ||
| if (d != "." && d != "..") { |
There was a problem hiding this comment.
It's weird that this is needed. DirAccess' include_navigational is false by default. The fact that it's different between editor and export means there is some bug.
There was a problem hiding this comment.
I have that feeling too, but I ended up adding it regardless.
There was a problem hiding this comment.
I tried listing directory using list_dir_begin() in GDScript and it's correctly skipping navigational paths. Seems like open() in C++ works a bit differently (GDScript uses _open()), but not sure what causes the wrong behavior.
EDIT:
Nevermind, it's because get_next method is bound to _get_next(), which does the skipping. Doesn't explain why it's different after exporting though.
EDIT2:
Ok this might be caused by DirAccessPack.
In any case, skipping it manually seems to be the solution anyway.
|
please refer to comments in the PR this supersedes why it's not actually "reliable". for example mine there and there tldr: you're guessing that a certain filename means that it used to have a different one, but the mere existence of ExportPlugins makes that assumption questionable at best. like KoBeWi said in the other PR, there's no way of actually doing this "reliable" without creating a list during export, and a simple |
|
@nonchip Yes, but that is a very corner case and generally external to the core engine, and even with export plugins remaps are still used, so it should work in almost every case. A "proper" solution is likely so complex that its not worth it. Likewise, this PR is fine as-is, and even if a better solution is deemed worth to implement in the future, the API exposed to the user is not changed. |
|
Thanks! |
When exporting a project, resources are often moved, converted or remapped (source import files are gone, text scenes are converted to binary, etc).
This new function is a convenience that allows to list a directory and obtain the actual original resource files.
Example
Result will be something like:
instead of
*.importfiles #25672.See On export, every
.tresfile is renamed to.tres.remap#66014.