Firstly I'll say I'm using this on wine-1.1.9, any other wine versions might have unexpected (or expected) issues.
it's a bit verbose to explain everything in minute details so instead I have written a script to (hopefully) do it for you, it should be attached to this post.
Before running the script rename your Tribes2/GameData/base/T2csri.vl2 to T2csri.vl2.bak, the script will leave this untouched but assumes it to be a 'clean' copy from which it builds the new.
Extract the script,
$ chmod +x t2hack.py
$ ./t2hack.py /path/to/your/Dynamix/Tribes2/
you should now be able to launch T2 under wine (using Wine Tribes2.exe -online) but as the name suggests it really is just a nasty hack But for me at least it's still more convenient than using Windows.
You will lose the server browser (use instead the MaxOGC link in the sticky in the main forums) meaning you'll have to join servers by IP but I'm afraid I'm unfamiliar with what console command allows that... One of the PJ scripts adds a 'join IP' button to the server list screen, but I'm not sure exactly which. Favourites still retains a list of servers but it can't query them.
Surprisingly, you also seem to be able to actually register accounts using this (which I tested once and managed to get through without Wine locking up), but if you do so, afterwards you'll have to quit and re-run the script in order to hard code the certificate for it.
You'll also have to re-run the script if your IP changes.
Hopefully it'll work but any problems let me know (BTW: if your env python variable is set to a Py3k interpretor you'll have to run it under a Py2.x interpretor instead; I think most if not all distros are still 2.x though)
A brief explanation of the files within T2csri.vl2 it modifies are:
scripts/autoexec/t2csri_list.cs -> renamed to t2csri_list.cs.null to prevent it being executed. This disables the server browser, and something else which caused wine to lock up randomly ish.
t2csri/ipv4.cs -> changes ipv4_getInetAddress() to define the computer's IP address at the top of the function (workaround for intro screen wine lockup)
t2csri/clientSide.cs -> changes t2csri_getAccountCertificate() to include the details from the public.store file (workaround for the truncated certificate issue)
$ ./t2hack.py ~/.wine/drive_c/Dynamix/Tribes2/
public.store not found - cert won't be updated -- you will need to rerun this script after you have an account.
Traceback (most recent call last):
File "./t2hack.py", line 56, in
z.extractall(tmp, toextract)
AttributeError: ZipFile instance has no attribute 'extractall'
ah why does nothing ever work as you want it to :P okay, apparently that wasn't introduced til Python2.6 so presumably you have a pre 2.6 install
If you change line 56 to read:
It looks like the new RC1E update fixes a lot of what the t2hacks.py script fixes. A couple things to note though:
* If you do not run the t2hacks.py script after the RC1E update, the game will play, the server browser will work as well, but when you play eventually it will stop working during play. It hits whatever wine issue was existing before.
* If you apply the t2hacks.py script after the RC1E update, the game plays fine, but the server browser goes back to being broken.
So far the best solution I have found is to run the game without the the patch first, then favorite all of the servers you plan to play on. Then exit and apply the t2hacks.py script. That way the game doesn't timeout during play and you get all the favorites in your server list. At that point, you can still query them for status and everything else, you just can't get an 'All Servers' listing. If for some reason you want to go back to pre-t2hacks.py execution, simply remove the T2csri.vl2 and copy the backup T2csri.vl2 to that file and re-run and it's back to normal. I've had to do this a couple times to add other servers that would start up after I had applied the t2hacks script.
Installed PJ's all in one from the windows .exe via wine.
Reverted to the backup T2csri.vl2 and I appear to be working with the server browser and no mystery crashes. I just had 4 hours of play without lockup.
Tribes 2 + Wine (1.0.1 and 1.1.5.. I've tried both) + AMD 64 (64 bit) Debian Lenny
Maybe I have to run under a 32-bit chroot? Or run actual i386 (32-bit) Debian? :-/
Anyone else here have success with amd64 distro?
I also noticed, pre-rc2a patch, when I ran the Tribes 2 training sessions. Lt. Kenzie (and your objective) would be stuck on the first thing and she would repeat the same first thing she said over and over and over forever.
Prior to patching, the game itself seems to work fairly well under wine, even with a 64-bit system (Gentoo 64-bit, on a dual-processor AMD Opteron 246 system). The RC1e patch worked acceptably in wine as well, but it looks like I broke something when making changes for RC2 (which has also broken in some versions of Windows Server). I'd suggest using RC1e for now on Linux systems, but you won't be able to generate an account with that patch version.
I've partially traced it down to inter-process transport encoding, but I haven't had the time to fix it yet, or to work on the community features for RC3.
Oh... and if any advanced Linux C/C++ programmer wants to help me out with a Loki port, I'm sure something could be hacked together for dedicated server support (It just needs SHA1, big integer base conversion, and big integer modular exponentiation). I'm just not sufficiently familiar with shared library injection in Linux.
hi, I got everythig working! but! when i start the game, i get the old login screen? how do i generate CDkey? i just get the old great account or login with old existing account? eny ideas?
Anyone ever try installing the old Loki Games CD on a Linux machine?
I'm running amd64 and it bombs out on the setup.sh. I know P!nk Panther who
runs a TribesNext server on amd64. I'd like to just set up Tribes 2 in the first place.
I managed to get it to run setup.data/bin/Linux/x86/glibc-2.2/setup.gtk, but
it dies when it tries to find bin/x86/t2launch and fails.
Has anyone ever tried installing on an amd64 arch?
If you want to play TribesNext in Fedora 11 but find the newer Wine doesn't work . Have no fear NewbBlood! Go to http://koji.fedoraproject.org/koji/buildinfo?buildID=77739 and download all the packages there. I've tested this and I'm using wine-1.1.12.If you already have wine installed. Install these packages like so # rpm -Uvh --oldpackage wine-*.rpm . If you don't have wine installed just omit --oldpackage. Apply the patch from earlier in this thread. Run wine like so, wine Tribes2.exe -online -connect ipaddress . You can check the web server list for ipaddress's and just insert the address of the server you want to connect to.
Hi, Ive been following this thread very closely trying to get tribes to work in ubuntu jaunty jackalope running Wine 1.1.19 as suggested.
On a fresh install of TribesGSI.exe into wine. Ive gotten tribes to work, very well, yet with NO tribesnext patch installed. I cant connect to a tribesnext server with the via "-nologin -connect 66.162.166.53" (GoonHaven) in the wine shortcut.
When I start tribes with the Rc2a patch installed, it just wont do anything, Ive tried this t2hack.py, and nothing.
What do I do? Is my env python variable is right in jaunty jackalope.
Installed Rc1e patch instead of Rc1a and it worked like a charm. : )
Team Inferno Scores!
Now if I can only fix the wierd linux mouse acceleration thats messing up my MA's!
If you want to speed up wine, or fix the mouse (called MouseWarp....eww). I knew I wasnt crazy.
These sites can help you edit the wine registry.
The video memory key really sped my system up. I guess wine wasnt making use of the 512 available.
Seems the problem is that ruby isn't working... rubyEval doesn't do anything in the scripts. I tested it on Wine 1.1.27 and 1.1.29 with the same results.
I know 1.1.11 worked (yes, I know it's a major downgrade)...
You'd have to ask some of the other users what they managed to get it working on for more version info.
It is possible that the newer versions of Wine have some incompatiblity with the patching program that the installer uses to modify the Tribes2.exe file. I used some sort of binary delta program for this purpose in the installer (xpatch, I think). If that patching process fails, the executable is not modified to load the new DLL that enables Ruby and the other code patches necessary to play on our system.
In any case, I will investigate more closely for the next releases, and if necessary, build a separate installer for the Wine platform.
I've completed a code review of our patch, and traced the source of the Wine incompatibility. It ends up, none of the code changes I made were the source of the problems, but rather bugs in the Ruby MRI implementation.
For RC2, I switched from Ruby 1.8.7 to Ruby 1.9.0, because Ruby 1.8.7 crashes when more than one thread is spawned in the interpreter process (even if that thread doesn't interact with the interpreter itself). A second thread was needed to verify the game was still running (so the interpreter properly closes if the game dies without issuing a quit call). Using Ruby 1.9.0 solved that issue in Windows, however, bugs in that version result in a thread deadlock when running in Wine (POSIX threads behave slightly differently than W32 threads).
I was able to initialize the interpreter (without any TN code modifications) under Wine when running the most recent Ruby 1.9.1 DLL (p243), and this is apparently suitable for operating a dedicated server. However, the Ruby 1.9.1 DLL crashes when performing any file IO operation (in both Windows AND Wine), thus is not suitable for client mode. Client mode uses the Ruby IO API to read the credential stores, since I explicitly placed those files outside the reach of TorqueScript file objects.
So, in a nutshell, the Ruby MRI interpreter is buggy and flaky beyond belief. I'm still working to resolve these issues with the Ruby 1.9.1 interpreter, and it is the last major piece of native code modification for the next release candidate.
Comments
Yes. I would like this very much.
Firstly I'll say I'm using this on wine-1.1.9, any other wine versions might have unexpected (or expected) issues.
it's a bit verbose to explain everything in minute details so instead I have written a script to (hopefully) do it for you, it should be attached to this post.
Before running the script rename your Tribes2/GameData/base/T2csri.vl2 to T2csri.vl2.bak, the script will leave this untouched but assumes it to be a 'clean' copy from which it builds the new.
Extract the script,
$ chmod +x t2hack.py
$ ./t2hack.py /path/to/your/Dynamix/Tribes2/
you should now be able to launch T2 under wine (using Wine Tribes2.exe -online) but as the name suggests it really is just a nasty hack
You will lose the server browser (use instead the MaxOGC link in the sticky in the main forums) meaning you'll have to join servers by IP but I'm afraid I'm unfamiliar with what console command allows that... One of the PJ scripts adds a 'join IP' button to the server list screen, but I'm not sure exactly which. Favourites still retains a list of servers but it can't query them.
Surprisingly, you also seem to be able to actually register accounts using this (which I tested once and managed to get through without Wine locking up), but if you do so, afterwards you'll have to quit and re-run the script in order to hard code the certificate for it.
You'll also have to re-run the script if your IP changes.
Hopefully it'll work but any problems let me know (BTW: if your env python variable is set to a Py3k interpretor you'll have to run it under a Py2.x interpretor instead; I think most if not all distros are still 2.x though)
A brief explanation of the files within T2csri.vl2 it modifies are:
scripts/autoexec/t2csri_list.cs -> renamed to t2csri_list.cs.null to prevent it being executed. This disables the server browser, and something else which caused wine to lock up randomly ish.
t2csri/ipv4.cs -> changes ipv4_getInetAddress() to define the computer's IP address at the top of the function (workaround for intro screen wine lockup)
t2csri/clientSide.cs -> changes t2csri_getAccountCertificate() to include the details from the public.store file (workaround for the truncated certificate issue)
public.store not found - cert won't be updated -- you will need to rerun this script after you have an account.
Traceback (most recent call last):
File "./t2hack.py", line 56, in
z.extractall(tmp, toextract)
AttributeError: ZipFile instance has no attribute 'extractall'
If you change line 56 to read:
os.popen("unzip " + gamedata + "/base/T2csri.vl2.bak " + " ".join(toextract) + " -d " + tmp)
that should do the same thing (assuming you have unzip installed)
* If you do not run the t2hacks.py script after the RC1E update, the game will play, the server browser will work as well, but when you play eventually it will stop working during play. It hits whatever wine issue was existing before.
* If you apply the t2hacks.py script after the RC1E update, the game plays fine, but the server browser goes back to being broken.
So far the best solution I have found is to run the game without the the patch first, then favorite all of the servers you plan to play on. Then exit and apply the t2hacks.py script. That way the game doesn't timeout during play and you get all the favorites in your server list. At that point, you can still query them for status and everything else, you just can't get an 'All Servers' listing. If for some reason you want to go back to pre-t2hacks.py execution, simply remove the T2csri.vl2 and copy the backup T2csri.vl2 to that file and re-run and it's back to normal. I've had to do this a couple times to add other servers that would start up after I had applied the t2hacks script.
Followed the below procedure posted by MojoBlue.
Installed PJ's all in one from the windows .exe via wine.
Reverted to the backup T2csri.vl2 and I appear to be working with the server browser and no mystery crashes. I just had 4 hours of play without lockup.
wine 1.0.1
Mint Linux 6 - Ubuntu 8.10 derivative
wine 1.0.1 working here perfectly too
Debian lenny/squeeze/sid Linux(32-bit install)
did the install, made an account, ran the RC1E update..
two 2 and a half hour stretches so far.
VICTORY, INFERNO.
cheers,
-m
Maybe I have to run under a 32-bit chroot? Or run actual i386 (32-bit) Debian? :-/
Anyone else here have success with amd64 distro?
I also noticed, pre-rc2a patch, when I ran the Tribes 2 training sessions. Lt. Kenzie (and your objective) would be stuck on the first thing and she would repeat the same first thing she said over and over and over forever.
I've partially traced it down to inter-process transport encoding, but I haven't had the time to fix it yet, or to work on the community features for RC3.
Knowing what to google for, I got this hit:
Code Injection into Running Linux Application
http://www.codeproject.com/KB/DLL/code_injection.aspx
Looks like a good starting point.
Running Ubuntu jaunty with wine 1.1.23
I'm running amd64 and it bombs out on the setup.sh. I know P!nk Panther who
runs a TribesNext server on amd64. I'd like to just set up Tribes 2 in the first place.
I managed to get it to run setup.data/bin/Linux/x86/glibc-2.2/setup.gtk, but
it dies when it tries to find bin/x86/t2launch and fails.
Has anyone ever tried installing on an amd64 arch?
http://icculus.org/lgfaq/
On a fresh install of TribesGSI.exe into wine. Ive gotten tribes to work, very well, yet with NO tribesnext patch installed. I cant connect to a tribesnext server with the via "-nologin -connect 66.162.166.53" (GoonHaven) in the wine shortcut.
When I start tribes with the Rc2a patch installed, it just wont do anything, Ive tried this t2hack.py, and nothing.
What do I do? Is my env python variable is right in jaunty jackalope.
Team Inferno Scores!
Now if I can only fix the wierd linux mouse acceleration thats messing up my MA's!
These sites can help you edit the wine registry.
The video memory key really sped my system up. I guess wine wasnt making use of the 512 available.
http://wiki.winehq.org/UsefulRegistryKeys
http://linuxgamingtoday.wordpress.com/2008/02/16/quick-tips-to-speed-up-your-gaming-in-wine/
Any ideas on what's causing this or how I could find out?
Running Jaunty and the latest version of Wine from the Wine PPA.
I am also having the same error right now. Anyone figure it out?
I believe RC1e is the only option for Wine/Crossover, unless Wine has since done something funky...
You'd have to ask some of the other users what they managed to get it working on for more version info.
In any case, I will investigate more closely for the next releases, and if necessary, build a separate installer for the Wine platform.
Gets that error up there. ^
For RC2, I switched from Ruby 1.8.7 to Ruby 1.9.0, because Ruby 1.8.7 crashes when more than one thread is spawned in the interpreter process (even if that thread doesn't interact with the interpreter itself). A second thread was needed to verify the game was still running (so the interpreter properly closes if the game dies without issuing a quit call). Using Ruby 1.9.0 solved that issue in Windows, however, bugs in that version result in a thread deadlock when running in Wine (POSIX threads behave slightly differently than W32 threads).
I was able to initialize the interpreter (without any TN code modifications) under Wine when running the most recent Ruby 1.9.1 DLL (p243), and this is apparently suitable for operating a dedicated server. However, the Ruby 1.9.1 DLL crashes when performing any file IO operation (in both Windows AND Wine), thus is not suitable for client mode. Client mode uses the Ruby IO API to read the credential stores, since I explicitly placed those files outside the reach of TorqueScript file objects.
So, in a nutshell, the Ruby MRI interpreter is buggy and flaky beyond belief. I'm still working to resolve these issues with the Ruby 1.9.1 interpreter, and it is the last major piece of native code modification for the next release candidate.