[ut2004] 64 bit client problems with downloads

[Paul]

On Sun, 2004-11-21 at 02:34 -0800, Tom Emerson wrote:
> 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...]

I ususally in the past have seen the file retrieval go twice because the
version of the file on the redirect is different than the version on the
game server.

> 
> The first file received starts out like this:
> 
> 202UEI264X244314bI255271370340213303?302'207200^O{w370g370344^H^_}
> 3603157207^A"A^Bd346364241U
> H202 at f"221371%^^374267277377313372273245337/375fii351ni351257370337337]Z372207377373357245
> 345277377345377{351261363247?375347\375343_^L336^V377374?377365ESC250#352257|
> 314263xiymy
> 355s<)363242372275234247i2O362354}
> 234334?224K373KkK^Mq^PM223ż"n234$3632312&qUZ>315246Տ255"216
> &^Ogit/253255^N˨220315254^M342{336F365
> {367346341u236L346237363t1203&Fѽ370261274}223'Y251U^371
> 
> 
> and the second like this:
> 
> 301203*236^@^]^@^A^@^@^@f^P^@^@@^@^@^@303^N^@^@210376354^@262^@^@^@246367354^@kAP266266341333
> M212^^R^Tr244360344^A^@^@^@303^N^@^@f^P^@^@^ENone^@^P^D^G^D^GVector^@^P^D^G^D^PCollisionHeight
> ^@^P^@^G^@^PCollisionRadius^@^P^@^G^@   
> Distance^@^P^@^G^@^DEnd^@^P^@^G^@^KreachFlags^@^P^@^G
> ^@^FStart^@^P^@^G^@^GRegion^@^P^@^G^@^NPhysicsVolume^@^P^@^G^@^DTag^@^P^@^G^D^LPointRegion^@^P
> ^@^G^@^EZone^@^P^@^G^@^FLevel^@^P^@^G^@^FiLeaf^@^P^@^G^@^KZoneNumber^@^P^@^G^@  
> Location^@^P^@
> ^G^@^HRotator^@^P^D^G^D 
> Rotation^@^P^@^G^@^LColLocation^@^P^@^G^@^SStaticMeshInstance^@^P^@^G
> ^@^KStaticMesh^@^P^@^G^@^PStaticMeshActor^@^P^@^G^@^MCullDistance^@^P^@^G^@^LDrawScale3D^@^P^@
> ^G^@^FGroup^@^P^@^G^@^TnextNavigationPoint^@^P^@^G^@    
> PathList^@^P^@^G^@^EBase^@^P^@^G^@^FSc
> ale^@^P^@^G^@^LbShadowCast^@^P^@^G^@^MRoadPathNode^@^P^@^G^@^LSoundVolume^@^P^@^G^@^NNone,Core
> Deco^@^P^@^G^@  LightHue^@^P^@^G^@^PLightSaturation^@^P^@^G^@^FLight^@^P^@^G^@  
> Material^@^P^@
> ^G^@
<SNIP>
> 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...]

Yes the client does decompress it before it stores it in the cache
directory from what I remember

Regards,
Paul Berger