Quote:
Originally Posted by L33THAK0R
did you have any difficulties extracting PAK 0?
|
No difficulties here (GOG v33909) but I think I know what's wrong with UnrealPak: it handles file offsets and sizes as
signed 32-bit (maximum of 2 GB) values.
When you extract files from PAK 0 (2967 MB), you get a line for each file like this:
Code:
LogPakFile: Display: Extracted "Engine/Content/EditorBlueprintResources/StandardMacros.uasset" to ".../Engine/Content/EditorBlueprintResources/StandardMacros.uasset" Offset 0.
And often offsets are negative numbers.
When extracting from PAK 1 (9128 MB), offsets obviously start from 0, go upwards to 2 GB, then switch to -2 GB and continue going upwards. This would suggest that files extracted from most of PAK 1 - above 4 GB - may be damaged - because they have been extracted from the wrong part of the PAK - but that's not the case: they don't seem to be damaged and you couldn't decompress damaged ZLib streams anyway without noticing. So, probably, only the display of file offsets is wrong but I can't tell as there's no source code: you can download the "source code" from GitHub but that's just another copy of the binaries. (?!)
PAK 0 is the only one whose size is between 2 GB (maximum of 32-bit signed integer) and 4 GB (32-bit unsigned integer); this may be why you're experiencing this error with it and only it. Look at the error message and you'll see that the file size is negative.
QuickBMS's error message looks similar: it's trying to allocate a negative number of bytes.