Server list is a bit archaic.

[/dev/null]

Tron likely shouldnt wait for a full list of the servers to start pinging and displaying them, it just adds a needless wait to get in the game. Especially when the master servers are being slow/stupid

[aP|Nelg]

After hitting enter but before it starts connecting to the master, hit escape and it should bring you right to the server list.

However, not downloading a brand new list from the master servers can cause new servers to not be displayed...

[Magi]

I'm prepared to be put to the cross for this post, but Durf has a pretty nifty /servers command in his servers that basically is an ingame server browser that then allows players to do /goto servername and it sends them there, saves a lot of time for players moving servers or just seeing who's online every now and then without leaving a server. Of course I wouldn't say get rid of the server list entirely because you still need to be able to find your favorite server if no one is in it. I just wonder how hard it would be to make the in-game server browser a command that all servers/players could use

[ConVicT]

Seriously, Magi, fck the Durf haters, the guy's done more for this game than most people.

Yes, it would be nice to have that in every server.
Durf was kind enough to share his script with me, for my server, so I'm pretty sure he'd be up for letting everyone use it.
I like that you don't have to leave the server to check which servers are active, or if you're friends are playing or not.

[Lucifer]

Tron likely shouldnt wait for a full list of the servers to start pinging and displaying them, it just adds a needless wait to get in the game. Especially when the master servers are being slow/stupid

You obviously haven't played any recent games. They're all the same.

It's the internet. Deal with it.

[Light]

[You obviously haven't played any recent games. They're all the same.

It's the internet. Deal with it.

The master server sends out the list in parts, right? His idea would probably be nice, though I don't think the master provides you with much more than a server address and port. That would make the list a little less useful until it pings, and having both at once could be much worse for people. So, it sounds nice, but seems unrealistic. To make it happen, you'd be using a little more bandwidth and server resources, which I doubt is the direction they're going to go.

Just my thoughts. Maybe someone could modify a master server & client and see how things go? I'm sure if you got it to turn out properly it would be taken in, but seems like it'd be difficult to make clean for people with bad internet.

[/dev/null]

Tron likely shouldnt wait for a full list of the servers to start pinging and displaying them, it just adds a needless wait to get in the game. Especially when the master servers are being slow/stupid

You obviously haven't played any recent games. They're all the same.

It's the internet. Deal with it.

Its DOS 3, deal with it.

Shut your whore mouth.

[Z-Man]

This has been on my mental TODO-list for a while. What happens now:
-client logs in to master with full connection negotiation stuff
-client asks master for list
-master slowly gives out the list
-master disconnects client
-client starts pinging and displays the list

What I´d like it to be:
-client sends all masters a single "hey! gimme the server list" packet
-client immediately shows the broser filled with servers it already knows, pings them
-masters start slowly giving the client the list (about 10 servers per UDP packet should not stress the connection too much)
-client integrates the servers it receives into the list on the fly, pings the new ones

Well, and some bookkeeping. The masters should stop sending servers to the clients at some point, obviously, so while the client is on the browser, it would send the masters "please keep feeding me servers" packets, and it would also send "please stop sending me servers" packets when it actually joins a server. And when it already is receiving servers from two different masters and a third joins in.
It's quite possible, not too hard, fits well with the network architecture already in place. It's just not very high priority.

[Lucifer]

[You obviously haven't played any recent games. They're all the same.

It's the internet. Deal with it.

The master server sends out the list in parts, right? His idea would probably be nice, though I don't think the master provides you with much more than a server address and port. That would make the list a little less useful until it pings, and having both at once could be much worse for people. So, it sounds nice, but seems unrealistic. To make it happen, you'd be using a little more bandwidth and server resources, which I doubt is the direction they're going to go.

Just my thoughts. Maybe someone could modify a master server & client and see how things go? I'm sure if you got it to turn out properly it would be taken in, but seems like it'd be difficult to make clean for people with bad internet.

Actually, if his main complaint is the UI blocking while loading the list, I have the same complaint. For me, though, it could be fixed by simply (heh) showing the cached list, pinging the cached list, and downloading the server list in the background. Maybe send a hash of the servers the client already has (sort by IP, do an md5sum) to the master and if the server list hasn't changed, the master server doesn't send anything.

Better yet, heh, Z-man, more complexity! Have the master server save diffs of the list, like bzr does. Version them, so anytime the master drops a server or a server shuts down, the list gets a new version with that server removed (might wait a few minutes to see if other changes happen). Then do a diff and store the diff needed to get to the previous list. When a client logs in to the master, it'll say "Hey, I have version 4386" and the server says "We're on 4389 right now, here's the changes". The master would periodically purge older versions (say a week old or so), and if the client requests a version that doesn't exist anymore, it gets the full current list.

Of course, you can skip all that by having the client upload it's cached list, and the master sends back only what's different.

On a side note, if something like this were to happen, would it be reasonable for the master server to try to track clients, and have clients keep their socket to the master open? You know, ping them periodically to see if they're still online, and if they are, anytime the server list changes, send them the change? I can't see that affecting their in-game pings, since it's minimal traffic, but doing a little NSA work on the clients could yield useful data to mine later for, I don't know, some reason. Give clients the option to opt out, yadayada.

[Light]

Actually, if his main complaint is the UI blocking while loading the list, I have the same complaint.

Oh, I wasn't disagreeing. It would be much nicer the way he's wanting it, which is what I'd love to see as well. Many games show you what is there as they go, so I know it's possible. I just assumed it was this way for a reason.

[Z-Man]

Better yet, heh, Z-man, more complexity! Have the master server save diffs of the list, like bzr does.

Scan the source for transactionID. That was supposed to be something like that. It never worked properlty and when we added multiple masters, the idea was killed; to work properly in that context, either the masters would have to sync their transactionIDs or the clients would need to remember one transactionID per master reliably even when we switch them around, and occasionally masters get reset... Come to think of it, since the masters exchange server information, syncing the transactionIDs would now be possible.

On a side note, if something like this were to happen, would it be reasonable for the master server to try to track clients, and have clients keep their socket to the master open?

The network system is not prepared to hold two connections at once. Occasional one-shot information packages would be possible. Useful, for example, would be if clients tell the master some experience metrics after a session on a server; how long did the session last, how much of that was spent playing, was the player kicked or left on its own, kills and deaths experienced, and how long the player has played total so far. With that info, we could gather actual data on which server is right for newbies or veterans.
I would not send personal information there, but of course, in principle, the IP can be logged.

Connecting to the masters is currently blocking and that's very hard to change (not impossible); but once the connection is established, I think the client could already show the server list and start pinging. That would have the advantage of not requiring master server code changes.

[Lucifer]

Scan the source for transactionID. That was supposed to be something like that. It never worked properlty and when we added multiple masters, the idea was killed; to work properly in that context, either the masters would have to sync their transactionIDs or the clients would need to remember one transactionID per master reliably even when we switch them around, and occasionally masters get reset... Come to think of it, since the masters exchange server information, syncing the transactionIDs would now be possible.

Oddly, I remember seeing that in there at one point and wondering what it was.

The clients wouldn't have to remember a transactionID per master, they only have to remember the last one they got. Theoretically, the master should have the current one, regardless of which one they talk to. If the master's transactionID is -1 or more of the client's, then it could refer the client to another master, and the client can pick a new one using the current algorithm, just subtracting the one it just talked to. If the master's transactionID is the same as the clients, nothing done (the client uses the cached list), because the master has no way to know if there's a new list available.

The network system is not prepared to hold two connections at once. Occasional one-shot information packages would be possible. Useful, for example, would be if clients tell the master some experience metrics after a session on a server; how long did the session last, how much of that was spent playing, was the player kicked or left on its own, kills and deaths experienced, and how long the player has played total so far. With that info, we could gather actual data on which server is right for newbies or veterans.
I would not send personal information there, but of course, in principle, the IP can be logged.

To ensure anonymity, perhaps a sha or md5 hash of the IP can be saved instead, so we still get a primary key, but we don't save IP information.

The real trick there, the one that'll require lots of coding, is syncing THAT information across master servers. Of course, it's worth pointing out that bazaar and other VCS have APIs that can be used when you need to sync this sort of information.

Connecting to the masters is currently blocking and that's very hard to change (not impossible); but once the connection is established, I think the client could already show the server list and start pinging. That would have the advantage of not requiring master server code changes.

Connecting is generally pretty quick, so that shouldn't be a big problem. Especially if that turns this problem from "OMG, that would be so many changes and I don't have time for them!" into "Oh, yeah, I can do this on a day off sometime".

[Z-Man]

Hashing IPs isn't adding too much protection, at least not for v4. The address space is just too small, especially if you consider that just running a regular game server, you can harvest all of the IPs of all players, you just don't know who they belong to. No matter: I don't personally consider IPs on their own as terribly protection worthy. Sure, I won't blurt out some random dude's IP, but my master logs have been collecting them the whole time (I delete them after a bit, or rather forget about them before a server gets a reformat). No matter: For this application, storing IPs would not be required, I think. I just wanted to point out that it's impossible to keep the IP a secret from the system with reasonable effort.

Connecting is generally pretty quick, so that shouldn't be a big problem. Especially if that turns this problem from "OMG, that would be so many changes and I don't have time for them!" into "Oh, yeah, I can do this on a day off sometime".

Yeah

[/dev/null]

Well that ******* idea went south. Practice more slugslimery versions of dont have to do something useful though. I guess im glad to help/