ah, this can explain a problem that occured today. we tried to play
BR-SlaughterHouse and I thought the server crashed because of the big loading
time. Well, I restarted the server and played DM :) but I never thought about
the server's map-load-time...

Yep, I've got the same problem. BR-Slaughterhouse took almost five minutes to
load on my box. There's no hard drive activity for the vast majority of this
time, but the game eats up 99% of the CPU. Thankfully, it doesn't lock anything
up. I was able to switch to a console and check "top".

I too see much longer load times, but only on the 32-bit build.  The 64-bit
build still takes about the same amount of time.  It is worthy to note that
previously the 64-bit build was 30-40% slower at loading than the 32-bit build.

 The difference in load times is quite dramatic. I killed the process at the
first few attempts to join online . It appeared as though the 'establishing
connection' timed out had not the 'instant action' been having the same result.

This delay makes online playing almost impossible. It takes more than five
minutes to change a map with an patched linux server. That causes the server to
be empty for a few minutes after a mapchange.
For linux clients it seems even worse, since windows players get on about 1.5
minutes earlier (like after 6.5 instead of 8).

This delay seems to also affect the player handling. When I played online
yesterday I stopped ut2004, because it took so long to load, I restarted it and
loged in to the server again, which was faster (2 instead of 5 minutes).

But I got the default name (Player) since a relic of my previous connect was
still left on that server and blocked my name. After about two more minutes this
relic quit (that was, when I noticed it)
 

This is may be way off base, but I found the coincidence kind of creepy, so I'll
post this anyway.  The UT2004 port of MonkeyMatrixMoves (written by MonkeyCircus
and myself) when run online UNDER V3204 (ie patch #1) creates VERY similar
symptoms server-side to this bug, ie wickedly long mapchanges where the
processor spikes to 99.9% CPU usage for minutes at a time.

This all started when we added a feature that spawned gradually fading pawn
animation frames to make a "blur" effect on all pawns...  Each of these frames
is spawned as a separate actor that gets "destroyed" upon full fade out...  We
thought that a "destroyed" actor would get garbage collected mid-game, but all
this effort during a mapchange suggests otherwise...  Perhaps so many actors are
spawned that garbage collection takes forever?  Perhaps the destroy function is
broken in some way?  Or garbage collection in general?

As I said, take this with a BIG grain of salt here, as this is quite possibly
just coincidence...  My symptoms occurred with an invasive mutator on a v3204,
NOT V3236, linux server.  But just in case I hope this helps you, Ryan...  

Hello

Just wanna confirm. No problem here with gentoo 64bit on amd64.
BR-Slaughterhouse loading time around 12 seconds.

regards
Thomas

Slackware 9.0, 2.4.26 kernel, 1Gb RAM, 2.4Ghz AMD XP CPU. 
 
Yes. Affecting me too. I've gone back to the 3204 version also as 3236 is 
basically unusable both online and off. 
 
My experience is "disk activity, long pause, disk activity". 
 
 

Try this new build:

  http://0day.icculus.org/ut2004/ut2004-lnxpatch3236-1.tar.bz2

--ryan.

This new build appears to have resolved all these issues for me; tested it out 
for several hours online yesterday and no problems to report so far. Thanks 
icculus! 

Yay. This build also fixed the lack of lit-up lights on vehicles for me.