QuickPack - Open Source Pakrat Replacement

Pakrat does not support automatically packing materials used in custom models, which has always driven me crazy. So I have gone ahead and made a program to replace it entirely:

https://github.com/jackson-c/quickpack

It’s a command-line program that automatically finds models, materials, textures, and sounds used in your BSP and then packs them. It’s extremely fast, and can be fully run in one click with a batch file. It also supports using a textfile list of specific dependencies to be added alongside auto-detected content.

Let me know what you think! If it’s failing to pack content in a specific circumstance, please let me know so I can fix it!

Quick question: Did you completely custom write the unpacking and re-packing of the BSP?

Nah, it uses bspzip.exe to save the file.

Alright, that’s what I was going to ask next. I think for most of the packing solutions, they would just be better if they scanned for a resources, and then saved them as a file (resource list), then sent that out for bspzip to do all the heavy-lifting.

Does it detect unusual files like cfg, particles, soundscape.txt, etc… ?
Because that’s the main reason you could need a manual packing.

Although I pack my whole map with Pakrat by draging a custom folder on my desktop (then just gotta fix paths of these unusual files), it’s much faster, and it dont miss anything :wink:

The thing that all content packers get wrong is this:

When a model has multiple skins, ALL of them get packed regardless of which ones are used or not. Larger maps would save tonnes of space if small things like this could be accounted for.

Not currently. I don’t know all the different file types a BSP could require, so I will add a fallback feature where you create a textfile list of dependencies and it will add all those as well.

I also used to have a special folder containing all the model materials used in my map, which were all copied from the Half-Life 2 folder. What a hassle to maintain!

[editline]30th September 2016[/editline]

I could attempt this. It would take quite a lot of complexity, and would have the possibility of creating missing textures if an entity changes skin on the fly (is this possible?), but I could add it as an option.

EDIT: I have added new features to address these comments. You can now create a textfile list of dependencies which will be added alongside the automatically found files. Additionally, you can create a textfile blacklist for which any file named in it will not be included nor will its dependencies. This can be used to block unused model skins (for now). See GitHub readme for info.

Models used with prop_static can never change skins on the fly. Dynamic props (also physics props, prop_door_rotating etc.) will in 99.999% cases not be able to change skins if they don’t have a targetname.

Ok, I’ve just done a big update to my script. The latest version only packs used skin materials on prop_static and entities without targetnames :smile: