Reserved slots

[#156.Alpha]

I'd love to see reserved slots - or at least functionality allowing mod developers to include them int their mods - implemented. Any chance for that?

[IBIS Customer Service]

Mods already have this, see DAK. However the greater issue is that currently the game does not allow the ability to verify and kick a non reserved slot player until they have completed the connection process. The ability to grab and verify client steam id as soon as they join would be great as well as the ability to send them a popup message stating why they could not connect.

On Fri, Jan 4, 2013 at 9:49 AM, #156.Alpha <mike.r.d...@gmail.com> wrote:

I'd love to see reserved slots - or at least functionality allowing mod developers to include them int their mods - implemented. Any chance for that?

--
 
 

[#156.Alpha]

I used DAK on my server for some time, reserved slots basically don't work. When I think reserved slots - I mean that with player limit of, lets say 22 when server is full and reports full to game client - client still tries to connect and server allows it if steam id is recognized. Kicking players [for me at least] is not an option. 

[IBIS Customer Service]

I do not think you understand how reserved slots are supposed to work. Please see how it is implemented in every other game currently in existence. Reserved slots are a system where as players with said reserved slots are always able to join into a server and can not be kicked from said server for lack of a reserved slot. Thus players without reserved slots are kicked to make room for players with reserved slots. Consequently the reserved slots themselves are often for sale on popular servers and used as a monetization system to fund server expenses. For example all the longest lasting NS1 servers implemented such systems to sustain the costs of running servers for this great game for so many years. 

I am not sure how you think reserved slots work but let me clear up a common misunderstanding I have seen on the forums, reserved slots are not "additional slots". On a server running reserved slots all slots are intended to be reserved as to preserve the system described above. The reason it does not work as additional slots is b/c it is impractical as you can in theory have then servers growing in slot capacity to infinity to meet demands, however this is not logically possible. In addition any server would logically want to be able to use all its available slot capacity as to allow the maximum number of players to enjoy the game on their server as possible. However, by doing this the server then needs to kick someone to make room for a reserved slot player when one joins, thus resulting in the system described above.

Alternatively you may be complaining about the way the games connection system currently functions in that current reserved slot plugins are not able to verify the user until after they have loaded into the server resulting in a poor player experience. Combined with the inability to give users a popup message telling them why they can not join the server players get confused and think something is wrong on their end. Hopefully players will learn over time that servers with odd player counts use reserved slots or the game developers will add in the ability to use connect (serverip) to get into the server directly even when it is for example 20/20 as to remove confusion and allow for players to wait connect.

--
 
 

[Steve D]

There is more than one way to do res slots.

OldF's reserve slot implementation in NS1 was as follows:

Server reported 18 slots to steam browser.  Server would in fact allow 20 players, but only if you had a reserve slot would you be able to join and use those two slots.   Server would then report something like 20/18 in steam browser.  (The only bug was that you'd have to do it manually via "connect ls.oldf.net" in console as steam's server browser took the available slots and determined slot availability on its own.)  

Basically, our system allowed an extra two slots for reservists and admins, and after that nobody could join, res slot or not.  It was relatively hacked together, but this was the desired behaviour.  Kicking players is not desirable at all, particularly given how this game can require so much time investment and a team can rely on one player.

That is how we desire res slots to work.  Now granted, some server op's don't like this because they are paying per slot and want to get their money's worth.  Any system would require flexibility.

-Steve D

--
 
 

[#156.Alpha]

Thank you for both answers

@IBIS Customer Service: I disagree. Actually I started to reply when I saw @BigDXLT's answer - and thats exactly what I meant so no need to duplicate. I can just add that in actual implementation in NS2 it could be even better, i.e. like in my second post. 

[IBIS Customer Service]

I want to point out that the only reason that worked in hl1 was b/c the server was allowed to misreport the number of slots it actually had to the master server list. This was more of an exploit than anything. However what your asking for is already possible minus the exploit in DAK.

--
 
 

[IBIS Customer Service]

I want to point out that the only reason that worked in hl1 was b/c the server was allowed to misreport the number of slots it actually had to the master server list. This was more of an exploit than anything. However what your asking for is already possible minus the exploit in DAK.

[afdownes]

Just want to add, this is exactly how I want to see reserved slots implemented.

The following are completely unacceptable to me:

Kicking a player under any circumstance and at any time as part of this system.

There is no possibility of ever breaking any auto join mechanism (either NS2's, steam's or other).

That's about it really, if that BigDXLT has specified is implemented, I would be very happy.

[Brian Cronin]

This is something we definitely want to implement. We tried to get it in before release but ran out of time.

So the way I understand it, the best system would work as follows:

1. Server admin can define a number of reserved slots. If they have a 24 player server and wish to have 2 reserved slots, the number of "normal" players would be 22. They define the number of reserved slots and the Steam IDs allowed to connect to those reserved slots in ServerConfig.json.

2. In the server browser, you would see something like 20/22 (2) (num players/max players (reserved slots)).

3. If you try to connect to a server that is full but has reserved slots open, everything will act as if the server is full.

4. If you try to connect to a server that is full but has reserved slots open AND your Steam ID is allowed in a reserved slot, you will connect like normal.

5. If the server is completely full (reserved slots too), nobody under any condition can connect until a normal slot or reserved slot is open.

6. Under no condition will any player be kicked due to this reserved slot system (unless an admin chooses to kick somebody manually obviously)

7. A normal player connecting to a full server that has reserved slots open will not take up one of the slots during the connection process.

Does that all make sense?

--
 
 

[F E]

Makes perfect sense Brian. I'd love to see UWE implement this in NS2.

[Mike Brickner]

I think you did a good job summarizing into several requirements.  I would also like to see this integrated soon!

My only thoughts are:

2. Should it say 20/22 or 20/20 until the reserved slots are filled then 22/20?  Or when checking "hide servers that are full" will 20/22 still show or hide?  If people see 20/22 they may keep trying to connect -> poor experience.

3. When you say "everything will act as if the server is full" will it somehow say the remaining 2 slots are reserved so they don't think it is a bug/glitch?

[#156.Alpha]

I agree with F E

One thing to consider though: paragraph 2

Maybe to avoid confusion server browser should show 22/22 instead of 20/22(2) [in configuration case described] - I guess many new players could have some difficulties understanding it? Just a thought.

[#156.Alpha]

Nice timing +Mike Brickner :]

[Mike Brickner]

I think we're both on the same page there!  I don't know exactly how it should be done but I think we need a few more ideas before going with #2 as-is.

[Brian Cronin]

How about it displays "20/20 (2)" which indicates all "normal" slots are taken but there are 2 reserved slots which may or may not be taken. We may not even be able to display the reserved slots actually. We have already hit some limits of the server browser system we are using which may make it difficult or impossible to send the number of reserved slots.

"When you say "everything will act as if the server is full" will it somehow say the remaining 2 slots are reserved so they don't think it is a bug/glitch?"

No, it would just act like the server is full. If we display the reserved slots in a logical way (or hide those slots entirely), there shouldn't be any confusion on the browser's part.

--
 
 

[Mike Brickner]

Or 20/20 *0/2 etc.  Or what about not even showing the reserved slot information?  Maybe a different message is even possible telling reserved access people that "All reserved slots are currently full"

Would limitations of the server browser system be a steam limitation?  I'm not exactly sure how the server browser backend works.

Another question, will the server bump people into the reserved slots?  Ex. if I have reserved slot access and join when the server is at 19/20 *0/2, then someone else tries to join will the server deny them the connection and be at 20/20 *0/2 or move me up and let them join and then be at 20/20 *1/2?

[Peter Kormendi]

Brian, I appreciate the attention to this.

'Best system' is very subjective.  I've seen both implementations people described above frequently used and it would be nice if NS2 natively supported both.

However, I think the community could build the perfect reserved slot system with all kinds of options to serve all parties IF given the right tools.  DAK is almost there but it as I understand it, there are two pieces missing:
1. There needs to be a way a mod can 'lie' about the max player count on a server ( to hide slots used to perform the reserved slot logic )
2. There NEEDS to be a way to communicate a kick reason.  This is critical for more than just reserved slots

[Wyzcrak]

Peter has it exactly. Those two things. The maxslots lie prevents players from trying to join a server they can't. When players attempt to join despite that, the denial is clearly explained.

Given these two additional tools, the mod community will step up and provide solutions in addition to whatever comes stock.

Thank you for soliciting feedback (and thanks to everyone for articulating it), and best of luck with whatever you offer after considering it all.

[IBIS Customer Service]

Yes this is exactly correct! The "best" solution is the one that give us all the flexibility to do what we want and also experiment with new ideas that we have not even attempted yet. It is the ability to have multiple ways of doing the same thing that allows each server community to modify its settings to best fit the various demands of the players/admins ect.

--
 
 

[Peter Holcroft]

Brian,

You seem to understand this very well and you are exceeding my expectations by putting this into NS2 without requiring a mod. Although there different ways of doing reserve slots, I think this is best for the official version as it has minimum player disruption (no kicking). I would definitely use it this way.

I also would like to see the capabilities requested added so that modders can roll their own reserve slot system if they wish.

1. sv_visiblemaxplayers cvar or something like it to set the max players shown to the outside world.

2. Ability to give a reason when kicking someone.

Pete.

[Brian Cronin]

"Would limitations of the server browser system be a steam limitation?  I'm not exactly sure how the server browser backend works."

Yes, there are limitations on what and how much we can send. And on top of that, some players are having connection problems after joining a server through the server browser due to the number of ping requests initiated by the browser.

"Another question, will the server bump people into the reserved slots?  Ex. if I have reserved slot access and join when the server is at 19/20 *0/2, then someone else tries to join will the server deny them the connection and be at 20/20 *0/2 or move me up and let them join and then be at 20/20 *1/2?"

This is a good point. I would want to make it so that a reserved slot is only used when needed. So a player that is in the reserved list will take up one of those slots if the server gets full.

In regard to the 2 features needed for better mod support, I will try to get those implemented while working on this.

Thanks everyone. I have a much more clear picture of how everything should work.

--
 
 

[Wyzcrak]

I can't believe it's been almost six months since we discussed this. Feels like yesterday.

I still have a need to lie to server queries about the number of public slots. If UWE bakes in a reserved slots solution, I do hope it remains an option, and I hope the public slots lie option is made available as well, for server operators running their own solution.

But, at the very least, that ability to lie is huge. It seems like such a simple thing to request. As a career software developer, I suspect it's more complicated than my perspective makes it seem. ;)

Enjoying 250. Thanks for all the fun!

[IBIS Customer Service]

What would likely be a lot faster to make which would be nice is the ability to kick people sooner when they do not have a reserved slot so they are not trying to load for a few min just to get booted.

--
You received this message because you are subscribed to the Google Groups "Unknown Worlds Server Operators" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uwe-server-op...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.