Username:
B
I
U
S
"
url
img
#
code
sup
sub
font
size
color
smiley
embarassed
thumbsup
happy
Huh?
Angry
Roll Eyes
Undecided
Lips Sealed
Kiss
Cry
Grin
Wink
Tongue
Shocked
Cheesy
Smiley
Sad
1 page
--
--
List results:
Search options:
Use \ before commas in usernames
myk
2006-08-28 11:48:07 am
I've been watching some Quake marathons historically, and some of the older ones (e4_1703, among a few others, not that they are many) didn't seem to decompress right.

I'm using the console version of dzip v2.9. When I undzip the DZs they seem to go fine, but then the demos won't play. And looking into the PAK with a pak-reading browser I see rubbish instead of the list of demo names dzip told me it decompressed.

I haven't tried the GUI version of dzip or any older version yet, but still, if this is a glitch it might be worth looking into.

e4_1703.dz is 705,860 bytes in size on my HDD and that seems reasonable compared to other similar dzips, so it doesn't seem to be missing anything. I've tried redownloading the files just in case but the results didn't change.
Thread title:  
aguirRe
2006-08-29 12:00:31 am
In e4_1703, the pak file is corrupt (the dzip archive seems OK). If you change the fifth byte from C3 to B0, it'll work again.
Radix
Radix
Edit history:
Radix: 2006-08-29 01:25:29 am
2006-08-29 01:23:47 am
I'm addicted to games
Couple problems at work here...
It seems the original e4_1703 pak file was 19 bytes too big. When dzip compresses a pak file, any such "extra bytes" disappear because they're not important to a pak file. But it doesn't make note of that and reduce the size of the file in the dz directory. When it extracts the pak it sets the offset to the pak directory at the beginning to the expected total file size - 64 * numfiles. Then when it writes all the files it puts the directory. But because of the missing bytes, the directory is in the wrong place. If you try to open the pak you get with dzip it'll say invalid pak because the directory points past the end of the file.

A bigger problem comes up if you extract the pak the way I was ... drag and drop it onto the desktop. I tell windows the file size to expect in that case. When the file it gets in temp is a few bytes short, windows decides that must not really have been the file I wanted to extract, and expands the size by 19 bytes (of garbage). When you try to open THAT pak file with Dzip, it crashes. I fixed the crash by ignoring bad file names in the gui and checking for bad file names in the pak loader. Maybe one of these days I'll release a new version.

Conclusion: I fixed the dz file  Tongue