possible central character server?
my roommate and i have been playing freelancer a lot, and we love it.
unfortunately, we don't love the servers. many lag, go down, or are great, but only up for a few days, so we end up starting over again, again, again...and many more agains.
i started looking where freelancer saves its characters, which is in:
My Documents\My Games\Freelancer\Accts\MultiPlayer
Or, more appropriately, where ever the my documents link points to - including network shares, like \\Biolution\flaccts\, or a drive that is mapped to a network location.
so i changed the location of 'my documents' to point to a network share on another computer and viola - it saved there. we had just found a primitive way to create a central character server.
Unfortunately, though, there are a lot of drawbacks that i've yet to figure out a good solution to:
(central character server henceforth known as CCS)
1) security - for a true central character server, the server would have to give read/write access to anonymous people running their own private server. This creates 2 problems: A) character server security could be compromised with all the security holes inherent in windows, and if someone created a server, then hacked their character on their server, they would then have that hacked character on all servers.
The only solution i can think of for this is to only allow certain servers to use the CCS. The criteria for which could would be based on who is running the CCS. This doesn't solve all problems, but limiting who can save characters on the CCS to just trusted servers/operators reduces the chance of someone breaking into the CCS, or creating a hacked character
2) CCS Load - I don't know how or when the server saves your character, but i'm guessing anytime you are disconnected, dock, undock, or killed. If you think about it, thats quite a bit of saving on the CCS's part if its connected to a whole community. There are probably hundreds of people docking and undocking, in addtion to disconnected and being killed. The load from saving on the CSS's part is probably minimal. For all i know, though, the server may save or read the character file more often than that. IMHO - I don't have a clue how bad the load would be, but i'm guessing it would be minimal compared to latency.
3) CCS lag - Usually with a MMO game, the character server are on a local lan with the gameplay servers (just guessing, but it makes perfect sense, right?), so the time for the character and gameplay server to comminicate is almost nothing. With this method of CCS, most gameplay servers would have to wait much longer for a response from the CCS. How long would depend on the respective connections, but i'm guessing that it would greatly increase the load times whenever a character is saved. If the character is saved when docking/disconnecting/dying, this isn't really a problem (you'd just wait longer before entering a new region, essentially). If it saves more often, however, a player could experience a lot of lag in the middle of a firefight, and that is a very bad thing.
4) Server configs - This is the most frustrating part of the whole deal. The server config file is in the same directory as the accounts. When you start the gameplay server, it will read the server config from the CCS server and load/change that as the default. This makes the use of the /c switch useless, since your server will have the same name as all the others, making it impossible for us humans to find the server we played on last. This can be overcome by not using the /c switch, but requires the server to manually be named, info'd, and started, which is annoying and a hassle. If there were more switches (and i'm sure there are) for the server, such as ones that would specify the name or what config file to use, this wouldn't be a problem.
EDIT (addressing soemthing stinger brought up in a previous thread): A couple more disadvantages would be that the gameplay server would be reading the accounts.cfg fil from the CCS, which holds the character bans. This means that if anyone can access it, anyone can ban anyone, practically forcing the CCS to only be accesible to trusted servers. Also, this file *probably* couldn't be read locally on the gameplay server because it could become out of sync with the CCS file, and characters wouldn't be able to cross servers (that is, assuming there is a switch to specify what accounts.cfg file to read).
Finally, my disclaimer: I'm not some guru at FL or computers. I just toyed with the FL server and used some logic. Most of my guesses about latency and load on the CCS are exactly that - guesses. But i'm confident that, provided a few command line switches are discovered (mainly, server name or config file), that this is a possible way for a centralized server for characters.
Edited by - biolution on 28-02-2003 09:06:05
unfortunately, we don't love the servers. many lag, go down, or are great, but only up for a few days, so we end up starting over again, again, again...and many more agains.
i started looking where freelancer saves its characters, which is in:
My Documents\My Games\Freelancer\Accts\MultiPlayer
Or, more appropriately, where ever the my documents link points to - including network shares, like \\Biolution\flaccts\, or a drive that is mapped to a network location.
so i changed the location of 'my documents' to point to a network share on another computer and viola - it saved there. we had just found a primitive way to create a central character server.
Unfortunately, though, there are a lot of drawbacks that i've yet to figure out a good solution to:
(central character server henceforth known as CCS)
1) security - for a true central character server, the server would have to give read/write access to anonymous people running their own private server. This creates 2 problems: A) character server security could be compromised with all the security holes inherent in windows, and if someone created a server, then hacked their character on their server, they would then have that hacked character on all servers.
The only solution i can think of for this is to only allow certain servers to use the CCS. The criteria for which could would be based on who is running the CCS. This doesn't solve all problems, but limiting who can save characters on the CCS to just trusted servers/operators reduces the chance of someone breaking into the CCS, or creating a hacked character
2) CCS Load - I don't know how or when the server saves your character, but i'm guessing anytime you are disconnected, dock, undock, or killed. If you think about it, thats quite a bit of saving on the CCS's part if its connected to a whole community. There are probably hundreds of people docking and undocking, in addtion to disconnected and being killed. The load from saving on the CSS's part is probably minimal. For all i know, though, the server may save or read the character file more often than that. IMHO - I don't have a clue how bad the load would be, but i'm guessing it would be minimal compared to latency.
3) CCS lag - Usually with a MMO game, the character server are on a local lan with the gameplay servers (just guessing, but it makes perfect sense, right?), so the time for the character and gameplay server to comminicate is almost nothing. With this method of CCS, most gameplay servers would have to wait much longer for a response from the CCS. How long would depend on the respective connections, but i'm guessing that it would greatly increase the load times whenever a character is saved. If the character is saved when docking/disconnecting/dying, this isn't really a problem (you'd just wait longer before entering a new region, essentially). If it saves more often, however, a player could experience a lot of lag in the middle of a firefight, and that is a very bad thing.
4) Server configs - This is the most frustrating part of the whole deal. The server config file is in the same directory as the accounts. When you start the gameplay server, it will read the server config from the CCS server and load/change that as the default. This makes the use of the /c switch useless, since your server will have the same name as all the others, making it impossible for us humans to find the server we played on last. This can be overcome by not using the /c switch, but requires the server to manually be named, info'd, and started, which is annoying and a hassle. If there were more switches (and i'm sure there are) for the server, such as ones that would specify the name or what config file to use, this wouldn't be a problem.
EDIT (addressing soemthing stinger brought up in a previous thread): A couple more disadvantages would be that the gameplay server would be reading the accounts.cfg fil from the CCS, which holds the character bans. This means that if anyone can access it, anyone can ban anyone, practically forcing the CCS to only be accesible to trusted servers. Also, this file *probably* couldn't be read locally on the gameplay server because it could become out of sync with the CCS file, and characters wouldn't be able to cross servers (that is, assuming there is a switch to specify what accounts.cfg file to read).
Finally, my disclaimer: I'm not some guru at FL or computers. I just toyed with the FL server and used some logic. Most of my guesses about latency and load on the CCS are exactly that - guesses. But i'm confident that, provided a few command line switches are discovered (mainly, server name or config file), that this is a possible way for a centralized server for characters.
Edited by - biolution on 28-02-2003 09:06:05