Tribes 2 Revival?
This is an interesting topic I found while browsing another forum: http://rftribes.com/forums/index.php?PHPSESSID=vqjmu6u3mpdtch3896ig0bg3c6&topic=102.msg313.
Tribes 2 revival forums: http://t2devo.com/.
Update: They've decided to merge with http://www.tribaloutpost.com/ because the webmaster has a lot on his own plate in life, so, he handed it over to someone who could manage it better than he could.
Tribes 2 revival forums: http://t2devo.com/.
Update: They've decided to merge with http://www.tribaloutpost.com/ because the webmaster has a lot on his own plate in life, so, he handed it over to someone who could manage it better than he could.
Comments
It won't happen by their hand. If someone wants a new community system, they can build it themselves.
But that require some engine mods. I think GameConnection::GetAuth() (SP) is an engine function, and connects to an IP that is defined therein.
Idk, it will give us something to talk about.
We're already distributing a modified EXE.
Actually, if you define $IRCTestServer, you can have it send all browser/tmail/chat related elements through your own IRC server. You'd have to set up a system to handle the commands and such, but it's doable - though it wouldn't be linked to the auth server.
http://rftribes.com/rfdm/
http://rftribes.com/forums/index.php/topic,102.msg345.html#msg345
When you log into the online part of the game, the authentication server gives you an authentication image. That image is what is returned by that function.
But how does the game server know the authentication image is valid? Asymmetric cryptography. The authentication image you get from the authentication server is digitally signed.
No game server<->authentication server communication is required to verify authentication images, beyond the initial communication that happens when the game server loads.
I'm sure you've noticed that when the authentication server has gone down in the past, it was impossible to initiate an online dedicated server. It is impossible to initiate because that initial key transfer communication fails.
If you want to replace the authentication system, I would suggest grafting Ruby to the T2 engine in a similar manner to the way Linker grafted Lua. Ruby has built in support for arbitrary precision integer types that are necessary for all major asymmetric crypto methods.
If yes, gimme.
This includes a client and server executable, both of which provide access to ruby and lua!
Both client and server are patched SI executables, so you can still use SI with your pretty ruby fun!
Installation
Notes
I've started implementing the RSA cipher (15 lines of Ruby), an RSA key generator (generates large prime numbers), and a hash algorithm. These are the essential components of the authentication system, and they are pretty straightforward.
We don't need Vivendi now.
Installation
Notes
Feel free to improve/rewrite entirely.
I'm not complaining, it's more of an error report. On Windows Vista, Tribes 2 gives me an error that msvcrt-ruby18.dll is missing. I'm looking for it now.
EDIT: Nvm got it already...
Neat!
Great, another superior language i should learn. >:(
Now with several packages to choose from!
t2-ruby includes the executables, DLLs, unified console, and a launcher (MS-DOS batch file)
dll includes t2dll.dll and msvcrt-ruby18.dll
console includes the unified console (now properly supporting resizing!)
scripts includes lua and ruby initializers & utilities.
launcher includes the custom launcher, and a registry file to enable DelayedExpansion in MS-DOS
source includes full source-code.
I want it all includes both t2-ruby & source
Installation
Notes
From what i've heard, most languages should be used over TorqueScript. If what else i've heard is true, this is one of them.
Ruby is very easy to learn, and can be pretty useful if you get in to it. It's worth a shot if you really want to try it out.
Why do we care about the ability to work with huge numbers? Seems rather useless until you think about the numerical requirements for asymmetric cryptography. Every major asymmetric cipher relies on some operations being very slow on large numbers, while other operations are very fast. Asymmetric cryptography enables writing a script that lets one person prove that a message came from another person, and that one person is who they say they are. By now, I hope you can see how this would be useful for an authentication system.
A player can send an account request message to the authentication server. The authentication server can then create a ticket for the player that says the account is valid. When the player joins a game server, the server can check the ticket to see if the account is valid, and can make sure the player is who they say they are. Any changes to the ticket will make it invalid.
The only way to do this is to allow asymmetric roles, where there are separate signature and verification roles. Where anyone can verify a signature, but nobody can forge a signature.
RSA is one of the (conceptually) simplest asymmetric ciphers. There are three numbers: E, D, and N. E and N are public, and can be known to anyone (they are used for verification). D is private, known to only one person (used for signatures). The authentication server has an E/D/N set, and each player has their own E/D/N set. N is calculated as a multiple of two prime numbers (P and Q). P and Q are used to calculate E and D through the Euclidean extended algorithm. The only real way (provided special precautions are taken when choosing P and Q) to get D from E and N is to factor N into P and Q.
Easy, right?
15 = 3 * 5, any child could figure that out.
2224927 = 71 * 31337, a bit more complicated, but a computer could do that in a fraction of a second
What if we go higher? This next one is 512 bits, or 156 digits.
1038557801480495022106519019573649119384754147938
9728420426514083771326945639729736695791225573893
7931194893360122978451461046376919412424857328392
77543427 = 903363060349886081779903699376749423125
98126945629080039358980696516831956279 * 114965715
0114424632841121950270840554465040708908568676185
84335022146211064213
That took a distributed effort several months to crack. It was the RSA-512 server key used in the Earth and Beyond MMORPG. The server emulator community put together their computing resources to crack that back in 2006. On a modern high-end 8 core Xeon, the same computation might be possible in under 6 months.
Yet, at the same time, you can verify that factorization in a tiny fraction of a second. Multiplication is fast. Factoring isn't.
The idea is to use an RSA-1024 bit key for the authentication server, and if possible, for all clients. It would take about a century to compute the modulus factors, so it is safe from cracking. Finally, in the event my authentication system goes down, anyone with an existing ticket would still be able to play.
That's why I asked Turkey to integrate Ruby with T2.