Number 1 will just lead to a lot of problems. Number 2 however, while certainly the more difficult option in terms of FLHook programming, sounds much more rewarding in the long term for me.
I'd be willing to donate for a second server too if you'd go for option 2. I'm just a student, so don't expect much though...
The fact that Freelancer is Windows 7 compatible breathes a longer life to it and the other server's collectively add to the gaming experience. It would be a shame to see them let go.
Almost every good mod out there learned/borrowed something from other mods. Microsoft made the game and owns the rights--its wonderful as much has been allowed to be done with it has.
As Microsoft hasn't reigned in the servers I think its great to keep the spirit of collaboration going.
I'm happy to wait my turn to play or for traffic to ebb some and root for all the other servers out there. Tekagi's making dockable ships, other mods with graphics and models and systems and server help--all works together.
Perhaps our forum could be modified as well as those for the other, active servers to put a header atop all of them cross-advertising good mods out there. Maybe even begin to consider sharing models, expertise and resources on a case by case basis. A Modder's Coalition if you will.
' Wrote:There's an error in the thinking on the empty space on having two servers. Traders wouldn't be able to exploit the empty spaces - they wouldn't exist. Say Bretonia was on Server A and the Omegas were on Server B. You jump from Dublin to Omega 49 - you switch servers. You head around down to Omega 3 and come back in to Cambridge - you switch servers. As far as Server A is concerned, the Omegas don't exist, and you can't get there on that server.
Well, first of all you would only switch the servers, if one of them is full. The problem I'd see upcoming is the messaging queue. How often would it be synchronized to grant leakless communication?
Another problem: two players want to trade weapons and say: "Hey, let's meet in Tau-37!" Now both of them are in Tau-37 but they don't see each other... because they're on different servers. Only if a certain amount of system is hosted by each server you would prevent that.
But a dynamically universe would be better, I guess.
Away from that: I worship your effort on that Disco!
In theory the switching server while jumping to another system works but how about if the other server is already full? Do you just get a never-ending tunnel of light?
Unless it keeps trying to log you on the server forever (and there's a hazard as well)
I personally and professionally (computer programmer here) believe that it's a very far reach without the source codes and with the resources at hand (people are doing this on their freetime already) to ever make it reality.
Interesting idea, but the FL currently does not support even the idea of it. And modifications (and problems) might become not doable.
I just wish MS would release the source. Trying to make it utilize more cores than one would probably be a more viable road to take.
1. Who would write the program to link the two servers together? (I love the second idea)
2. Is it at all possible to write a new Flserver program? How complicated is it? If we applied to M$ for just the source code to FlServer, would we get anywhere?
@loogas
Did you have a look at the FLHook code? It is good stuff; I can see option two becoming a reality.
@seth
2) It would be possible to write a new FLServer. It would also be a tremendous lot of work. Not that I'd say no to trying if somone wanted to start such a project =P
/w
John Johnson - Master of Synth.Foods-Convoy|049
Hans Adler - Synth Foods escort wing
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.
' Wrote: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"
![[Image: Tink_Shadow.png]](http://junkers.worldstrider.info/images/Tink_Shadow.png)
![[Image: image.png]](http://xcomm.de/discosig/image.png)
![[Image: SethSig.png]](http://i130.photobucket.com/albums/p272/Sedrander/SethSig.png)
![[Image: ksp_sig.png]](http://www.haard.se/hosted/ksp_sig.png)
