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"
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 ;
2021-12-25 22:36:38 +01:00
2022-10-11 15:37:34 +02:00
static const std : : regex BLOCK_REGEX { R " (pak000_([0-9]{3})) " } ;
static const std : : regex DIR_REGEX { R " ((?:.* \ /)?([^_]*_)(.*)(.bsp.pak000_dir).*) " } ;
2022-10-02 19:24:00 +02:00
2022-11-16 00:54:51 +01:00
static const vector < string > DIR_TARGET =
2022-10-02 12:17:03 +02:00
{
" server " ,
" client "
} ;
static const vector < string > DIR_LOCALE =
{
" 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 ) ;
string m_svEntryPath ;
uint16_t m_iPreloadSize ;
uint32_t m_nLoadFlags ;
uint16_t m_nTextureFlags ;
bool m_bUseCompression ;
bool m_bUseDataSharing ;
VPKKeyValues_t ( const string & svEntryPath = " " , uint16_t iPreloadSize = NULL , uint32_t nLoadFlags = LOAD_FLAGS_DEFAULT ,
uint16_t nTextureFlags = TEXTURE_FLAGS_DEFAULT , bool bUseCompression = true , bool bUseDataSharing = 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
bool m_bIsCompressed = false ;
2022-06-06 14:54:22 +02:00
VPKChunkDescriptor_t ( ) { } ;
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
{
2022-10-12 23:39:26 +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.
2022-11-16 00:54:51 +01:00
vector < VPKChunkDescriptor_t > m_vFragments ; // 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).
2022-10-12 23:39:26 +02:00
string m_svEntryPath ; // Path to entry within vpk.
2022-06-06 14:54:22 +02:00
2022-11-23 14:49:40 +01:00
VPKEntryBlock_t ( FileHandle_t pFile , const string & svEntryPath ) ;
2022-11-23 17:09:48 +01:00
VPKEntryBlock_t ( const uint8_t * pData , size_t nLen , int64_t nOffset , uint16_t iPreloadSize ,
uint16_t iPackFileIndex , uint32_t nLoadFlags , uint16_t nTextureFlags , const string & svEntryPath ) ;
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
{
string m_svPackName ;
string m_svDirectoryName ;
VPKPair_t ( string svLanguage , string svTarget , const string & svLevel , int nPatch ) ;
} ;
2022-05-30 02:56:15 +02:00
struct VPKDir_t
{
2022-10-12 23:39:26 +02:00
VPKDirHeader_t m_vHeader ; // Dir header.
vector < VPKEntryBlock_t > m_vEntryBlocks ; // Vector of entry blocks.
2022-11-16 00:54:51 +01:00
uint16_t m_nPackFileCount ; // Number of pack patches (pack file count-1).
vector < string > m_vPackFile ; // Vector of pack file names.
2022-11-23 17:09:48 +01:00
string m_svDirectoryPath ; // Path to vpk_dir file.
2021-12-25 22:36:38 +01:00
2022-11-23 17:09:48 +01:00
VPKDir_t ( )
{
m_vHeader . m_nHeaderMarker = VPK_HEADER_MARKER ; m_vHeader . m_nMajorVersion = VPK_MAJOR_VERSION ;
m_vHeader . m_nMinorVersion = VPK_MINOR_VERSION ; m_vHeader . m_nDirectorySize = NULL , m_vHeader . m_nSignatureSize = NULL ;
} ;
VPKDir_t ( const string & svDirectoryFile ) ;
VPKDir_t ( const string & svDirectoryFile , bool bSanitizeName ) ;
2022-05-30 02:56:15 +02:00
2022-11-23 17:09:48 +01:00
void Init ( const string & svPath ) ;
string StripLocalePrefix ( const string & svDirectoryFile ) const ;
string GetPackFile ( const string & svDirectoryPath , uint16_t iPackFileIndex ) const ;
void WriteHeader ( FileHandle_t hDirectoryFile ) const ;
void WriteTreeSize ( FileHandle_t hDirectoryFile ) const ;
uint64_t WriteDescriptor ( FileHandle_t hDirectoryFile , std : : map < string , std : : map < string , std : : list < VPKEntryBlock_t > > > & vMap ) const ;
2022-11-23 12:27:57 +01:00
void BuildDirectoryTree ( const vector < VPKEntryBlock_t > & vEntryBlocks , std : : map < string , std : : map < string , std : : list < VPKEntryBlock_t > > > & vMap ) const ;
void BuildDirectoryFile ( const string & svDirectoryFile , const vector < VPKEntryBlock_t > & vEntryBlocks ) ;
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
2022-11-23 17:09:48 +01:00
vector < VPKEntryBlock_t > GetEntryBlocks ( FileHandle_t hDirectoryFile ) const ;
vector < VPKKeyValues_t > GetEntryValues ( const string & svWorkspace ) const ;
vector < VPKKeyValues_t > GetEntryValues ( const string & svWorkspace , KeyValues * pManifestKeyValues ) const ;
2022-06-06 14:54:22 +02:00
2022-06-05 17:28:39 +02:00
string GetNameParts ( const string & svDirectoryName , int nCaptureGroup ) const ;
2022-11-16 00:54:51 +01:00
string GetLevelName ( const string & svDirectoryName ) const ;
2022-06-06 23:08:53 +02:00
2022-11-23 12:18:33 +01:00
KeyValues * GetManifest ( const string & svWorkspace , const string & svManifestName ) const ;
2022-11-16 00:54:51 +01:00
vector < string > GetIgnoreList ( const string & svWorkspace ) 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
2022-11-23 17:09:48 +01:00
string FormatEntryPath ( const string & svPath , const string & svName , const string & svExtension ) 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
2022-11-23 17:09:48 +01:00
void BuildManifest ( const vector < VPKEntryBlock_t > & vBlock , const string & svWorkspace , const string & svManifestName ) 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
2022-11-16 00:54:51 +01:00
void PackWorkspace ( const VPKPair_t & vPair , const string & svWorkspace , const string & svBuildPath , bool bManifestOnly ) ;
2022-11-23 17:09:48 +01:00
void UnpackWorkspace ( const VPKDir_t & vDirectory , const string & svWorkspace = " " ) ;
2022-12-04 01:33:10 +01:00
void ValidateCRC32PostDecomp ( const string & svAssetPath , const uint32_t nFileCRC ) ;
2022-06-06 14:54:22 +02:00
private :
2022-11-17 20:37:12 +01:00
size_t m_nChunkCount ; // The number of fragments for this asset.
2022-11-16 00:54:51 +01:00
lzham_compress_params m_lzCompParams ; // LZham decompression parameters.
lzham_compress_status_t m_lzCompStatus ; // LZham compression status.
lzham_decompress_params m_lzDecompParams ; // LZham decompression parameters.
lzham_decompress_status_t m_lzDecompStatus ; // LZham decompression status.
std : : unordered_map < string , VPKChunkDescriptor_t & > m_mChunkHashMap ;
2021-12-25 22:36:38 +01:00
} ;
///////////////////////////////////////////////////////////////////////////////
extern CPackedStore * g_pPackedStore ;
2022-10-12 23:39:26 +02:00
# endif // PACKEDSTORE_H