[ut2004] 64 bit client problems with downloads

Tom Emerson osnut at pacbell.net
Sun Nov 21 05:34:10 EST 2004

Moments ago I wrote:
> I'm thinking the next thing to check would be a comparison of the actual
> files received via each method [...]

but after I sent this, I realized I didn't need to see the entire file to 
determine why the files are different sizes [and as someone else pointed out, 
bugs are obvious once uncovered...]

The first file received starts out like this:

H202 at f"221371%^^374267277377313372273245337/375fii351ni351257370337337]Z372207377373357245

and the second like this:

Deco^@^P^@^G^@  LightHue^@^P^@^G^@^PLightSaturation^@^P^@^G^@^FLight^@^P^@^G^@  

[these are copy/pastes from a "less" command, so some of these are actually 
control characters or have a "high bit" set]

It *appears* that the file sent from the "redirect" server is indeed 
compressed, while the file from the hosting server is being sent in 
uncompressed form [or else the "receive" routine is decompressing-on-the-fly 
and writing that to the Cache####.tmp file] and given what I see even from 
this small snippet, I can certainly understand why the "uncompressed" form 
would be several times larger :)

Presuming for the moment that the server is really sending the whole file 
"decompressed", would this actually be Atari's "bug"?  (since, presumably, 
even "windows" based servers would exhibit this behavior)  Or is it the case 
that "everyone" actually uses a linux server for "hosting" games, so nobody 
really knows if this happens "from a windows server" or not?  [OK, it must be 
getting late if I'm starting to ask silly questions like that...]

OTOH, if the client is decompressing-on-the-fly, and it is SUPPOSED to be 
doing that, then this might explain why the program restarts the download 
from the hosting server: the first file would appear to be "corrupt", so the 
client retries ...  [just a thought...]

More information about the ut2004 mailing list