Time for a quick update. I'll probably post another one in a few hours.
All of the pre-login code is complete. I've done UI polish, proper error handling, and even increased the entropy available for the client side random number generator. I ran into some issues with network communication with the authentication server that stumped me for a while (availability, name check, account download requests were working, but account signatures were not, so I didn't realize it was networking related right away). It ended up being a latency sensitivity issue and I rewrote part of the authentication server communication interface to prevent any similar situations from occurring in the future.
All authentication server issues have been resolved with the database, and that server has been deployed in its final configuration for almost a week.
I have only one part left to test/debug, and that is the client/game server interaction code, and the new ban code. I plan to finish this part sometime in the next couple of hours.
After that, I send the package to Krash so he can finalize the logo, insert the listing code, and then we produce/release the patcher for our first beta release.
Server side script code worked exactly as it was designed. Certificate verification worked perfectly, and I successfully connected to my test server on the first attempt. I still need to implement IP bans and GUID bans in script, since the built in engine functions don't work anymore. Otherwise, it worked beautifully -- the client in authentication phase stays on the "Joining Game" popup box for the duration of the cryptographic exchange.
Unfortunately, I've run into some minor issues initializing the game servers in "online" mode. Ordinarily, this would be only a minor concern, but the client runs in "online" mode, and this affects the server query code (i.e. clients in online mode can't see the list of players in an offline mode server). Krash originally set up that part of the script, so I'll need to chat with him about possible workarounds.
I think after the first beta release, I'll probably want to bump the version of the built in Ruby interpreter from 1.8 to 1.9, since the 1.9 interpreter is roughly 2.5x faster in numerical computing than the 1.8 interpreter. This would cut down on account generation time, and reduce the slight lagspike during the server verification process.
In any case, the first release will be a beta quality release. I doubt it will be perfect, and I don't have the time to integrate some of the secondary functionality (like auto-update), but it will be orders of magnitude better than the cesspool that are the no-login solutions.
Still a little bit of code to polish, and I'm not sure of Krash's availability, but it is functionally complete from account creation to joining servers at this point.
I've sent the scripts to Krash, and he was able to generate an account successfully, and join my test server. You can see a screenshot of us hanging by a random column attached. As in any system, there were a couple of minor snags that are either fixed at time of this post, or will be shortly.
Krash is doing the important job of finalizing the UIs, including listing functionality, and producing the online mode workaround for the servers.
It's been a very long tunnel. It's good to hear that there's an end to the depressing tunnel of inconvienience, and that there's actually light on the other side. :P
I've sent the scripts to Krash, and he was able to generate an account successfully, and join my test server. You can see a screenshot of us hanging by a random column attached. As in any system, there were a couple of minor snags that are either fixed at time of this post, or will be shortly.
Krash is doing the important job of finalizing the UIs, including listing functionality, and producing the online mode workaround for the servers.
We'll be done really soon.
I like the words- "really soon."
Thank you for the late, yet delicious holiday cookies.
The scripts are complete. I'm going to make some modifications to the DLL to reduce size of the IPC buffer -- the lagspikes that are generated as a result of IPC are too big to tolerate in the current DLL. After that, I get to write some legalese for the EULA, so nobody gets to sue us, and then write some patch code for the installer. The way the installer is built is pretty important for the DMCA 1201f reasons discussed earlier.
Oh yeah... TribesNext clients can still join servers running in LAN mode, so if for whatever reason some particular server doesn't want to switch, you can still play. Vice-versa doesn't apply though -- you must have a TribesNext client and a valid certificate to join a TribesNext server.
If we don't release today (I have festivities to attend), we'll release tomorrow.
New DLL is built. I reduced the IPC buffer size from 1 MB to 64 KB -- in practice, the largest chunk being transferred over the IPC interface is the crypto script (12 KB), so the limited buffer size isn't an issue. On the plus side, operations on the buffer are almost instant now, so no perceptible lagspike during join-verification. The 1-2 second processing spike was my only dissatisfaction with the system.
I just want to say that the patch is done, and Krash has posted the first release candidate for a little bit of small group testing. The patch itself comes in the form of an installation executable, and the whole system is designed to be really user friendly.
Unfortunately, I had some sort of hardware failure on the remote server I was using for hosting the authentication system -- perfect timing, I know. I'm setting up a new server location at the moment, and verifying that it is operational.
Comments
-Phantom
Really? I didn't see a difference between my post and this.
All of the pre-login code is complete. I've done UI polish, proper error handling, and even increased the entropy available for the client side random number generator. I ran into some issues with network communication with the authentication server that stumped me for a while (availability, name check, account download requests were working, but account signatures were not, so I didn't realize it was networking related right away). It ended up being a latency sensitivity issue and I rewrote part of the authentication server communication interface to prevent any similar situations from occurring in the future.
All authentication server issues have been resolved with the database, and that server has been deployed in its final configuration for almost a week.
I have only one part left to test/debug, and that is the client/game server interaction code, and the new ban code. I plan to finish this part sometime in the next couple of hours.
After that, I send the package to Krash so he can finalize the logo, insert the listing code, and then we produce/release the patcher for our first beta release.
I'm getting real tired of anonymous people joining my server and causing trouble.
Unfortunately, I've run into some minor issues initializing the game servers in "online" mode. Ordinarily, this would be only a minor concern, but the client runs in "online" mode, and this affects the server query code (i.e. clients in online mode can't see the list of players in an offline mode server). Krash originally set up that part of the script, so I'll need to chat with him about possible workarounds.
I think after the first beta release, I'll probably want to bump the version of the built in Ruby interpreter from 1.8 to 1.9, since the 1.9 interpreter is roughly 2.5x faster in numerical computing than the 1.8 interpreter. This would cut down on account generation time, and reduce the slight lagspike during the server verification process.
In any case, the first release will be a beta quality release. I doubt it will be perfect, and I don't have the time to integrate some of the secondary functionality (like auto-update), but it will be orders of magnitude better than the cesspool that are the no-login solutions.
Still a little bit of code to polish, and I'm not sure of Krash's availability, but it is functionally complete from account creation to joining servers at this point.
I've sent the scripts to Krash, and he was able to generate an account successfully, and join my test server. You can see a screenshot of us hanging by a random column attached. As in any system, there were a couple of minor snags that are either fixed at time of this post, or will be shortly.
Krash is doing the important job of finalizing the UIs, including listing functionality, and producing the online mode workaround for the servers.
We'll be done really soon.
~Syn~
It's been a very long tunnel. It's good to hear that there's an end to the depressing tunnel of inconvienience, and that there's actually light on the other side. :P
I like the words- "really soon."
Thank you for the late, yet delicious holiday cookies.
PS: Your cookies are appreciated.
Oh yeah... TribesNext clients can still join servers running in LAN mode, so if for whatever reason some particular server doesn't want to switch, you can still play. Vice-versa doesn't apply though -- you must have a TribesNext client and a valid certificate to join a TribesNext server.
If we don't release today (I have festivities to attend), we'll release tomorrow.
Happy New Year.
EULA writing time...
....
Unfortunately, I had some sort of hardware failure on the remote server I was using for hosting the authentication system -- perfect timing, I know. I'm setting up a new server location at the moment, and verifying that it is operational.
ULTRACORN!!!!!!!!!!
(Yet)
....