Quote:
Originally Posted by Joe Forster/STA
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. |
Huh I think I actually understood that, I'll try re-downloading the tools to see if the original source is the issue (outdated or an unstable version as I don't quite remember what version either were, and I didn't document this), it's still a puzzle to me why I was unsuccessful and you were, but I suppose sometimes shit breaks for reasons we cannot fathom, thank you for the explanation!