I've found that the x86_64 UT2004 client crashes during every map change. Reproducible: Always Steps to Reproduce: 1.emerge ut2004 2.play ut2004 in multiplayer 3.switch maps (the easiest way to induce this is a 1v1 with a 1 kill limit) Actual Results: UT2004 hangs during map at rotation. Expected Results: More killing in a different place? PLZ? I found that the x86 version (file -L says: /opt/ut2004/System/ut2004-bin: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped) does not produce this error. During map change it does not hang, and game moves on to next map in rotation as expected. Steps to fix was copy over the 32 bit executable, and then link to the proper libraries in /usr/lib32... I found only openal.so and libSDL had to be linked in order for the game to run as expected. I felt this was a gentoo bug for one reason: I'm capable of installing the game with portage, and unfortunately, I wasn't able to use portage to force using the 32 bit game client. There should be a way to do this, most relevently, with useflags.
UT2004 can easily be made unstable by changes to its config files, so rename ~/.ut2004 and retry. If that doesn't help, attach ~/.ut2004/System/UT2004.log
Created attachment 114297 [details] ut2004.ini (In reply to comment #1) > UT2004 can easily be made unstable by changes to its config files, so rename > ~/.ut2004 and retry. If that doesn't help, attach ~/.ut2004/System/UT2004.log > Well, I haven't manually edited the config at all. I've simply been using the menu... and none of the graphical options SHOULD effect the ability to switch between maps when you're serving. I can play on remote servers just fine, but I cannot play on my own server. As for the log... give me a minute or two... I'll have to set it back to 64 bit, and link openal and libsdl correctly again. One minute... here's my config, though.
Created attachment 114298 [details] ut2004.log Looking at it myself, it would seem that it blows up trying to reregister with gamespy?
(In reply to comment #2) > I haven't manually edited the config at all. I didn't ask you that. Just rename the directory and retry. It's a very quick and useful check.
Created attachment 114299 [details] NEW log file. (In reply to comment #4) > (In reply to comment #2) > > I haven't manually edited the config at all. > > I didn't ask you that. Just rename the directory and retry. It's a very quick > and useful check. > That came off very rude, but I'm going to hold my tongue. game still very much so crashes, out of the box settings.
OK. I need you to test this with the built-in libraries and *not* ones form your system. We do not support users using libraries that did not ship with the game. If this problem still occurs with the default config and the default libraries, then please REOPEN this bug.
Perhaps you misread, sir. I play the game with the default install and default setup. I emerge ut2004 and that's it. I don't go any further than that. What I found worked and got ut2004 working is to use the 32 bit version of ut2004. The 64 bit client exhibiting the bug is using the libraries delivered with the executable, the 32 bit client uses libraries found in /usr/lib32. Oddly enough, the one using libraries not shipped with the executable works better.
When using the 32-bit client, you should also be using the 32-bit libraries that ship with the game. That was my whole point. If you're using any lib{SDL,openal}.so outside of /opt/ut2004, then you'll need to make it work with the built-in libraries. I don't care to try to troubleshoot problems with libraries not shipped with the game.
(In reply to comment #8) > When using the 32-bit client, you should also be using the 32-bit libraries > that ship with the game. That was my whole point. If you're using any > lib{SDL,openal}.so outside of /opt/ut2004, then you'll need to make it work > with the built-in libraries. I don't care to try to troubleshoot problems with > libraries not shipped with the game. > You really aren't getting the point of this bug, sir. The point is, the AMD64 version that merges when I "emerge ut2004" does not work correctly. When I serve a game at home and I'm playing in the same client, on map change the game crashes. I can play on remote servers without crashing during a map change, only when I'm serving does this occur. The 32 bit libraries and executable I'm using only stands to prove that the bug is isolated to the 64 bit client. The point of this bug, sir, was to propose an easy way of allowing the user to decide whether they want the 32 bit or 64 bit client or not. I rather enjoy using 64 bit gentoo, I have less problems with it, but I don't want 64 bit UT2004, and I can improvise around it, but others will undoubtedly encounter this, and be unable to EASILY change it using portage because we don't offer the option,and I believe we should.
Anyway, if you guys would LIKE me to test with the distributed 32 bit binary libraries that came with the game, I could. But is it really neccessary when it's completely unrelated to the bug filed? The point is, I would like to see the ability to select which build I want, 32 bit or 64 bit, I'd even possibly work with the ebuild a bit, but it's a bit over my head, I could do it, it's just a lot of work when I know it would be a lot easier for the maintainer himself to do it. Being able to select the 32 bit version of UT2004 over the 64 bit version is advantageous, and my reason for this is the bug exhibited when switching maps. The game crashes regularly and is unstable, and it may be lazy of me to want to be able to just merge it, but darnit, that's the gentoo way, isn't it? Configure-ability, speed, and I'd hope to god stability, yes?
See the ebuilds in bug #159164. Stop ranting. Funnily enough, there is now a precedent for using the native libs, because the *Midway* UT2004 DVDs don't contain any Linux files (despite having a penguin on the DVD cover). However, this is the *first* time I've heard the request to use 32-bit libs under amd64. Untold thousands of other users don't need that. Isn't Google such a wonderful tool: http://www.unrealadmin.org/server_ini_reference/ut2004 http://www.unrealadmin.org/forums/showthread.php?t=10130
(In reply to comment #11) > See the ebuilds in bug #159164. Stop ranting. > > Funnily enough, there is now a precedent for using the native libs, because the > *Midway* UT2004 DVDs don't contain any Linux files (despite having a penguin on > the DVD cover). > > However, this is the *first* time I've heard the request to use 32-bit libs > under amd64. Untold thousands of other users don't need that. > > Isn't Google such a wonderful tool: > http://www.unrealadmin.org/server_ini_reference/ut2004 > http://www.unrealadmin.org/forums/showthread.php?t=10130 > I wasn't so much concerned with using the 32 bit libs, as I was the 32 bit client. The client only requires the 32 bit libs since it doesn't know what to make of the 64 bit libs.I'll see if the two links provide anything useful tommorrow, but the smart assery is unneccesary.
OK. You want a way to select a 32-bit install on a 64-bit machine. Here's my simple answer. No. I have no intentions on putting forth the work to do so and really don't feel it is advantageous for me to spend time on it. You can try using: ABI="x86" ACCEPT_KEYWORDS="-* x86" emerge ut2004 If that doesn't work, I'm honestly not interested in "fixing" it, since the problem seems to be solely on your installation. I cannot duplicate this on multiple AMD64 machines.
Portage 2.1.2.2 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r5 x86_64) ================================================================= System uname: 2.6.19-gentoo-r5 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ Gentoo Base System release 1.12.9 Timestamp of tree: Mon, 26 Mar 2007 23:00:08 +0000 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl alsa amd64 avi beagle berkdb bitmap-fonts cdr cli cracklib crypt dbus dri dvd dvdr firefox flac fortran gdbm glitz gnome gpm gtk gtk2 hal iconv ipv6 isdnlog jpeg jpg libg++ mad midi mp3 ncurses nls nptl nptlonly ogg pam pcre perl png ppds pppd python readline reflection session smp spell spl ssl svg tcpd theora threads truetype truetype-fonts type1-fonts unicode vorbis xorg zlib" ALSA_CARDS="intel8x0 emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse joystick evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIRC_DEVICES="livedrive_midi" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY Well then, if you can't reproduce it, then maybe it's a use flag or some other thing I've set that I shouldn't be setting?
WONTFIX means just that. Don't reopen this, please. There are no USE flags that affect ut2004, other than it's installation (dedicated/opengl). I would suggest checking your logs (they're in .ut2004) and reporting the problem upstream if you're having further difficulty.
