[SSX-Killjoy]

Good Morning,

It has certainly been awhile since I have been here, and has happened. However I noticed in another thread (http://www.amazon.com/gp/product/0596005431/ref=pd_sxp_elt_l1/002-4666357-1688052?n=283155) that Taylor has been working on the client/server stuff for PXO. I was wondering if there was an update on the status for the PXO stuff, and if there was anything I could do to help out.

My skills are primarily the web based (being the one that did the rework of the FS2NetD site), but integration is my love. If there is a need for web side integration for PXO (ie the old version ran on Cold Fusion Server) I would be glad to take the challenge on. I am also pretty decent at reading C/C++ code so if documenation is scare, no fear.

anyways.. Looking forward to the information..

(I have recently been playing Flight Sim 2k4 and have been musing over the code for the FSD server system so I figured if I am going to be spending the time on that, I should see what I can do to help out here as well. A good multi-player run/killing spree is in much needed order... )

[taylor]

The CFM to PHP/MySQL conversion is still needed, though you would make the 4th person to volunteer for that job at this point, the 2nd this week.  We do need an admin interface through PHP though and that's going to take a fair bit of imagination, since the server side doesn't actually exist yet.  If you are interested in either of those tasks then let me know.  You'd need to be able to translate CFM and the file based database into PHP and MySQL.  I don't think it will necessary to get into the tracker code though so you can probably skip having to deal with the horrid C++/MFC crap.

Unfortunately, none of that will really speed up getting the server done.  I just haven't had time to really get into the rewrite for the trackers yet.  The client side still needs work, though it's mostly been put back into FS2_Open, but it's 100% untested.  I haven't even gotten it to the point where it will build all the way yet.  I've got so much new code at the moment (around 100,000+ lines of fixes and new features for FS2_Open) that it's a pain to work with any of it.  The plan is to set up a new SVN server locally (to replace my aging CVS server that I've managed to horribly rape over the years) in the next couple of weeks to help me manage all of it and I hope that will make it a bit easier to get things done.  As long as I get enough free time it shouldn't take that long to rewrite everything.  What will take the longest is all of the new FS2_Open support that I have planned, and most of that code exists only in my head.

The web site and admin side does need to be done at some point though.  And I'll probably take most of my db coding cues from the PHP/MySQL conversion, but it's going to be strange since we'll be going somewhat backwards in that whole process.

[SSX-Killjoy]

Actually Taylor, this is where my skills shine. I am good at taking existing systems and converting them into better systems. This includes database work, front end, administration, etc. So YES, I will gladly volunteer my help to make the front end the key to your success..

It is very possible to build it front end first, with backend hooking into it. I have written several systems where the backend didn't exist until long after the front end was in place (mostly hooking JAVA applications that talked to PLC devices and embedded controllers into PHP front ends with FLASH). As long as we know what we want to achieve it should be relatively simple. I understand enough about system/server relations that I can make a fair guess at what has to be left to the server itself and what can be handled by the front end mainly. So, please feel free to post your thoughts of how the new PXO should/could work on the server/client side and I will take care of programming where I can. I also have enough practice I think to work on the Server implementation as well. Although my specialty isn't C++, I do know how create sockets in other languages. Maybe Python maybe a better language for this as it can run both as a scripted language and a compiled service. C#/ASP, etc.. Whatever..

To layout the basics for the framework I can see the following needs:

Administration
   * Create/Manage/Remove Pilots
   * Modify scores by removing completed misssions by pilot
   * Create/Manage/Remove Squads (and associated Pilots)
   * Add/Manage/Remove Validated Mission Files and/or other files (Table files, POFs etc?)
   * Create/Manage/Validate/Remove Officially approved servers
   * Create/Manage/Remove Official Moderators (and game observers?)
   * Create/Manage/Remove Tourney Style Ladders
   * Manage Ban Lists and/or Suspensions
   * Post/Remove news items

Pilots
   * View scores/stats/completed missions
   * Modify pilot information
   * Upload pilot Avatars
   * Sign up/Use Forums
   * Sign up/Leave Squads
   * Manage/Request Duels
   * Recieve/View System Updates
   * View Universe Map standings (FS2 capability)
   * Manage friends list (know who is online and their ping and server playing on)

Squads
   * Create/Manage/Remove Squads and their information
   * Accept/Deny Join Requests
   * View Squad Standings and other system information (pilots online, etc)
   * Accept/Deny/Request Squad Battles
   * View Squad system ownership (FS2 capability)

In Game
   * Publish mission statistics/stats on completion (so no leaving a game mid-run )
   * Verfiy pilot validity
   * Verify Duel/Squad Battle ids
   * Verify mission files (and/or other files?)
   * Recieve News Updates
   * Communicate Bans/Suspensions to players
   * Handle IRC style communication?
        - includes public/private communication and possibly on server communication?
   * Retrieve Pilots information/standing (for use in player look ups or dispalying on comm pages)
   * Recieve Pilot Avatars/Squad logos, etc.

Main Server
   * Maintian communication with players online
   * Handle dumping of stats to PXO
   * Process IRC communication interactions
   * Provide pinging services(?)
   * Validate connections
        - Validate game versions (?)
   * Maintain communication with Player and Official Servers

I doubt i have everything covered but I think have the core here for starting. I can build 90% of all that into the front end, with only the communications to the game itself left to however you want to implement it. If you have other ideas or thoughts or needs, please let me know. Otherwise I have a current PHP framework we can put to work with the user/squad/admin stuff and setup the Database side.

* SSX-Killjoy plunges headlong into coding...

[Turambar]

well it's nice to see that kind of enthusiasm.

[Taristin]

Ahh, KJ. Long time no see. Good luck with this, if you do it. No one better for it than SSX.

[SSX-Killjoy]

I have some tutorials I need to practice in Flight Simulator 2004, but I will put in some hours on the administration side this weekend. With pilots next weekend, squads the weekend following. That should give Taylor atleast a couple weeks of breathing room before I bug him, and then depending on where he is, he and I can jump up and make this a reality.

First iteration of the application will not have a full layout, only code required pieces (forms, tables, etc). However the framework supports skinning, so if anyone wants to put together a layout for the new PXO in PNG format (I can manipulate it into the skin part of the application) I will gladly set it up for everyone to vote on their favorite skins. Just post them in this thread.

If it is done, and nothing has been put forth, I am sure I can put something together. But I bet there are some people here who are more artistically talented than myself..

Cheers and thanks for the thumbs up Raa.. !

[Goober5000]

Well, this is quite a welcome surprise.

[taylor]

@SSX-Killjoy:  Umm, did you want the original PXO CFM and database?  The client is based on that, so the rewritten game/user trackers will have to be based on that too.  We'll also have to keep support for Descent3, FS1, FS2Demo, FS2 and add new FS2_Open suppor, so we can't exactly re-invent the wheel here.  About all we can do is upgrade it a bit.

[SSX-Killjoy]

You are absolutely correct Taylor, how you get the information is set due to how they had done it originally. But all the information is transferred at the TCP/UDP level, so how the information is stored or manipulated is pretty much up to us; provided that whatever sends the information to the client knows where to get the information, and what format it needs to be in for the client to make use of it.

That is unless I am missing something. I know for a fact that we aren't required to use CF, so I am fairly certain my assumption is correct.

Also, I looked at the database and the CFM (and I am pretty sure I have it floating around here somewhere on one of my hard drives) when it was first released. Everything was sent to/from the client via the C++ app (the tracker) with the information stored in the CF database (in this case access).

The only downside is the last time I crawled the code for the tracker I had a hard time duplicating it in a JAVA based code structure. I know I didn't fully understand what it was doing, and I know for a fact SOMETHING was missing from the code becuase even compiled the code was very.... well.. basically it didn't seem to work. Hacking it some more it seemed to require a second tracker that didn't seem to be in the code. So on some level I am sure you are redoing the Tracker itself, so we have the room to decide how best to get the information.

Of course, I maybe just talking out of my butt; but I think I am on the right idea here. Please let me know if I am off my rocker before I get too far into this.

[taylor]

We are set in what we send and how we send it, but not how to use it once we've got it.  The "once we've got it" part needs to be cross-platform, which means it can't be tied to any CPU type.  Other than that there probably aren't any rules other than common sense.  And this is for the original PXO support of course, we have almost free reign for the enhanced FS2_Open support.

The tracker will still be C/C++, database access though MySQL queries, admin though socket(s) using whatever web-based interface is made.  There are two trackers, user and game, but I intend to merge those, probably with the IRC server code too (running in a different thread).  The IRC code is currently a separate app but I don't see the point in having to start up three different servers to act as PXO.  The biggest problem is that the tracker side is mostly MFC and so it has to be completely rewritten.

And it will probably be August before I actually start coding on this again, no matter how much you start nagging at me to work on it sooner.   I'm busy with RL stuff through most of next month and PXO isn't that high on my todo list anyway.

[SSX-Killjoy]

Would it be easier if the C/C++ sent requests to the backend and recieved XML instead of requiring a MySQL connection? I am not sure how difficult it would be to implement XML parsing on the C/C++ side, but it would be unfortunate if we were only stuck with one type of database solution. What if in the future we decide that Oracle would better serve our needs? Not that it will, considering the cost of Oracle (outside of developer packages). Although I think the XSLT might make it easier to support the various types of data processing that is going to be required.

Anyways those are problems for another day.

Even if it is awhile before you can get to working on the PXO server stuff, I would rather focus on the front end stuff and get it atleast up, so that when you do find time, you will be able to quickly test stuff if you need to. I will write it to support multiple export types of data (XML, HTML, CSV, INI, variable string), so that you have the freedom to decide how best to interface with the front end data.

* SSX-Killjoy goes back to coding...