Admin Announcement: Full server, what now?

[Cannon]

The problem is reverse engineering everything so that it works, without forgetting or omitting anything. Hell, if someone was to supply a verbose list of packet commands and parametres FL and the server use to communicate and what they expect back on each command, anyone could go start the project there and then...

So I am more inclined to support option number 2. It might take longer, but it will be worth it.

The main challenge for option 2 is hooking the direct play functions sufficiently to intercept all communications traffic to the server and re-directing it when needed to the second server, as well as emulation of connection/disconnect functions on the second server and stuff like that. I've found this to be an excellent way to improve my X86 assembly.

My goal is not to increase the number of players - although this might be possible but I believe there are some really really harded coded limits associated with the clientID which is also used as a NPC shipID in some circumstances.

My goal is to reduce the lag by spliting the server into two parts. With the careful selection of systems for each server, about half the players will be on one server and the other half on the other.

So if you're interesting hack away at the direct play messaging functions in dacom.dll. I've considered reverse engineering and rewriting this library in C and this might prove simpler...and a rewriting effort lends itself collaboration.

I'm working on this and have been doing it for a while...but it might never work.

---

Proud member of "the most paranoid group of people in the community"

Old Avatar #2 | Old Avatar #3