You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A "retrogaming library frontend", heavily reliant on the functionality of loading external PCK files to implement core functionality.
Describe the problem or limitation you are having in your project
When porting the project to 4.0, I've found a problem when loading external PCK files. It generates a lot of warnings about unknown UID paths:
After looking around, it seems this UID information is not being added/read from PCK files. Before godot#50786, resource paths were the only way to uniquely identify a resource:
Now, since Godot internally uses these UIDs to reliably fetch files, and since they're randomly generated, this means that the UID will very likely change between files of the same path:
Currently, only the files themselves are added/replaced, while their UIDs are not. This creates problems because the UIDs are different, and scenes from the mod.pck file will be expecting a uid://def asset to exist, which it never does. Replacing the old UIDs with the ones from external PCK files, would also break existing references from the original project (if uid://def replaced uid://abc, the original res://scene.tscn would now complain that uid://abc doesn't exist).
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Godot stores this UID map at the editor level, in a uid_cache.bin file. This file is packaged on exported projects and read at runtime, and is currently also packaged on PCK files. Furthermore, this file is also always exported and can't be ignored:
The problem is that Godot currently doesn't load this file dynamically: it only loads it once when starting up. The idea is to change this behavior to consider that multiple uid_cache.bin files may exist, and instead add this information to the existing UID map.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
When reading a PCK file, whether it has replace_files set or not, the existing uid_cache.bin file is fetched, and it's contents are appended to the existing UID map. This way, the UID <-> source file mappings are preserved, and both scenes using original and new resources can successfully fetch them:
If this enhancement will not be used often, can it be worked around with a few lines of script?
It cannot be worked around, since this UID information is hardcoded on resource files. Although currently this doesn't affect behavior (when UID lookup fails, it uses the path as fallback), it still generates a lot of warnings.
Is there a reason why this should be core and not an add-on in the asset library?
This is core behavior that needs to be implemented in-engine.
The text was updated successfully, but these errors were encountered:
Describe the project you are working on
A "retrogaming library frontend", heavily reliant on the functionality of loading external PCK files to implement core functionality.
Describe the problem or limitation you are having in your project
When porting the project to 4.0, I've found a problem when loading external PCK files. It generates a lot of warnings about unknown UID paths:
After looking around, it seems this UID information is not being added/read from PCK files. Before godot#50786, resource paths were the only way to uniquely identify a resource:
Now, since Godot internally uses these UIDs to reliably fetch files, and since they're randomly generated, this means that the UID will very likely change between files of the same path:
Currently, only the files themselves are added/replaced, while their UIDs are not. This creates problems because the UIDs are different, and scenes from the
mod.pck
file will be expecting auid://def
asset to exist, which it never does. Replacing the old UIDs with the ones from external PCK files, would also break existing references from the original project (ifuid://def
replaceduid://abc
, the originalres://scene.tscn
would now complain thatuid://abc
doesn't exist).Describe the feature / enhancement and how it helps to overcome the problem or limitation
Godot stores this UID map at the editor level, in a
uid_cache.bin
file. This file is packaged on exported projects and read at runtime, and is currently also packaged on PCK files. Furthermore, this file is also always exported and can't be ignored:https://github.com/godotengine/godot/blob/46424488edc341b65467ee7fd3ac423e4d49ad34/editor/export/editor_export_platform.cpp#L842-L845
The problem is that Godot currently doesn't load this file dynamically: it only loads it once when starting up. The idea is to change this behavior to consider that multiple
uid_cache.bin
files may exist, and instead add this information to the existing UID map.Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
When reading a PCK file, whether it has
replace_files
set or not, the existinguid_cache.bin
file is fetched, and it's contents are appended to the existing UID map. This way, the UID <-> source file mappings are preserved, and both scenes using original and new resources can successfully fetch them:If this enhancement will not be used often, can it be worked around with a few lines of script?
It cannot be worked around, since this UID information is hardcoded on resource files. Although currently this doesn't affect behavior (when UID lookup fails, it uses the path as fallback), it still generates a lot of warnings.
Is there a reason why this should be core and not an add-on in the asset library?
This is core behavior that needs to be implemented in-engine.
The text was updated successfully, but these errors were encountered: