2022-10-12 23:39:26 +02:00
# ifndef PACKEDSTORE_H
# define PACKEDSTORE_H
/*******************************************************************
* █ █ █ █ █ █ ╗ █ █ ╗ █ █ ╗ █ █ ╗ █ █ █ █ █ █ ╗ █ █ ╗ █ █ ╗ █ █ ╗ █ █ ╗ █ █ █ █ █ █ ╗ *
* █ █ ╔ ═ ═ █ █ ╗ █ █ █ ║ █ █ ║ █ █ ║ █ █ ╔ ═ ═ █ █ ╗ █ █ ║ █ █ ╔ ╝ █ █ ║ █ █ ║ █ █ ╔ ═ ═ █ █ ╗ *
* █ █ █ █ █ █ ╔ ╝ ╚ █ █ ║ █ █ ║ █ █ ║ █ █ █ █ █ █ ╔ ╝ █ █ █ █ █ ╔ ╝ █ █ ║ █ █ ║ █ █ █ █ █ █ ╔ ╝ *
* █ █ ╔ ═ ═ █ █ ╗ █ █ ║ ╚ █ █ ╗ █ █ ╔ ╝ █ █ ╔ ═ ═ ═ ╝ █ █ ╔ ═ █ █ ╗ █ █ ║ █ █ ║ █ █ ╔ ═ ═ █ █ ╗ *
* █ █ ║ █ █ ║ █ █ ║ ╚ █ █ █ █ ╔ ╝ █ █ ║ █ █ ║ █ █ ╗ █ █ █ █ █ █ █ ╗ █ █ ║ █ █ █ █ █ █ ╔ ╝ *
* ╚ ═ ╝ ╚ ═ ╝ ╚ ═ ╝ ╚ ═ ═ ═ ╝ ╚ ═ ╝ ╚ ═ ╝ ╚ ═ ╝ ╚ ═ ═ ═ ═ ═ ═ ╝ ╚ ═ ╝ ╚ ═ ═ ═ ═ ═ ╝ *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2022-11-23 12:18:33 +01:00
# include "public/ifilesystem.h"
2023-05-29 21:41:17 +02:00
# include "public/tier1/strtools.h"
# include "public/tier1/utlvector.h"
# include "public/tier1/utlstring.h"
2021-12-25 22:36:38 +01:00
# include "thirdparty/lzham/include/lzham.h"
2022-06-05 12:28:49 +02:00
constexpr unsigned int VPK_HEADER_MARKER = 0x55AA1234 ;
Proper VPK repacking
Initial proper implementation pending cleanup.
The new system builds a manifest file when a VPK is unpacked. The manifest files contains data such as the entry flags and texture flags. It also contains a field determining whether the file should be compressed or not.
When a user repacks a pack, the system attempts to load this manifest file and does a lookup to the object to retrieve the flags (most of these flags are unknown, but they are used by the engine and are necessary for stuff like cubemaps and texture files to work correctly. Cubemaps won't work with proper flags, and textures (decals, particle system components, etc..) will look washed out without them.
I think some also determine whether a file within the VPK should be cached or not, so simply marking everything as 0x101 will probably end up in more CPU time and higher filesystem cache usage (depot/ is only 0x1, I don't think anything there is getting cached ever without the 0x100 flag).
User could also repack a VPK while excluding anything that is not in the manifest file. So you could unpack all VPK's into a single directory (each VPK has its own manifest file tied to its level name), and rebuild all the VPK's with only the files that where originally in them.
fs_pack_vpk command usage: <locale> <context> <level_name> <manifest_only>
locale determines the pak language (default english), context determines whether is a server/client vpk, level_name determines the BSP name of the pak, manifest_only determines whether the pack system should only include files within the manifest (leaving this arg out will build all files into the vpk).
The VPK workspace path is determined with ConVar 'fs_packedstore_workspace'.
2022-06-04 01:08:23 +02:00
constexpr unsigned int VPK_MAJOR_VERSION = 2 ;
constexpr unsigned int VPK_MINOR_VERSION = 3 ;
2022-06-05 12:28:49 +02:00
constexpr unsigned int VPK_DICT_SIZE = 20 ;
constexpr int ENTRY_MAX_LEN = 1024 * 1024 ;
2022-11-17 20:37:12 +01:00
constexpr int PACKFILEPATCH_MAX = 512 ;
2022-11-23 12:18:33 +01:00
constexpr int PACKFILEINDEX_SEP = 0x0 ;
2022-11-16 00:54:51 +01:00
constexpr int PACKFILEINDEX_END = 0xffff ;
2023-05-29 21:41:17 +02:00
constexpr const char VPK_IGNORE_FILE [ ] = " .vpkignore " ;
2021-12-25 22:36:38 +01:00
2023-05-29 21:41:17 +02:00
static const char * const DIR_TARGET [ ]
2022-10-02 12:17:03 +02:00
{
" server " ,
" client "
} ;
2023-05-29 21:41:17 +02:00
static const char * const DIR_LOCALE [ ]
2022-10-02 12:17:03 +02:00
{
" english " ,
" french " ,
" german " ,
" italian " ,
" japanese " ,
" korean " ,
" polish " ,
" portuguese " ,
" russian " ,
" spanish " ,
" tchinese "
} ;
Proper VPK repacking
Initial proper implementation pending cleanup.
The new system builds a manifest file when a VPK is unpacked. The manifest files contains data such as the entry flags and texture flags. It also contains a field determining whether the file should be compressed or not.
When a user repacks a pack, the system attempts to load this manifest file and does a lookup to the object to retrieve the flags (most of these flags are unknown, but they are used by the engine and are necessary for stuff like cubemaps and texture files to work correctly. Cubemaps won't work with proper flags, and textures (decals, particle system components, etc..) will look washed out without them.
I think some also determine whether a file within the VPK should be cached or not, so simply marking everything as 0x101 will probably end up in more CPU time and higher filesystem cache usage (depot/ is only 0x1, I don't think anything there is getting cached ever without the 0x100 flag).
User could also repack a VPK while excluding anything that is not in the manifest file. So you could unpack all VPK's into a single directory (each VPK has its own manifest file tied to its level name), and rebuild all the VPK's with only the files that where originally in them.
fs_pack_vpk command usage: <locale> <context> <level_name> <manifest_only>
locale determines the pak language (default english), context determines whether is a server/client vpk, level_name determines the BSP name of the pak, manifest_only determines whether the pack system should only include files within the manifest (leaving this arg out will build all files into the vpk).
The VPK workspace path is determined with ConVar 'fs_packedstore_workspace'.
2022-06-04 01:08:23 +02:00
2022-11-23 12:18:33 +01:00
struct VPKKeyValues_t
Proper VPK repacking
Initial proper implementation pending cleanup.
The new system builds a manifest file when a VPK is unpacked. The manifest files contains data such as the entry flags and texture flags. It also contains a field determining whether the file should be compressed or not.
When a user repacks a pack, the system attempts to load this manifest file and does a lookup to the object to retrieve the flags (most of these flags are unknown, but they are used by the engine and are necessary for stuff like cubemaps and texture files to work correctly. Cubemaps won't work with proper flags, and textures (decals, particle system components, etc..) will look washed out without them.
I think some also determine whether a file within the VPK should be cached or not, so simply marking everything as 0x101 will probably end up in more CPU time and higher filesystem cache usage (depot/ is only 0x1, I don't think anything there is getting cached ever without the 0x100 flag).
User could also repack a VPK while excluding anything that is not in the manifest file. So you could unpack all VPK's into a single directory (each VPK has its own manifest file tied to its level name), and rebuild all the VPK's with only the files that where originally in them.
fs_pack_vpk command usage: <locale> <context> <level_name> <manifest_only>
locale determines the pak language (default english), context determines whether is a server/client vpk, level_name determines the BSP name of the pak, manifest_only determines whether the pack system should only include files within the manifest (leaving this arg out will build all files into the vpk).
The VPK workspace path is determined with ConVar 'fs_packedstore_workspace'.
2022-06-04 01:08:23 +02:00
{
2022-11-23 12:18:33 +01:00
static constexpr uint16_t TEXTURE_FLAGS_DEFAULT = static_cast < uint16_t > ( EPackedTextureFlags : : TEXTURE_DEFAULT ) ;
static constexpr uint32_t LOAD_FLAGS_DEFAULT = static_cast < uint32_t > ( EPackedLoadFlags : : LOAD_VISIBLE ) | static_cast < uint32_t > ( EPackedLoadFlags : : LOAD_CACHE ) ;
2023-05-29 21:41:17 +02:00
CUtlString m_EntryPath ;
2022-11-23 12:18:33 +01:00
uint16_t m_iPreloadSize ;
uint32_t m_nLoadFlags ;
uint16_t m_nTextureFlags ;
bool m_bUseCompression ;
2023-04-03 20:08:36 +02:00
bool m_bDeduplicate ;
2022-11-23 12:18:33 +01:00
2023-05-29 21:41:17 +02:00
VPKKeyValues_t ( const CUtlString & svEntryPath = " " , uint16_t iPreloadSize = NULL , uint32_t nLoadFlags = LOAD_FLAGS_DEFAULT ,
2023-04-03 20:08:36 +02:00
uint16_t nTextureFlags = TEXTURE_FLAGS_DEFAULT , bool bUseCompression = true , bool bDeduplicate = true ) ;
Proper VPK repacking
Initial proper implementation pending cleanup.
The new system builds a manifest file when a VPK is unpacked. The manifest files contains data such as the entry flags and texture flags. It also contains a field determining whether the file should be compressed or not.
When a user repacks a pack, the system attempts to load this manifest file and does a lookup to the object to retrieve the flags (most of these flags are unknown, but they are used by the engine and are necessary for stuff like cubemaps and texture files to work correctly. Cubemaps won't work with proper flags, and textures (decals, particle system components, etc..) will look washed out without them.
I think some also determine whether a file within the VPK should be cached or not, so simply marking everything as 0x101 will probably end up in more CPU time and higher filesystem cache usage (depot/ is only 0x1, I don't think anything there is getting cached ever without the 0x100 flag).
User could also repack a VPK while excluding anything that is not in the manifest file. So you could unpack all VPK's into a single directory (each VPK has its own manifest file tied to its level name), and rebuild all the VPK's with only the files that where originally in them.
fs_pack_vpk command usage: <locale> <context> <level_name> <manifest_only>
locale determines the pak language (default english), context determines whether is a server/client vpk, level_name determines the BSP name of the pak, manifest_only determines whether the pack system should only include files within the manifest (leaving this arg out will build all files into the vpk).
The VPK workspace path is determined with ConVar 'fs_packedstore_workspace'.
2022-06-04 01:08:23 +02:00
} ;
2022-06-06 14:54:22 +02:00
struct VPKChunkDescriptor_t
2021-12-25 22:36:38 +01:00
{
2022-10-12 23:39:26 +02:00
uint32_t m_nLoadFlags ; // Load flags.
uint16_t m_nTextureFlags ; // Texture flags (only used if the entry is a vtf).
2022-11-16 00:54:51 +01:00
uint64_t m_nPackFileOffset ; // Offset in pack file.
2022-10-12 23:39:26 +02:00
uint64_t m_nCompressedSize ; // Compressed size of chunk.
uint64_t m_nUncompressedSize ; // Uncompressed size of chunk.
2021-12-25 22:36:38 +01:00
2023-05-29 21:41:17 +02:00
VPKChunkDescriptor_t ( )
: m_nLoadFlags ( 0 )
, m_nTextureFlags ( 0 )
, m_nPackFileOffset ( 0 )
, m_nCompressedSize ( 0 )
, m_nUncompressedSize ( 0 )
{
}
2022-11-23 17:09:48 +01:00
VPKChunkDescriptor_t ( FileHandle_t hDirectoryFile ) ;
VPKChunkDescriptor_t ( uint32_t nLoadFlags , uint16_t nTextureFlags , uint64_t nPackFileOffset , uint64_t nCompressedSize , uint64_t nUncompressedSize ) ;
2021-12-25 22:36:38 +01:00
} ;
2022-04-09 00:59:42 +02:00
struct VPKEntryBlock_t
2021-12-25 22:36:38 +01:00
{
2023-05-29 21:41:17 +02:00
uint32_t m_nFileCRC ; // Crc32 for the uncompressed entry.
uint16_t m_iPreloadSize ; // Preload bytes.
uint16_t m_iPackFileIndex ; // Index of the pack file that contains this entry.
CUtlVector < VPKChunkDescriptor_t > m_Fragments ; // Vector of all the chunks of a given entry (chunks have a size limit of 1 MiB, anything over this limit is fragmented into smaller chunks).
CUtlString m_EntryPath ; // Path to entry within vpk.
2022-06-06 14:54:22 +02:00
2023-05-29 21:41:17 +02:00
VPKEntryBlock_t ( FileHandle_t pFile , const char * svEntryPath ) ;
2022-11-23 17:09:48 +01:00
VPKEntryBlock_t ( const uint8_t * pData , size_t nLen , int64_t nOffset , uint16_t iPreloadSize ,
2023-05-29 21:41:17 +02:00
uint16_t iPackFileIndex , uint32_t nLoadFlags , uint16_t nTextureFlags , const char * svEntryPath ) ;
VPKEntryBlock_t ( const VPKEntryBlock_t & other )
: m_nFileCRC ( other . m_nFileCRC )
, m_iPreloadSize ( other . m_iPreloadSize )
, m_iPackFileIndex ( other . m_iPackFileIndex )
, m_EntryPath ( other . m_EntryPath )
{
// Has to be explicitly copied!
m_Fragments = other . m_Fragments ;
}
2021-12-25 22:36:38 +01:00
} ;
Proper VPK repacking
Initial proper implementation pending cleanup.
The new system builds a manifest file when a VPK is unpacked. The manifest files contains data such as the entry flags and texture flags. It also contains a field determining whether the file should be compressed or not.
When a user repacks a pack, the system attempts to load this manifest file and does a lookup to the object to retrieve the flags (most of these flags are unknown, but they are used by the engine and are necessary for stuff like cubemaps and texture files to work correctly. Cubemaps won't work with proper flags, and textures (decals, particle system components, etc..) will look washed out without them.
I think some also determine whether a file within the VPK should be cached or not, so simply marking everything as 0x101 will probably end up in more CPU time and higher filesystem cache usage (depot/ is only 0x1, I don't think anything there is getting cached ever without the 0x100 flag).
User could also repack a VPK while excluding anything that is not in the manifest file. So you could unpack all VPK's into a single directory (each VPK has its own manifest file tied to its level name), and rebuild all the VPK's with only the files that where originally in them.
fs_pack_vpk command usage: <locale> <context> <level_name> <manifest_only>
locale determines the pak language (default english), context determines whether is a server/client vpk, level_name determines the BSP name of the pak, manifest_only determines whether the pack system should only include files within the manifest (leaving this arg out will build all files into the vpk).
The VPK workspace path is determined with ConVar 'fs_packedstore_workspace'.
2022-06-04 01:08:23 +02:00
struct VPKDirHeader_t
2021-12-25 22:36:38 +01:00
{
2022-10-12 23:39:26 +02:00
uint32_t m_nHeaderMarker ; // File magic.
uint16_t m_nMajorVersion ; // Vpk major version.
uint16_t m_nMinorVersion ; // Vpk minor version.
uint32_t m_nDirectorySize ; // Directory tree size.
uint32_t m_nSignatureSize ; // Directory signature.
2022-05-30 02:56:15 +02:00
} ;
2022-11-23 17:09:48 +01:00
struct VPKPair_t
{
2023-05-29 21:41:17 +02:00
CUtlString m_PackName ;
CUtlString m_DirName ;
2022-11-23 17:09:48 +01:00
2023-05-29 21:41:17 +02:00
VPKPair_t ( const char * svLocale , const char * svTarget , const char * svLevel , int nPatch ) ;
2022-11-23 17:09:48 +01:00
} ;
2022-05-30 02:56:15 +02:00
struct VPKDir_t
{
2023-05-29 21:41:17 +02:00
VPKDirHeader_t m_Header ; // Dir header.
CUtlVector < VPKEntryBlock_t > m_EntryBlocks ; // Vector of entry blocks.
uint16_t m_PackFileCount ; // Number of pack patches (pack file count-1).
CUtlVector < CUtlString > m_PackFiles ; // Vector of pack file names.
CUtlString m_DirFilePath ; // Path to vpk_dir file.
2021-12-25 22:36:38 +01:00
2023-07-05 23:04:07 +02:00
class CTreeBuilder
{
public :
typedef std : : map < std : : string , std : : list < VPKEntryBlock_t > > PathContainer_t ;
typedef std : : map < std : : string , PathContainer_t > TypeContainer_t ;
void BuildTree ( const CUtlVector < VPKEntryBlock_t > & entryBlocks ) ;
uint64_t WriteTree ( FileHandle_t hDirectoryFile ) const ;
private :
TypeContainer_t m_FileTree ;
} ;
2022-11-23 17:09:48 +01:00
VPKDir_t ( )
{
2023-07-05 23:04:07 +02:00
m_Header . m_nHeaderMarker = VPK_HEADER_MARKER ; m_Header . m_nMajorVersion = VPK_MAJOR_VERSION ;
2023-05-29 21:41:17 +02:00
m_Header . m_nMinorVersion = VPK_MINOR_VERSION ; m_Header . m_nDirectorySize = NULL , m_Header . m_nSignatureSize = NULL ;
m_PackFileCount = NULL ;
2022-11-23 17:09:48 +01:00
} ;
2023-05-29 21:41:17 +02:00
VPKDir_t ( const CUtlString & svDirectoryFile ) ;
VPKDir_t ( const CUtlString & svDirectoryFile , bool bSanitizeName ) ;
2022-05-30 02:56:15 +02:00
2023-05-29 21:41:17 +02:00
void Init ( const CUtlString & svPath ) ;
2022-11-23 17:09:48 +01:00
2023-05-29 21:41:17 +02:00
CUtlString StripLocalePrefix ( const CUtlString & svDirectoryFile ) const ;
CUtlString GetPackFile ( const CUtlString & svDirectoryPath , uint16_t iPackFileIndex ) const ;
2022-11-23 17:09:48 +01:00
void WriteHeader ( FileHandle_t hDirectoryFile ) const ;
void WriteTreeSize ( FileHandle_t hDirectoryFile ) const ;
2022-11-23 12:27:57 +01:00
2023-07-04 22:08:44 +02:00
void BuildDirectoryFile ( const CUtlString & svDirectoryFile , const CUtlVector < VPKEntryBlock_t > & entryBlocks ) ;
Proper VPK repacking
Initial proper implementation pending cleanup.
The new system builds a manifest file when a VPK is unpacked. The manifest files contains data such as the entry flags and texture flags. It also contains a field determining whether the file should be compressed or not.
When a user repacks a pack, the system attempts to load this manifest file and does a lookup to the object to retrieve the flags (most of these flags are unknown, but they are used by the engine and are necessary for stuff like cubemaps and texture files to work correctly. Cubemaps won't work with proper flags, and textures (decals, particle system components, etc..) will look washed out without them.
I think some also determine whether a file within the VPK should be cached or not, so simply marking everything as 0x101 will probably end up in more CPU time and higher filesystem cache usage (depot/ is only 0x1, I don't think anything there is getting cached ever without the 0x100 flag).
User could also repack a VPK while excluding anything that is not in the manifest file. So you could unpack all VPK's into a single directory (each VPK has its own manifest file tied to its level name), and rebuild all the VPK's with only the files that where originally in them.
fs_pack_vpk command usage: <locale> <context> <level_name> <manifest_only>
locale determines the pak language (default english), context determines whether is a server/client vpk, level_name determines the BSP name of the pak, manifest_only determines whether the pack system should only include files within the manifest (leaving this arg out will build all files into the vpk).
The VPK workspace path is determined with ConVar 'fs_packedstore_workspace'.
2022-06-04 01:08:23 +02:00
} ;
2021-12-25 22:36:38 +01:00
class CPackedStore
{
public :
2022-02-06 15:59:46 +01:00
void InitLzCompParams ( void ) ;
void InitLzDecompParams ( void ) ;
Proper VPK repacking
Initial proper implementation pending cleanup.
The new system builds a manifest file when a VPK is unpacked. The manifest files contains data such as the entry flags and texture flags. It also contains a field determining whether the file should be compressed or not.
When a user repacks a pack, the system attempts to load this manifest file and does a lookup to the object to retrieve the flags (most of these flags are unknown, but they are used by the engine and are necessary for stuff like cubemaps and texture files to work correctly. Cubemaps won't work with proper flags, and textures (decals, particle system components, etc..) will look washed out without them.
I think some also determine whether a file within the VPK should be cached or not, so simply marking everything as 0x101 will probably end up in more CPU time and higher filesystem cache usage (depot/ is only 0x1, I don't think anything there is getting cached ever without the 0x100 flag).
User could also repack a VPK while excluding anything that is not in the manifest file. So you could unpack all VPK's into a single directory (each VPK has its own manifest file tied to its level name), and rebuild all the VPK's with only the files that where originally in them.
fs_pack_vpk command usage: <locale> <context> <level_name> <manifest_only>
locale determines the pak language (default english), context determines whether is a server/client vpk, level_name determines the BSP name of the pak, manifest_only determines whether the pack system should only include files within the manifest (leaving this arg out will build all files into the vpk).
The VPK workspace path is determined with ConVar 'fs_packedstore_workspace'.
2022-06-04 01:08:23 +02:00
2022-09-11 00:16:31 +02:00
lzham_compress_level GetCompressionLevel ( void ) const ;
2022-06-06 14:54:22 +02:00
2023-05-29 21:41:17 +02:00
void GetEntryBlocks ( CUtlVector < VPKEntryBlock_t > & entryBlocks , FileHandle_t hDirectoryFile ) const ;
bool GetEntryValues ( CUtlVector < VPKKeyValues_t > & entryValues , const CUtlString & workspacePath , const CUtlString & dirFileName ) const ;
2022-06-06 14:54:22 +02:00
2023-05-29 21:41:17 +02:00
CUtlString GetNameParts ( const CUtlString & dirFileName , int nCaptureGroup ) const ;
CUtlString GetLevelName ( const CUtlString & dirFileName ) const ;
2022-06-06 23:08:53 +02:00
2023-05-29 21:41:17 +02:00
KeyValues * GetManifest ( const CUtlString & workspacePath , const CUtlString & manifestFile ) const ;
bool GetIgnoreList ( CUtlVector < CUtlString > & ignoreList , const CUtlString & workspacePath ) const ;
Proper VPK repacking
Initial proper implementation pending cleanup.
The new system builds a manifest file when a VPK is unpacked. The manifest files contains data such as the entry flags and texture flags. It also contains a field determining whether the file should be compressed or not.
When a user repacks a pack, the system attempts to load this manifest file and does a lookup to the object to retrieve the flags (most of these flags are unknown, but they are used by the engine and are necessary for stuff like cubemaps and texture files to work correctly. Cubemaps won't work with proper flags, and textures (decals, particle system components, etc..) will look washed out without them.
I think some also determine whether a file within the VPK should be cached or not, so simply marking everything as 0x101 will probably end up in more CPU time and higher filesystem cache usage (depot/ is only 0x1, I don't think anything there is getting cached ever without the 0x100 flag).
User could also repack a VPK while excluding anything that is not in the manifest file. So you could unpack all VPK's into a single directory (each VPK has its own manifest file tied to its level name), and rebuild all the VPK's with only the files that where originally in them.
fs_pack_vpk command usage: <locale> <context> <level_name> <manifest_only>
locale determines the pak language (default english), context determines whether is a server/client vpk, level_name determines the BSP name of the pak, manifest_only determines whether the pack system should only include files within the manifest (leaving this arg out will build all files into the vpk).
The VPK workspace path is determined with ConVar 'fs_packedstore_workspace'.
2022-06-04 01:08:23 +02:00
2023-05-29 21:41:17 +02:00
CUtlString FormatEntryPath ( const CUtlString & filePath , const CUtlString & fileName , const CUtlString & fileExt ) const ;
void BuildManifest ( const CUtlVector < VPKEntryBlock_t > & entryBlocks , const CUtlString & workspacePath , const CUtlString & manifestName ) const ;
Proper VPK repacking
Initial proper implementation pending cleanup.
The new system builds a manifest file when a VPK is unpacked. The manifest files contains data such as the entry flags and texture flags. It also contains a field determining whether the file should be compressed or not.
When a user repacks a pack, the system attempts to load this manifest file and does a lookup to the object to retrieve the flags (most of these flags are unknown, but they are used by the engine and are necessary for stuff like cubemaps and texture files to work correctly. Cubemaps won't work with proper flags, and textures (decals, particle system components, etc..) will look washed out without them.
I think some also determine whether a file within the VPK should be cached or not, so simply marking everything as 0x101 will probably end up in more CPU time and higher filesystem cache usage (depot/ is only 0x1, I don't think anything there is getting cached ever without the 0x100 flag).
User could also repack a VPK while excluding anything that is not in the manifest file. So you could unpack all VPK's into a single directory (each VPK has its own manifest file tied to its level name), and rebuild all the VPK's with only the files that where originally in them.
fs_pack_vpk command usage: <locale> <context> <level_name> <manifest_only>
locale determines the pak language (default english), context determines whether is a server/client vpk, level_name determines the BSP name of the pak, manifest_only determines whether the pack system should only include files within the manifest (leaving this arg out will build all files into the vpk).
The VPK workspace path is determined with ConVar 'fs_packedstore_workspace'.
2022-06-04 01:08:23 +02:00
2023-05-29 21:41:17 +02:00
void ValidateCRC32PostDecomp ( const CUtlString & assetPath , const uint32_t nFileCRC ) ;
2023-04-03 22:46:10 +02:00
bool Deduplicate ( const uint8_t * pEntryBuffer , VPKChunkDescriptor_t & descriptor , const size_t chunkIndex ) ;
2023-05-29 21:41:17 +02:00
bool ShouldPrune ( const CUtlString & filePath , CUtlVector < CUtlString > & ignoreList ) const ;
void PackWorkspace ( const VPKPair_t & vpkPair , const char * workspaceName , const char * buildPath ) ;
void UnpackWorkspace ( const VPKDir_t & vpkDir , const char * workspaceName = " " ) ;
2022-06-06 14:54:22 +02:00
private :
2023-05-29 21:41:17 +02:00
lzham_compress_params m_lzCompParams ; // LZham compression parameters.
lzham_decompress_params m_lzDecompParams ; // LZham decompression parameters.
std : : unordered_map < string , const VPKChunkDescriptor_t & > m_ChunkHashMap ;
2021-12-25 22:36:38 +01:00
} ;
///////////////////////////////////////////////////////////////////////////////
extern CPackedStore * g_pPackedStore ;
2022-10-12 23:39:26 +02:00
# endif // PACKEDSTORE_H