Godot: A way to browse loaded resources from zip/pck files

Created on 19 Feb 2017  Â·  12Comments  Â·  Source: godotengine/godot

When loading a resource pack, the only way to know the contents is to append a (known) file with the data.
Even if the resources are accesible from res://, these are not visible by Directory or any other way.

What I ask for is a tool/class that can browse current and loaded resources like working with a real, unique filesystem, it could be really useful to manage DLC, level packs, packed mods and things like that.

archived discussion feature proposal core

Most helpful comment

Hey @eon-s,
I hope I'm not too late, but I just implemented a PCKDirectory class, it could be loaded as singleton.
It provides the same API as the Directory-class (it extends it).
I also added a "get_common_paths( pck_path )" function, which could be useful to test if a mod/DLC overwrites core-scrips before adding it to the game.

You can find it here (MIT license): https://github.com/MrJustreborn/godot_PCKDirectory

I'll maybe at it to the asset lib, if it's suitable for the problem.

All 12 comments

Seems this attracted lots of :+1:-s... and no :-1:-s.
So, to make use of the discussion tag, let's discuss the implementation details:

  • How do you imagine one would open the tool?

    • Via the editor? (probably from filesystem dock, or somewhere in the menus)

    • Via an external "game"/tool made with Godot? (just launch it, and browse to the various DLC-s)

    • Via the project manager? (launch Godot, click a new tab/button there, and browse to the various DLC-s)

  • Do you think it should be in editor core?

    • Makes sense, it just got to be a core editor functionality! (aka, just write the C++)

    • Naw, probably better for asset lib, editor is bloated already. (aka, just write it in GDScript)

  • Finally, should it be a 3.0-only feature?
  • \

My idea was just to have something like Directory (core) but for the full res://, like a virtual space containing default directory and new resources loaded with extra pck files (always talking about scripting).

Right now, you add a level pack and you can't use a directory listing to load them, the level pack needs an extra configuration file pointing to the new resources or overwrite (patch) an existing one.
Being able to list files and directories of a pack like if it is part of the original res (merged) could make this a lot more easy to manage, so the developer makes a directory structure for levels, textures, etc. and the game loads all like if were the original.


With that done, a visual tool to browse pck files will be easy to make if needed but I don't know if makes sense making it visual.

Just for 3 may be enough, I think.

I think this is solvable by platform.

1) If you know the platform you are running, and DLCs are downloaded by a
third party service, you can always use the host filesystem
2) If you want to download the DLCs from in-game, you can always download
them to user:// , and list user:// for DLCs available.

On Mon, Jun 12, 2017 at 10:09 AM, eon-s notifications@github.com wrote:

My idea was just to have something like Directory (core) but for the full
res://, like a virtual space containing default directory and new
resources loaded with extra pck files (always talking about scripting).

Right now, you add a level pack and you can't use a directory listing to
load them, the level pack needs an extra configuration file pointing to the
new resources or overwrite (patch) an existing one.
Being able to list files and directories of a pack like if it is part of
the original res (merged) could make this a lot more easy to manage, so the
developer makes a directory structure for levels, textures, etc. and the

game loads all like if were the original.

With that done, a visual tool to browse pck files will be easy to make if
needed but I don't know if makes sense making it visual.

Just for 3 may be enough, I think.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7845#issuecomment-307784112,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z27xWMvZzhYBvr8BAtLQMUSMVLYtlks5sDTiGgaJpZM4MFcRK
.

@reduz yes, but the content of the dlc pack will be unknown for the game unless it contains a known file that specify the DLC content, and once loaded, user pack contents are part of res so is not possible to see anything.

If you list the "res://Level" directory, you get [level1.scn,level2.scn].
Then if you load a resource pack with level3, listing the Level directory you get [level1.scn,level2.scn], level3 is on "res://Level" but is not part of the filesystem for Directory.

I know it is not ideal to use Directory for things like this but is handy and being able to access the full patched "res" could be more useful for pack management (DLC, modding).

I understand. I'm not sure if this is worth to add in godot core, but the
content of the .pck format is open and really simple, so making a very
simple and small parser should be easy as an asset lib addon

On Mon, Jun 12, 2017 at 10:38 AM, eon-s notifications@github.com wrote:

@reduz https://github.com/reduz yes, but the content of the dlc pack
will be unknown for the game unless it contains a known file that specify
the DLC content, and once loaded, user pack contents are part of res so is
not possible to see anything.

If you list the Level directory, you get [level1.scn,level2.scn].
Then if you load a resource pack with level3, listing the Level directory
you get [level1.scn,level2.scn], level3 is on "res://" but is not part of
the filesystem for Directory.

I know it is not ideal to use Directory for things like this but is handy
and being able to access the full patched "res" could be more useful for
pack management (DLC, modding).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7845#issuecomment-307791902,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2xm6b2bWusD0HRDbT7EoR-NV4Ykfks5sDT9pgaJpZM4MFcRK
.

I guess it shouldn't be hard to deduce from the code, but is the PCK format documented anywhere?

Hey @eon-s,
I hope I'm not too late, but I just implemented a PCKDirectory class, it could be loaded as singleton.
It provides the same API as the Directory-class (it extends it).
I also added a "get_common_paths( pck_path )" function, which could be useful to test if a mod/DLC overwrites core-scrips before adding it to the game.

You can find it here (MIT license): https://github.com/MrJustreborn/godot_PCKDirectory

I'll maybe at it to the asset lib, if it's suitable for the problem.

@MrJustreborn nice!
If you can, add it to the asset lib for 2 and/or 3 so it gets more visibility.

I thought about extending it maybe to a real EditorPlugin with a custom dock for creating DLCs, think of a GUI for the PCKPacker-class and maybe inspect a PCK, plus the PCKDirectory-wrapper for accessing it in exported games.

I wrote it with godot3alpha, but it SHOULD work with godot2, since i only used PCKPacker (for testing), the Directory and File classes.

I'll close this because is solved by a plugin and there is no intention to add the functionality to the core.

I am really surprised this is not part of core (and probably won't be, since this task is closed). Why you can load pck, but not walk it from code? Why Godot doesn't allow loading only list of file names (with paths) from pck without loading it to virtual fs? Why can't we load pck into a specified directory?

I don't know, this seems to me that Godot isn't really ready for supporting mods at all, even though docs seem to be suggesting otherwise.

@mnn open a new issue with the things you think that are missing or wrong with the resource pack loading process.

Was this page helpful?
0 / 5 - 0 ratings