The maps are downloaded, but it takes an eternity and the count goes up to
several hundred percent

It takes longer than an eternity, and makes the amd64 binaries
totally unsuitable for online play...

*** Bug 1902 has been marked as a duplicate of this bug. ***

Can confirm; I'm seeing this too, looks like the exact same thing.

Unless it's changed dramatically from the UTv1 days, the server is configured to
point clients at a webserver for resource downloads; they'll all be sitting,
gzip'd in one dir. The client will HTTP the needed files from the specified dir,
ungzip, and drop in the cache.

Something is broken on linux/amd64, apparently after the HTTP retrieve step. I
wouldn't be surprised if this bug could be trivially fixed by adjusting a CFLAG
during the build process w.r.t. a compression library dependency, or something. 

This isn't a showstopper, but with the plethora of 3rd-party content now running
out there, it's a surprisingly major drag! 

I'm glad I'm not the only one with this problem ;). Any Ideas on a fix. This is
getting annoying that I can't play on any server that plays a map I don't
already have...

*** Bug 2176 has been marked as a duplicate of this bug. ***

This might be explained by bug #1771.  On my machine, tcpdump shows that the   
compressed file is sent from the redirect server (which is the fast 0 -> 100%   
part you see onscreen), but then the download restarts from the game server   
itself (which is the slow, > 100% part).   
   
Presumably this happens because the compressed file can't be decompressed on   
AMD64 (bug #1771), and the client assumes that the redirect server failed to   
send the file.  The client then gets the uncompressed version of the file from   
the game server, which is why the size goes > 100% of the filesize initially   
reported by the redirect server.   
   
A temporary (but definitely less than optimal) solution is to go into   
ut2004.ini and set InitialConnectTimeout to some large number, then go get a   
sandwich while the files are downloaded over the slow connection from the game   
server.  In this case, also set PurgeCacheDays to some large number, so you   
won't have to re-download before Ryan (name uttered with much respect, awe and   
appreciation for all the work he's put into making ut2004 run so well on Linux)   
has a chance to find and fix the problem.   
 

Setting PurgeCacheDays=0 makes UT2004 never delete any cache file. This might be
better than a large number, if you have plenty of disk space and don't want to
download anything twice - ever.

I can confirm this as well. AMD64/Linux (Gentoo). The binary is fast (25-FPS on
32-bit, 65FPS on 64-bit), but even since the Old Days this bug has annoyed the
hell out of me. 

If it's a library bug why not just have it call gzip or uz2unpack from the
system? Granted, not many systems are going to have uz2unpack on the system, why
not just ship the next patch with it as a 64-bit binary, since only the 64-bit
UT2004 seems to be failing? It already links against an external libSDL.so.0 and
openal.so, so would calling uz2unpack be that much more difficult?

*** Bug 2227 has been marked as a duplicate of this bug. ***

I posted this in another bug.  This is the little bit of research I've done:

I'm seeing this same thing.  It feels as though it is downloading just fine (or
is it?) but when it goes to decompress the newly downloaded file is when it
comes to a halt.  About .01%/second.  I upgraded my CPU to a 3200+ and I saw an
increase in the precentage....a minimal increase.....but an increase
nonetheless.  Which kind of makes me think that it's the processor/binary doing
the decompressing part that is having the problem.  The first precentage (which
goes rather quick) is the download of the compressed map, the second
precentage...the one that can go up to 200+% is the decompressing of the
file....right?  That's what it feels like to me.  

But wait....there's more:
./ucc-bin decompress ~/DLoads/Maps/CTF-FP2-Ages.ut2.uz2 -nohomedir
....the above command works perfectly fine, and decompresses the map in a matter
of seconds.

./ucc-bin-linux-amd64 decompress ~/DLoads/Maps/CTF-FP2-Ages.ut2.uz2 -nohomedir
Error occurred decompressing ~/DLoads/GameStuff/UT2004/Maps/Maps/CTF-FP2-Ages.ut2

History:

Exiting due to error
....obviously the linux 64 binary does not work....strange!



Now onto compression:
./ucc-bin compress ~/DLoads/GameStuff/UT2004/Maps/Maps/CTF-FP2-Ages.ut2 -nohomedir
...compresses the map in a matter of seconds.

./ucc-bin-linux-amd64 compress
~/DLoads/GameStuff/UT2004/Maps/Maps/CTF-FP2-Ages.ut2 -nohomedir
...compresses the map in a matter of seconds.

Strange, both the 32bit and the 64bit can compress the maps, but only the 32bit
can decompress the maps.  Does this have anything to do with anything....or am I
just reaching here?

Here's my system info:
Video: eVGA nVIDIA GeForce 6800 GT Video Card, 256MB PCI-Express
Mobo: GIGABYTE "GA-K8NF-9" NVIDIA nForce4 4X Chipset Motherboard For AMD Socket 939
Proc: AMD Athlon 64 3200+ 939 Socket, 512k L2 Cache Retail Box
Memory: Patriot Signature Series DDR Memory 184-Pin 1GB PC-3200
OS: Ubuntu Warty Warthog 4.10 

Please let me know if there is anything I can do to help, test, whatever....this
is a real annoying bug, and I would like to help out if possible.

"The first precentage (which
goes rather quick) is the download of the compressed map, the second
precentage...the one that can go up to 200+% is the decompressing of the
file....right?"

wrong.  The first % is the compressed map being downloaded from the http
redirect, the second % is the full uncompressed map being downloaded directly
from the game server, but using the compressed file size for the %.  If the
server disables in game map downloads you will instead get an error saying you
can't download the file.  BTW, with UT99 when you downloaded a compressed map
from a redirect it would use the full size for the % and often complete after
only 40-60%.  interesting reversal of bugs :)

I also see that the command line 32 bit comrepesses and decompresses fine and
the 64 bit will only compress.

There is ONE server on which large downloads actually do work for me, the Unreal
Exiles linuxhardware server. I don't know why this works, but does, and it does
consistently.

could they be serving via redirect uncompressed?

I enquired about the server, and they are running it on a dual core amd64
machine, so the server is probably run from 64 bit binaries.

This build...

  http://icculus.org/~icculus/tmp/ut2004-lnx-amd64-05282005.tar.bz2

...fixes the issue.

--ryan.

I affirm the "RESOLVED" status. However, I'll ask one final question. Where did
this fix come from?

If you mean who made the fix, I did; I'm the developer responsible for the
64-bit version.

If you mean what was wrong specifically, we were passing a pointer to a 32-bit
integer to zlib, and forcibly casting it to zlib's "uLongf *" type...uLongf is
64-bits on amd64 platforms, which means we were writing garbage to a variable,
which confused the (de)compression code. Since it was an explicit cast in the
source code, the compiler didn't warn about it. I corrected this, and rebuilt
the game, which is where this version came from.

Did that answer your question?

--ryan.

I replaced my System/ut2004-bin file with this one and the game won't start,
here's the error:

Assertion failed: GetPropertiesSize()>=sizeof(UObject) [File:UnClass.cpp] [Line:
1032]

History:

Exiting due to error

That happens if your game install isn't patched to 3355 before replacing this file.

--ryan.

That answered my question perfectly. Case closed, heh. Thanks!

ddin't know 3355 was out for linux, it's not mentioned on any of the main ut
sites.  I've found it now and am installing, thanks