Jagged Alliance 2

[Post a new comment]
Comments
[Show all 13 comment threads on one page]
[1-10] [11-13] 

	No problem with FC5 posted by Anonymous @ 82.243.116.2 on Mar 31 2006 7:53 AM
The games runs "as is" under Fedora Core 5, no special X11 library or 'export LD_...' required.
[Reply]

	Jagged Alliance 2 posted by basramm @ 80.141.169.200 on Mar 26 2005 8:36 AM
Still a killer!
[Reply]

	Jagged Alliance 2 posted by Kropemann @ 213.135.224.119 on Feb 26 2005 4:29 PM
I hope somebody works on the source-code to keep ja2 playable for many more years
[Reply]

	Its totally awesome, if you can run it. posted by Dou9st3r @ 68.112.96.25 on Aug 11 2004 5:38 PM
I see that this game hasn't been rated so I better get in here and give it a 5-star, even though I can't run it anymore. This is a totally fantastic game which will consume your life for days, weeks, months, ... years. Its a totally violence dripping CAWS buckshot burst to the head explosion of turn based gaming greatness! If you have ever played Fallout, you will probably love this game. It's simply stupendous. It works in a similar manner. You can make your squad move around in realtime, but when an enemy is sighted the game kicks into squad turn mode just like the option in Fallout Tactics. This game is no stand and blast it out toe-to-toe deal like Fallout, however, you will have your mercs scurring for cover behind a tree, rock, bush, or else bull-rushing for a hand to hand quick overwhelming takedown. Assault the enemy with overwhelming firepower by day or through stealth and trickery by night, this game has a lot of playability. And the source code is now out. A linux port would be great! There are a couple of places to go to get in on this right now: Bear's Pit's JA2 Source Code Forum alt.games.jagged-alliance on Usenet Ok, get those compilers fired up and I hope to see some of you JA2 fans soon! I will look into starting a SF project if the license is compatible.
[Reply]
Re: Its totally awesome, if you can run posted by Anonymous @ 205.201.57.57 on Sep 26 2004 10:17 AM   > I will look into starting a SF project if the license is compatible. Looking into doing so (and seeing whether the Bear's Pit folks are interested) might help a good deal in centralizing development and providing a single reliable source for CVS storage. A few notes of appreciation I'd like to make: Strategy First: Thank you very much for the open source release. I can't say how much this means to us -- it means that there is a reliable, maintainable, patchable codebase to work with. Jagged Alliance 2 should be working until Judgement Day. :-) Please, if it all possible, consider continuing to make the Jagged Alliance 2 CD with the datafiles available for purchase (Lucasarts, for instance, has continued to press CDs of their games as long as there is interest). Jagged Alliance 2 represents one of the few commercial-class games that one can buy for Linux which one can obtain source for -- and hence, a continued working game on all distros and systems. Mathieu Pinard (and the other good folk from Tribsoft): Thank you for your work porting Jagged Alliance 2 to Linux. I know that this was a financially risky move -- a bit of a niche game being ported to a niche platform -- but many of us appreciate it very much. I'd consider Jagged Alliance 2 one of the best games for Linux, and one of the most sophisticated games I've played (and I've developed for some of the Angband-class games, so I've seen some sophisticated games ;-) ). I'd *especially* like to thank Mathieu for his offer to try to facilitate a source release of the original Linux port, if folks can convince Strategy First to give an okay to the original Linux release -- but even the release of the Windows source should be enough -- it'll just take a bit longer to re-port. Linux folks hacking on the source release: Thank you (actmodern, Dougster, etc). Your work -- already having a from-scratch port up and running on Linux -- is appreciated and impressive. Linux game fans: Consider purchasing the Wildfire release. I know, it doesn't run on Linux currently, but it's a good bet that it will shortly. It supports Strategy First, and it means that you get a CD copy of the source code. (And, of course, one can always WINE it.) Strategy First has stuck its neck out a bit and done one of the nicest things that a Linux game fan could hope for -- to provide a maintainable copy of the source for their earlier customers. Very few other folks have done this -- the excellent Mr. Carmack has continued with his tradition of helping Linux folks with both driver and older application code, and the folks at Relic have released the Homeworld source, which has allowed for an SDL port. If you do pick up a copy of Wildfire (or if you bought a copy of Jagged Alliance 2), you'd be doing all of us a favor if you'd send Strategy First a nice thank you email, saying that you're a customer and that you appreciate what they've done. In a day and age when many publishing houses don't treat their customers very well, Strategy First has gone quite far beyond what is expected of a publishing house. If they don't receive your feedback, they have no way of knowing whether their actions are appreciated by their customers. All in all, things are turning out rather well. It's much better than the state of things back in February when it took me a extensive binary-level troubleshooting to get things working for myself and others -- and this is thanks to a lot of effort from a number of people. -- Mark Schreiber (mark7@alumni.cmu.edu)   [Reply]

	Problem during the installation posted by Anonymous @ 212.89.162.213 on Apr 28 2004 1:07 AM
During installation i am receiving this message "An I/O error occured while installing a file.This is normally caused by bad installation media or a corrupt installation file.Abort Retry".If i choose "Abort" i am receiving an other message which is says "Corrupt installation file.OK".After pressing "OK" it stops install and rerturns back to Windows.If i choose "Retry" it is trying to continue the installation but it stops and i am receiving the same message again.I have a Pentium 2 with a RIVA TNT2 with 32MB RAM, 32MB RAM and 80GB HD.Please tell me where's the problem located?In the CD-ROM or in my system?Thanks a lot
[Reply]

	Problem during the installation posted by Anonymous @ 212.89.162.213 on Apr 28 2004 1:03 AM
During installation i am receiving this message "An I/O error occured while installing a file.This is normally caused by bad installation media or a corrupt installation file.Abort Retry".If i choose "Abort" i am receiving an other message which is says "Corrupt installation file.OK".After pressing "OK" it stops install and rerturns back to Windows.If i choose "Retry" it is trying to continue the installation but it stops and i am receiving the same message again.I have a Pentium 2 with a RIVA TNT2 with 32MB RAM, 32MB RAM and 80GB HD.Please tell me where's the problem located?In the CD-ROM or in my system?Thanks a lot
[Reply]

	Problem during the installation posted by Anonymous @ 212.89.162.213 on Apr 28 2004 1:00 AM
During installation i am receiving this message "An I/O error occured while installing a file.This is normally caused by bad installation media or a corrupt installation file.Abort Retry".If i choose "Abort" i am receiving an other message which is says "Corrupt installation file.OK".After pressing "OK" it stops install and rerturns back to Windows.If i choose "Retry" it is trying to continue the installation but it stops and i am receiving the same message again.I have a Pentium 2 with a RIVA TNT2 with 32MB RAM, 32MB RAM and 80GB HD.Please tell me where's the problem located?In the CD-ROM or in my system?Thanks a lot
[Reply]

	Where is the patch? posted by Anonymous @ 24.206.121.236 on Apr 17 2004 5:43 PM
I got this game working on Mandrake 10.0 thanks to the help in this forum. However, I have been unable to find the patch anyhwere on google. Any ideas? I wish I would of kept all those files back in the day.
[Reply]

	kernel 2.6.3 segmentation fault still posted by Anonymous @ 62.142.240.72 on Mar 20 2004 9:39 AM
i managed to get this game working at my friend computer who has 2.4 -series kernel. my kernel is 2.6.3 and after export LD_PRELOAD=/usr/local/games/ja2/lib/libX11.so.6.2 export LD_ASSUME_KERNEL=2.4.1 it still gives me segfault my system is almost identical with my friend one (slackware 9.1), kernel version is the main difference. anyone got this working with 2.6 kernel?
[Reply]
Re: kernel 2.6.3 segmentation fault stil posted by Anonymous @ 205.201.7.175 on Apr 2 2004 9:13 AM   I have successfully used this with 2.6.3 Fedora Core 1 (with a few things from Fedora Core 2 and manual changes to make the distro work properly with the 2.6.3 kernel). I didn't do anything special for JA2 -- once the distro itself was working properly with the 2.6 kernel, so did JA2. If you post a stack trace, we might be able to at least tell whether this is the same problem or a different one. Where did you get your old X11 libraries? An old Red Hat or old Slackware distro? Do other SHM and DGA-using applications work okay, like WINE? -- Mark Schreiber (mark7+happypenguin@andrew.cmu.edu)   [Reply]

	Making this game work on modern distros posted by Anonymous @ 205.201.7.175 on Feb 22 2004 5:58 PM
I'm not sure how the "use a new X server" fixed the other user's problems, unless doing so is a fortunate side effect of whatever starting up a new X environment did on the other user's system. I used the following (I suspect minimal) approach to get Jagged Alliance 2 working on Fedora Core 1. Note that there was only about five minutes of testing, so there may be still unknown issues. First, you'll need a somewhat older X11 library. I got this from the Red Hat 8.0 X11 library. On Red Hat, this is part of the XFree86-libs package. Currently, this can be snagged from many places -- the mirror I used is the University of Tenessee mirror here Next, you'll want to extract the libX11 file from the RPM. There's a way to pull this off with a conversion tool and cpio, IIRC (RPMs are slightly differently formatted cpio archives). I simply use aunpack, a neat utility that detects file types automatically, unpacks the file type, and prevents multiple files from being dumped in the root folder -- this thing should really be on every Linux user's system. It's a component of the atool package. The freshmeat entry for the atool package is here. Grab it, install it, and use aunpack: $ aunpack XFree86-libs-4.2.0-72.i386.rpm aunpack will list all the files being unpacked. You want to grab libX11.so.6.2 from the newly-unpacked directory. Note that I'm copying from the newly unpacked usr, not the systemwide /usr. Dump it into your ja2 game directory, wherever it is. By default, if you installed the game as a user, it's in ~/ja2/ -- I put mine in ~/.private/ja2 so that it doesn't take up visible space in my home directory (you can move the ja2 folder post-installation without breaking anything). $ cp usr/X11R6/lib/libX11.so.6.2 ~/.private/ja2/ You can now delete the usr directory containing the unpacked RPM, if you'd like. now cd into the ja2 directory: $ cd ~/.private/ja2/ Now we need to tell the Linux dynamic library loader to use the old libX11 rather than the new systemwide one: $ export LD_PRELOAD=/home/schreib1/.private/ja2/libX11.so.6.2 We're most of the way there (as a matter of fact, on my system, JA2 will start up and run, with the occasional crash and no sound at this point). The JA2 binary is incompatible with the NPTL-compiled version of glibc, however. Red Hat includes a non-NPTL version of glibc in Fedora Core 1. You just need to tell the Linux dynamic loader to use it: $ export LD_ASSUME_KERNEL=2.4.1 Now you should be able to run JA2: $ ./ja2 Given the number of commands that have to be typed to start the game, I'd recommend creating a shell script and dropping it somewhere in your path, perhaps in ~/bin. This way, you can just run the game from anywhere on the system with one command: #!/bin/bash # ja2.sh # Starts Jagged Alliance 2 cd ~/.private/ja2/ export LD_PRELOAD=/home/schreib1/.private/ja2/libX11.so.6.2 export LD_ASSUME_KERNEL=2.4.1 ./ja2 I suspect that there are folks that would appreciate a post of where to get the proper libraries for their Gentoo/Debian/what-have-you system. If you get this working on something other than Fedora Core 1, please drop us a note here, so that other people using your distro can benefit from your work as well. Good luck, and have fun kicking out the evil Queen! -- Mark Schreiber (mark7+happypenguin@andrew.cmu.edu)
[Reply]
Re: Making this game work on modern dist posted by Anonymous @ 144.139.77.50 on Mar 7 2004 5:59 PM   I can confirm that this works for mdk 9.2. Thanks v.much for the fix. Also, I love the atool scripts - very useful. Can you describe how you diagnosed the problem? I'd guessed a glibc version problem but didn't even consider that there might be X11 issues. Also, I suspect that this type of solution will come in handy for other old games. Here is the script I use for my setup - I install games in a dedicated partition mounted at /usr/local/games, and I opted to drop the libx11 library in to the ja2/lib. #!/bin/bash # JA2 would not run without an older libX11 and an older glibc (ie without threads). # This script is taken from here http://happypenguin.org/show?Jagged%20Alliance%202# ja2.sh # Starts Jagged Alliance 2 # JA2 would not run without an older libX11 and glibc (ie without threads). # This script is taken from here http://happypenguin.org/show?Jagged%20Alliance%202 cd /usr/local/games/ja2 export LD_PRELOAD=/usr/local/games/ja2/lib/libX11.so.6.2 export LD_ASSUME_KERNEL=2.4.1 ./ja2   [Reply]   Re: Making this game work on modern dist posted by Anonymous @ 217.236.36.238 on Mar 13 2004 6:57 AM   Thanks for providing the fix. JA2 runs again for me on SuSE9.0! Many thanks! But now, JA2 only starts in a window. I can't get it to work fullscreen. Anyone knows how to get JA2 to run fullscreen? Thanks again, chris   [Reply]   Re: Making this game work on modern dist posted by Anonymous @ 205.201.7.175 on Mar 16 2004 3:00 PM   Are you using the Red Hat 8.0 libraries, or old versions of the SuSE libraries from the same time frame? Perhaps you could try using the old SuSE libraries, on the off chance that they have some sort of DGA-related patches? -- Mark Schreiber (mark7+happypenguin@andrew.cmu.edu)   [Reply]   Re: Making this game work on modern dist posted by Anonymous @ 205.201.7.175 on Mar 14 2004 9:14 AM   Can you describe how you diagnosed the problem? I'd guessed a glibc version problem but didn't even consider that there might be X11 issues. Also, I suspect that this type of solution will come in handy for other old games. Heh. Yes. Well. It was not the easiest troubleshooting I've done. I actually first poked at this something like a year ago, researched the feasibility of converting dynamically linked binaries to statically linked, and spent time poking about in disassembly and with debugging tools like valgrind, strace, ltrace, and gdb before I happened to go for this. The first thing you do when troubleshooting an application that worked at some point and then stopped working is figure out what changed in the environment to cause the breakage. There aren't that many things that can cause an application to start barfing. The most likely change would be a data file change (especially to a dotfile), followed by a change to libraries used by the application, followed by a change to the application binaries itself, followed by a change in something the kernel does or is returning (perhaps eth0 isn't there any more, etc), followed by a change to hardware. If the application uses the network, a change in what data is coming back over the network is suspect. If the application talks to another process, something different coming back from the other process is suspect. That's about it in terms of what to troubleshoot -- oh, occasionally you want to look for an environment variable that you set and forgot about and breaks newer versions of a piece of software. First, try and narrow down the problem. Run the application with strace -f, maybe with gdb, maybe with valgrind, maybe with ltrace -f. See what the last few calls from ltrace or strace before the segfault were. See what the stack trace in valgrind and gdb looked like. Normally, with valgrind or gdb, if the application binary hasn't been stripped, you'll have a good clue or two. In this case, the stack trace at the time of the crash appeared to be somewhere in the i18n functionality of glibc. This was misleading, and threw me and others off the scent for a while. A long while. The first cure for old binaries under glibc (and this will persist for the next few years) should be to try disabling NPTL, the new threading interface. NPTL breaks a *lot* of software in very unpredictable ways. You can apparently tell the Linux library loader to do this (I picked this up by reading tidbits of people talking how to fix problems rather than learning exactly why things work the way they do) by setting the environment variable LD_ASSUME_KERNEL to an older kernel version -- for some reason, 2.4.1 seems to be commonly used. IIRC, this didn't fix my problems, which was a bit disappointing. A lot of people got hung up somewhere around this point. I hung onto this as an idea, however, since IIRC JA2 uses multiple threads, which I picked up from gdb. A lot of games have a sound thread, since sound is the one real-time operation that most games need to perform, preemptive multithreading makes this easier. I have found that the biggest cause of something breaking -- you do a fresh install, and *this* time the application doesn't work out-of-box -- is changed datafiles. Maybe your prefs have some data that's out-of-date or refer to a file that isn't there any more. I, as other people working on this did, first tried running the application with strace -f and looking at what files and directories are being accessed (actually, strace -fe open is usually good enough, since open() is the most likely culprit). Look for failed open() calls -- sometimes processes segfault if they aren't checking to see whether opening their data file worked. If all the open()s succeded, try moving and letting the application regenerate any user-specific config files that come up -- usually .[applicationname] in your home directory. The problem is, Jagged Alliance 2 didn't seem to access any config files, so I was out of luck there Okay, well, config files weren't my problem. The next best possibility would be a change in libraries used by the application. In the Linux library scheme, libraries are supposed to be backwards-compatible with old binaries within minor versions -- this lets you dump in a new library with bugfixes without rebuilding your entire system. However, in real life, behavior tends to change around a bit. XFree86 has had an imperfect history of backwards compatibility, *especially* with regards to DGA. I ran ldd on ja2. Hmm...all the things the ja2 binary were linked to were in glibc -- pretty much a dead end, unless I wanted to try setting up multiple glibcs. The valgrind stack traces from earlier seemed to indicate that whatever was dying was in tsv_xshm.so, a library included with JA2 and explicitly loaded by the library. This is probably a graphics compatibility layer done up by Tribsoft. When I ran ldd on tsv_xshm.so, I got all the same linkings as the ja2 binary...plus a link to libX11.so.6 and libXext.so.6. This was suspicious. The Linux library loader lets you load a library before going through the regular looking-for-linked-libraries process by setting the environment variable LD_PRELOAD to the name of the library you'd like to load. This method is how a lot of programs that hook calls in binaries for debugging purposes pull it off -- for example, the Electric Fence memory debugger preloads a library that overrides the regular glibc malloc(), free(), and realloc() calls. It's also useful for forcing an old version of a library to be used instead of a newer one. It's okay to use an old version of Xlib with a newer X server and visa versa -- the protocol was designed to work this way, or else all machines where people used X11 programs remotely over the network would have to have the same version of the libraries and the server. I grabbed an old XFree86-libs package from a version of Red Hat that I knew I had successfully run JA2 under -- Red Hat 8. I extracted the thing, set LD_PRELOAD, and the application started without segfaulting. I didn't have sound, and the thing seemed to hang randomly, but I was a lot better off than before. Given that the problem was with sound, and I was already suspicious of NPTL causing problems, for the reasons mentioned above, I set the LD_ASSUME_KERNEL environment variable and things worked completely (including fullscreen mode). Basically, I cut out all the silly and frusterating things I did, but that's a reasonable start. :-) It really is frusterating to troubleshoot old binaries like this, especially on Linux, where there isn't a strong culture for absolute backwards binary compatibility and some resistance to closed-source software. A good solution may be to try to convince game vendors to GPL old games -- usually, there isn't a terrible amount of value in game code after a couple of years, especially if the data files aren't included. This lets people rebuild and fix the software -- usually game vendors are not supporting a piece of software that was released six years ago. I know that I would be much more interested in purchasing a game for Linux if the game came with a guarantee that the source would be released under the GPL six years from the release date. It lets people do basic maintenance on the game, as has happened with Quake. O'Reilly has taken a similar tack with their books. Computer (well, IT) books are pretty much worthless seven years after their publication date, so it costs O'Reilly very little to follow Revolutionary War-era copyright law. If you take a look at Lucasarts, they've done very well. They *still* sell CD collections of their classic games, even though few people use DOS any more. Why? Because the ScummVM people reverse-engineered their engine and have an open-source VM out there. It gave new life to selling the data files. I bought two Lucasarts games last month -- two sales that would not have happened without the open source engine out there. There's not a whole lot of brilliant stuff in a six-year-old game engine that a competitor is likely to use. -- Mark Schreiber (mark7+happypenguin@andrew.cmu.edu)   [Reply]   Re: Making this game work on modern dist posted by Anonymous @ 24.33.150.184 on Apr 1 2004 12:26 PM   I can confirm that this works in Slackware 9.1.   [Reply]   Re: Making this game work on modern dist posted by Anonymous @ 24.33.150.184 on Apr 1 2004 12:26 PM   By the way. Thanks for your hard work on figuring this one out.   [Reply]   Re: Making this game work on modern dist posted by Anonymous @ 84.169.191.72 on Mar 6 2005 3:54 PM   Great! Thanks very much for finding this out and explaining what to do. I can confirm that it works now with my current Debian Sarge system.   [Reply]   Re: Making this game work on modern dist posted by Anonymous @ 193.198.136.87 on Mar 5 2006 2:33 PM   This worked for me; Gentoo 2006.0, Linux 2.6.15 kernel and X.Org 6.8.2 Thank you   [Reply]