• Please make sure you are familiar with the forum rules. You can find them here: https://forums.tripwireinteractive.com/index.php?threads/forum-rules.2334636/

Final Release [Mutator] ReservedSlots (white-listed)

Ducky

Super Moderator
May 22, 2011
6,358
237
Netherlands
ReservedSlots (white-listed)

Revision 134 - Released August 12, 2013


Introduction

This mutator allows server admins to reserve slots for clan members or privileged players.

Web-Admin mutator settings
All configuration properties can be edited directly from out of the web-admin interface.

Here are a few screen shots of the improved (and now also working in multi-admin setup) web-admin interface for this mutator:

The General Settings tab:
This tab contains all behavior settings for this mutator.
GeneralSettings.png


The Privileged Players managment tab:
Here you can:
  • Add members. This can now easily be done by selecting the member from a drop down-list.
  • Delete members.
  • Edit members.
  • View who's currently on the server (member details will be marked in bright green).
  • Fast lookup of players steam profile by clicking on their steam id in the member table.
PrivilegedPlayers.png


The mutator also has a feature where server admins can lock the mutator settings. This prevent that other admins can make changes to the mutator settings. This locking can be achieved by clicking on the lock button (located on the top-right button panel). You will be asked to fill in a password to lock the mutator. The entered password will grand you the rights to change the mutator settings. The settings will only be read-only if not signed-in.

Password enter screen:
Locking.png


Screen when not signed-in:
SignedOut.png


Screen when signed-in:
SignedIn.png


Those last three screens don't add much to the mutator itself, but I displayed it to show a feature which comes with a web-admin template class that I developed. The complete web-admin page for this mutator is written using that template class. It makes it very easy to create your own web-admin pages without having to have any knowledge about HTML, JQuery or JavaScript. However you can still use them to give a more dynamic behavior to the settings screen. The mutator web-admin template package is available for other coders. More details plus download info can be found here.

Important:
If you did run an older version of this mutator, then it might be that you will not see any of the mutator settings. In that case you will need to look-up and open the ROWebAdmin.ini file on your server and delete all the lines that start with HasSettingsCache. Those lines should be present in the [WebAdmin.QHDefaults] section of that ini file. Don't worry about throwing away lines for other mutators. They will be recreated as soon as you restart the server.


Mutator commands (only available for administrators):

  • Mutate RSM Help
    Displays this mutator command list.
  • Mutate RSM AddByName <name>
    Adds a privileged player by name to the UniqueMemberIds list.
    The player must be currently on the server.
  • Mutate RSM AddById <id>
    Adds a privileged player by unique ID to the UniqueMemberIds list.


Where to download the mutator (for server admins):

The mutator can be downloaded from this location:
https://dl.dropboxusercontent.com/u/54368035/Mutators/ReservedSlots/ReservedSlots-Rev134.zip


How to install the mutator (for server admins):


  1. Download the mutator from above location
  2. Extract all files from the archive
  3. Place the next files in your ROGame\Config folder on your server:
    • config\defaultreservedslots.ini
    • config\ROReservedSlots.ini
  4. Place the next files in your ROGame\BrewedPCServer folder on your server:
    • BrewedPCServer\ReservedSlots.u
    • BrewedPCServer\IReservedSlots.u
    Note:
    If you have a redirect, then it's advised to also place the ReservedSlots.u and IReservedSlots.u file on your redirect. It will prevent ping spikes when players connect and the server needs to upload those files to the clients. Unlike with map files, the .u files should NOT be renamed to .upk
  5. Restart your server(you need to do this or else the server will not find the mutator)
Note:
It can be that the IReservedSlots.u files do already exist on your server. In that case you need to overwrite them.

How to activate the mutator (for server admin):

  1. Open your servers web-admin tool
  2. Go to the Change Map page
  3. Select your game type and map
  4. At the Additional URL variables field you add ?mutator=ReservedSlots.ReservedSlots
  5. Now load the map
You can also add ?mutator=ReservedSlots.ReservedSlots to your command line.

If you have more than one mutator running on your server, then you can load them with:
?mutator=ReservedSlots.ReservedSlots,Mutator1.Mutator1
It doesn't matter which mutator is on the first position.

Compatibility note:
ReservedSlots does not replace any vanilla RO2 class instance.

Source code:
The source code of this mutator can be downloaded from:
svn://62.163.53.115/ReservedSlots/trunk/
An SVN client is required to download the sources (for example TortoiseSVN).
The files are password protected. If you want access to the sources, then please PM me and you will receive a reply with sign-in details.

Many thanks to:
For arranging tests on their servers.
 
Last edited:
Just for clarification, this mutator only allows (assuming the default of 6 reserved slots on a 64 slot server) 58 non-privileged players on at any given time, and forces those last 6 slots to remain empty until a privileged player joins. Is that correct?

If so, would it be possible to change things up a bit so that it allows the game server to fill to capacity, let's say 64 players in 64 slots, then should a privileged player join a full 64/64 server, have it kick a non-privileged player to make room?
 
Upvote 0
Just for clarification, this mutator only allows (assuming the default of 6 reserved slots on a 64 slot server) 58 non-privileged players on at any given time, and forces those last 6 slots to remain empty until a privileged player joins. Is that correct?

Correct.

If so, would it be possible to change things up a bit so that it allows the game server to fill to capacity, let's say 64 players in 64 slots, then should a privileged player join a full 64/64 server, have it kick a non-privileged player to make room?

Yes, that would be possible, but in then still only 63 could join without restrictions. If allowing 64, then a privileged player would be number 65 and then the server is already full and a join attempt would never reach the mutator.

But in case of kicking a player, then the mutator will need to select a kick candidate. How should that candidate be selected? Any thoughts?
And, should it keep track on who was kicked in the last days to prevent that always the same victim will be kicked?

I need some feedback/thoughts here before I create a kick-bastard :D
 
Upvote 0
lol

Keeping 1 slot permanently reserved seems perfectly fine to me. Personally, we run 32-slot servers, so we could just increase them to 33 slots with a mutator like this and it would all be the same.

Obviously you want to make sure it doesn't kick any other privileged players, so then I tend to lean towards kicking whatever non-privileged player has been their the shortest amount of time. And yeah keeping track in the short term to make sure the same poor guy doesn't get the boot too often would be nice. I can't think of anything else but I'll ask my mates and see if they have any other ideas/suggestions to throw in.
 
Last edited:
Upvote 0
we run 32-slot servers, so we could just increase them to 33 slots with a mutator like this and it would all be the same.

I'm not too sure about that. I'd have to confirm, but I think that using 33 slots instead of 32 would trigger the 64-slots maps, like using 17 slots triggers the 32 slots maps.

I tend to lean towards kicking whatever non-privileged player has been their the shortest amount of time.
Another parameter to consider, could be idle players... If a player is idle for more than x seconds, he would get on the priority list for kicks.
 
Last edited:
Upvote 0
I'm not too sure about that. I'd have to confirm, but I think that using 33 slots instead of 32 would trigger the 64-slots maps, like using 17 slots triggers the 32 slots maps.

You are correct. That would indead trigger the 64 slots map version.

Another parameter to consider, could be idle players... If a player is idle for more than x seconds, he would get on the priority list for kicks.

Sounds good. Especially because RO2 already does keep track of AFK players for that "kick on AFK for more than xxx minutes" server side option. The only difference that need to be added is to kick only if a privileged member tries to join and the server is full.

GrimReality said:
Obviously you want to make sure it doesn't kick any other privileged players

Of course. Privileged players should not be kicked. Not even if they are AFK or make it configurable like a separate Max Allowed AFK Time for privileged players and one for non-privileged players.

GrimReality said:
so then I tend to lean towards kicking whatever non-privileged player has been their the shortest amount of time. And yeah keeping track in the short term to make sure the same poor guy doesn't get the boot too often would be nice. I can't think of anything else but I'll ask my mates and see if they have any other ideas/suggestions to throw in.

There is one drawback on kicking the one which is shortest on the server and not kicking the same guy twice in a row. What if the "shortest guy" gets kicked and then after few minutes rejoins? He will be sure not to be kicked again. This can become a complicated evaluation of several conditions. I will have to keep a lot over user specific statistics :(

How about this rule:

If privileged player joins while server is full,
then kick the last non-privileged player that joined with a ping above X
If none found, then kick the last non-privileged player on the score board

And of course trying to prevent picking out the same victim over and over again.

An other point is that we should try to prevent to kick new players, or else they might leave RO2 for good. And that is the last that we want. This means that we need to evaluate the players honor level. If it's below 20 (or make it configurable), then only kick if there really is no other candidate.

This way a new player can secure his slot by doing his best to gain up his score.

Any thoughts?
 
Upvote 0
Hi Ducky!

Is it correct that if I set up 10 reserved slots on a 64 server, I just can get a maximum 54 of public players on it?
Or is it possible to reserve 10 slots on a 64 server and 64 people can play and once a privileged player join, another one gets a kick?


Best regards & Thank you for that awesome mutator, which we're using since you released it ;=)

Blitzkrieg-Bob
 
Upvote 0
Hi Ducky!

Is it correct that if I set up 10 reserved slots on a 64 server, I just can get a maximum 54 of public players on it?

That is correct.

Or is it possible to reserve 10 slots on a 64 server and 64 people can play and once a privileged player join, another one gets a kick?

That is also possible. If you set Kick A Public Player If No More Empty Slots (can be found on the Kick tab of the mutators web-ui page), and keep the Number Of Reserved Slots at 0, then 63 public players can join at all time. As soon as a privileged player joins while the server has 63 players, then one of the pubs will get kicked.

Best regards & Thank you for that awesome mutator, which we're using since you released it ;=)

Blitzkrieg-Bob

Your welcome and thank you for using it.

The mutator has one bug though which I only recently detected. If a player tries to join the server while there are no more public free slots, or if he get kicked because of a joining privileged player, then the kick message only displays an OK button. :(
 
Upvote 0
Hi Ducky,

I have recently installed your mutator on our server yet
All configuration properties can now be edited directly from out of the web-admin interface. The settings can be found on the mutator page.
these options are not available in the webadmin interface. The mutator is running though as it is listed under current game.

EDIT:
How do I list the uniqueIDs for priviliged players, f.e. like this:
UniqueMemberIds=0x011000010XXXXXXX, 0x011000010XXXXXXX, 0x011000010XXXXXXX ?
 
Last edited:
Upvote 0
Hi Ducky,

I have recently installed your mutator on our server yet these options are not available in the webadmin interface. The mutator is running though as it is listed under current game.

Yes they are. They can be found on the Mutator page of the web-admin.

EDIT:
How do I list the uniqueIDs for priviliged players, f.e. like this:
UniqueMemberIds=0x011000010XXXXXXX, 0x011000010XXXXXXX, 0x011000010XXXXXXX ?

In the mutators ini file it should be like:
Code:
UniqueMemberIds[0]=0x011000010XXXXXX1
UniqueMemberIds[1]=0x011000010XXXXXX2
UniqueMemberIds[2]=0x011000010XXXXXX8
 
Upvote 0
Thank you for the reply Ducky,


I had previously managed to add privileged players via the command line commands.
They were added like this to the ini file:
UniqueMemberIds=0x011000010025XXXX
UniqueMemberIds=0x011000010025XXXX
UniqueMemberIds=0x011000010000XXXX
UniqueMemberIds=0x011000010549XXXX
UniqueMemberIds=0x0110000102A2XXXX
UniqueMemberIds=0x0110000103C8XXXX
UniqueMemberIds=0x011000010029XXXX
UniqueMemberIds=0x0110000102B1XXXX

They are greeted by the server correctly as well, but the admin interface still lacks the option to configure the mutator. The box where I am supposed to select the mutator is just empty.
 
Last edited:
Upvote 0
Ok, I've seen that before. It sometimes happens in RO2 for no clear reason. You can manually correct this by opening ROWedAmin.ini and search for this line:
Code:
HasSettingsCache=(ClassName="ReservedSlots.ReservedSlots",hasSettings=False)

and change it into:
Code:
HasSettingsCache=(ClassName="ReservedSlots.ReservedSlots",hasSettings=[B][COLOR="Yellow"]True[/COLOR][/B])

Edit:
You are correct with this:
Code:
UniqueMemberIds=0x011000010025XXXX
UniqueMemberIds=0x011000010025XXXX
UniqueMemberIds=0x011000010000XXXX
UniqueMemberIds=0x011000010549XXXX
UniqueMemberIds=0x0110000102A2XXXX
UniqueMemberIds=0x0110000103C8XXXX
UniqueMemberIds=0x011000010029XXXX
UniqueMemberIds=0x0110000102B1XXXX

The UniqueMemberIds[x] that I added are not needed. That was my mistake.
 
Last edited:
Upvote 0
Direct link to the screenshot: http://i184.photobucket.com/albums/x41/Werg78/remote_zps6589975c.jpg

Yes all files are in the correct folders, just double checked again and they were all were they are supposed to be from the beginning. I am really clueless at what is amiss here.

EDIT:

This is my ro2serverstart.bat

Code:
start .\Binaries\win32\rogame te-Apartments?minplayers=40?MinNetPlayers=0?maxplayers=64?mutator=ReservedSlots.ReservedSlots -seekfreeloadingserver
 
Last edited:
Upvote 0