Thread: Go to CODE BEIGE. (Server potentially in danger!)

I'm going to go ahead and move this into LoneStar Issues since, you know, that's what it is :P

A player can be in one of two states: connecting and in-game

When a player starts the server loading screen, it "connects" to the remote server and LoneStar is aware of that person. This is the moment when you see the message above the chat window where "SomeGuy connected".

When that person's loading screen goes away, then the state of the client changes to "in-game".


Now the complicated part...

LoneStar does reserved slots by steam ID. Clients don't connect with their steam ID already validated, Valve does that in the background while the client is connecting. So when a client first connects all LoneStar has is their IP address... that's it. As everyone's IP address is generally dynamic in nature, you can't really base the reserved slot system off of that as people's IPs would be constantly changing. So in other words lonestar has to let them connect because they might be a reservist, or they might not, there's just no way to know yet.

Eventually while the client is still loading the steam ID gets validated. Most of the time this occurs before the client is put in-game, but if the steam ID takes longer than normal to validate, then the client will get in-game before it validates and lonestar will kick them then. Basically the moment the client has a valid Steam ID, that's when it evaluates a person for a reserved slot.

So this whole conversation really hinges on: at what point in time does Valve deduct the 15 points?

1) If it's when a client first connects when LoneStar only has an IP address, then the entire reserved slot system will tank the ranking of the server and we'll have to come up with a new system.
2) If it's when a client gets put in-game, then most of the time LoneStar will kick the person before that point and we'll only occasionally lose 15 points due to the reserved slot system.

Maybe we should ask Robin Walker? Sending him an email couldn't hurt, but it might take a while for him to get back to us. In the mean time, we can bug him about having a Valve-endorsed reserve slot implementation.

Ah yes, that could be an issue.

I'd send the E-Mail. As Zen says, it couldn't hurt.

I just sent an email since I <3 you guys so much:

Dear Mr. Walker,

Hi! I'm a member of TexasTeamPlayers.com, and I play regularly on their TF2 server. They run an in-house admin mod called "LoneStar," and it has functionality for reserving 2 out of our 24 slots. It works like this: when our server is "full" at 22/24, and if a reservist joins, he enters one of the two buffer slots and boots out a non-reservist. Now, I'm concerned about our server, because before the ranking system, it didn't matter that our server didn't appear "full" when it really was "full," meaning at 22/24. It used to be passable that people trying to connect in those 2 slots were forbidden a connection. Now, I'm worried those people will show up on the ranking system as people who quit infuriated they join, instead of people that were simply refused a slot because of the way we're implementing reserve slots.

The implementation is explained in the post by Ewok here, and I will reproduce it in this email:

=====================
A player can be in one of two states: connecting and in-game

When a player starts the server loading screen, it "connects" to the remote server and LoneStar is aware of that person. This is the moment when you see the message above the chat window where "SomeGuy connected".

When that person's loading screen goes away, then the state of the client changes to "in-game".


Now the complicated part...

LoneStar does reserved slots by steam ID. Clients don't connect with their steam ID already validated, Valve does that in the background while the client is connecting. So when a client first connects all LoneStar has is their IP address... that's it. As everyone's IP address is generally dynamic in nature, you can't really base the reserved slot system off of that as people's IPs would be constantly changing. So in other words lonestar has to let them connect because they might be a reservist, or they might not, there's just no way to know yet.

Eventually while the client is still loading the steam ID gets validated. Most of the time this occurs before the client is put in-game, but if the steam ID takes longer than normal to validate, then the client will get in-game before it validates and lonestar will kick them then. Basically the moment the client has a valid Steam ID, that's when it evaluates a person for a reserved slot.

So this whole conversation really hinges on: at what point in time does Valve deduct the 15 points?

1) If it's when a client first connects when LoneStar only has an IP address, then the entire reserved slot system will tank the ranking of the server and we'll have to come up with a new system.
2) If it's when a client gets put in-game, then most of the time LoneStar will kick the person before that point and we'll only occasionally lose 15 points due to the reserved slot system.

=====================

Basically, we'd like to know when those -15 points kick in. As Ewok explained, we're going to have to change our implementation to prevent our server from tanking, and it would be great to know when exactly we get penalized.

Ideally, I'd think it would be spectacular if you guys could support reserve slots, but you've already given us so much that I feel guilty demanding more. That being said, we'd like some help so we can keep our reputation high; I don't even code for TTP, and I'm genuinely concerned for their reputation just because I really love the environment on the server.

http://www.texasteamplayers.com/index.php?topic=57547.0

They just explained how it works a little more. I'm still not sure that LoneStar's reserved slot is safe, but the explanation makes me less worried.