2021-12-25 22:36:38 +01:00
# pragma once
2022-08-09 17:18:07 +02:00
# include "public/utility/binstream.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 ;
2021-12-25 22:36:38 +01:00
2022-10-02 19:24:00 +02:00
static const std : : regex BLOCK_REGEX { R " ((?:.* \ /)?([^_]*_)(.*)(.bsp.pak000_dir).*) " } ;
2022-10-02 12:17:03 +02:00
static const vector < string > DIR_CONTEXT =
{
" 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-06-06 14:54:22 +02:00
enum class EPackedLoadFlags : int
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
LOAD_NONE ,
LOAD_VISIBLE = 1 < < 0 , // FileSystem visibility?
LOAD_CACHE = 1 < < 8 , // Only set for assets not stored in the depot directory.
LOAD_TEXTURE_UNK0 = 1 < < 18 ,
LOAD_TEXTURE_UNK1 = 1 < < 19 ,
LOAD_TEXTURE_UNK2 = 1 < < 20 ,
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
} ;
enum class EPackedTextureFlags : short
{
TEXTURE_NONE ,
TEXTURE_DEFAULT = 1 < < 3 ,
TEXTURE_ENVIRONMENT_MAP = 1 < < 10 ,
} ;
2021-12-25 22:36:38 +01:00
2022-08-06 00:16:11 +02:00
struct FileHandleTracker_t
{
int m_nFileNumber ;
int m_nCurOfs ;
HANDLE m_hFileHandle ;
} ;
struct pFileHandleTracker_t
{
FileHandleTracker_t self [ 1024 ] ;
} ;
2022-04-09 00:59:42 +02:00
# pragma pack(push, 1)
struct VPKFileEntry_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
char * m_pszDirectory ;
char * m_pszFileName ;
char * m_pszExtension ;
2022-04-09 00:59:42 +02:00
uint8_t unknown [ 0x38 ] ;
} ;
struct VPKData_t
{
2022-06-05 12:28:49 +02:00
int m_nHandle ;
char pad [ 1 ] ;
char m_szPath [ 255 ] ;
uint8_t unknown2 [ 0x134 ] ;
int32_t m_nEntries ;
uint8_t unknown3 [ 12 ] ;
2022-04-09 00:59:42 +02:00
VPKFileEntry_t * m_pEntries ;
} ;
# pragma pack(pop)
2022-06-06 14:54:22 +02:00
struct VPKChunkDescriptor_t
2021-12-25 22:36:38 +01:00
{
2022-06-06 14:54:22 +02:00
uint32_t m_nLoadFlags { } ; // Load flags.
2021-12-25 22:36:38 +01:00
uint16_t m_nTextureFlags { } ; // Texture flags (only used if the entry is a vtf).
uint64_t m_nArchiveOffset { } ; // Offset in archive.
2022-06-06 14:54:22 +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 ( ) { } ;
VPKChunkDescriptor_t ( CIOStream * pReader ) ;
VPKChunkDescriptor_t ( uint32_t nEntryFlags , uint16_t nTextureFlags , uint64_t nArchiveOffset , 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-06-06 14:54:22 +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.
vector < VPKChunkDescriptor_t > m_vChunks { } ; // 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).
string m_svEntryPath { } ; // Path to entry within vpk.
VPKEntryBlock_t ( CIOStream * pReader , string svEntryPath ) ;
VPKEntryBlock_t ( const vector < uint8_t > & vData , int64_t nOffset , uint16_t nPreloadData , uint16_t nArchiveIndex , uint32_t nEntryFlags , 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
{
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
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
} ;
struct VPKDir_t
{
2022-06-06 14:54:22 +02:00
VPKDirHeader_t m_vHeader { } ; // Dir header.
uint32_t m_nFileDataSize { } ; // File data section size.
vector < VPKEntryBlock_t > m_vEntryBlocks { } ; // Vector of entry blocks.
uint16_t m_iPackFileCount { } ; // Highest archive index (archive count-1).
vector < string > m_vPackFile { } ; // Vector of archive file names.
string m_svDirPath { } ; // Path to vpk_dir file.
2021-12-25 22:36:38 +01:00
2022-05-30 02:56:15 +02:00
VPKDir_t ( const string & svPath ) ;
2022-06-05 17:28:39 +02:00
VPKDir_t ( ) { m_vHeader . m_nHeaderMarker = VPK_HEADER_MARKER ; m_vHeader . m_nMajorVersion = VPK_MAJOR_VERSION ; m_vHeader . m_nMinorVersion = VPK_MINOR_VERSION ; } ;
2022-05-30 02:56:15 +02: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
void Build ( const string & svDirectoryFile , const vector < VPKEntryBlock_t > & vEntryBlocks ) ;
} ;
struct VPKPair_t
{
2022-10-09 12:08:54 +02:00
string m_svBlockName ; // !TODO: Multi-pak support.
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
string m_svDirectoryName ;
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-06-06 14:54:22 +02:00
VPKDir_t GetDirectoryFile ( string svDirectoryFile ) const ;
string GetPackFile ( const string & svPackDirFile , uint16_t iArchiveIndex ) const ;
2022-09-11 00:16:31 +02:00
lzham_compress_level GetCompressionLevel ( void ) const ;
2022-06-06 14:54:22 +02:00
vector < VPKEntryBlock_t > GetEntryBlocks ( CIOStream * pReader ) const ;
vector < string > GetEntryPaths ( const string & svPathIn ) const ;
vector < string > GetEntryPaths ( const string & svPathIn , const nlohmann : : json & jManifest ) const ;
2022-06-05 17:28:39 +02:00
string GetNameParts ( const string & svDirectoryName , int nCaptureGroup ) const ;
string GetSourceName ( const string & svDirectoryName ) const ;
2022-06-06 23:08:53 +02:00
2022-06-04 01:30:18 +02:00
nlohmann : : json GetManifest ( const string & svWorkSpace , const string & svManifestName ) const ;
2022-06-06 23:08:53 +02: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-06-06 14:54:22 +02:00
string FormatEntryPath ( string svName , const string & svPath , const string & svExtension ) const ;
string StripLocalePrefix ( const string & svDirectoryFile ) 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
VPKPair_t BuildFileName ( string svLanguage , string svContext , const string & svPakName , int nPatch ) const ;
void BuildManifest ( const vector < VPKEntryBlock_t > & vBlock , const string & svWorkSpace , const string & svManifestName ) const ;
void PackAll ( const VPKPair_t & vPair , const string & svPathIn , const string & svPathOut , bool bManifestOnly ) ;
2022-06-06 14:54:22 +02:00
void UnpackAll ( const VPKDir_t & vDir , const string & svPathOut = " " ) ;
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-02 01:57:18 +02:00
void ValidateAdler32PostDecomp ( const string & svDirAsset ) ;
void ValidateCRC32PostDecomp ( const string & svDirAsset ) ;
2022-06-06 14:54:22 +02:00
private :
size_t m_nChunkCount { } ; // Entry per-block incrementor.
lzham_uint32 m_nAdler32_Internal { } ; // Internal operation Adler32 file checksum.
lzham_uint32 m_nAdler32 { } ; // Pre/post operation Adler32 file checksum.
lzham_uint32 m_nCrc32_Internal { } ; // Internal operation Crc32 file checksum.
lzham_uint32 m_nCrc32 { } ; // Pre/post operation Crc32 file checksum.
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.
2022-10-02 19:24:00 +02:00
std : : unordered_map < string , VPKChunkDescriptor_t & > m_mChunkHashMap { } ;
2021-12-25 22:36:38 +01:00
} ;
///////////////////////////////////////////////////////////////////////////////
extern CPackedStore * g_pPackedStore ;