Adventures in the admin system from the X servers.

[Anomalous]

I like the idea of a standard set of ban reasons. I may implement this.

Other parts of it – well, we'll see. I can see some utility in sharing ban information across servers, for a start…

[kharnov]

A central ban database would be fantastic. It would aid in spotting potentially disruptive types so that they can be monitored accordingly.

As for stock ban reasons, they should come with default punishments that can be altered by editing the appropriate configuration. I can tell you from my experiences on US Main that people will go after you if they perceive you as being overly harsh, and I believe that this is due to the overwhelming amount of subjectivity in assigning bans, kicks, and mutes. If this is controlled by something objective, like a stock list of reasons and their associated punishments, then it becomes more uniform and it is solely up to the administrator in question to give out the appropriate sentencing. For example, I've seen administrators give between two hours to two weeks for a basenade. Why deal with that level of variability? Set a standard punishment, like six hours or a day, and be done with it. All administrators should be giving out the same exact punishments.

[Anomalous]

It's possible that the admins in question were taking into account their knowledge of the players at fault. Repeat offenders would get longer bans; a regular who's occasionally a problem may get a shorter ban. Unknown players – yes, default is appropriate.

It is easy enough to add a /ban variant which uses stock reasons; however, some work will need to be done to /showbans to allow for translation, and there'll be still more work to make the ban list shared.

Not just bans, either – forced spectate is mentioned above, and we already have that (though it's limited to the current game). And from there, it wouldn't be much to make denybuild and mute sticky – which can be done anyway with some tweaking of the training server's longstrip handling.

The big part of this is the shared list handling.

[janev]

Are we talking about official servers of all servers? Big difference.

How would a central ban database work? I imagine it could easily be abused. It don't fancy the idea of a disagreement with one admin on one server resulting in a blanket ban from every server. That is a bit too much power to give one person. Also I think server administrators are quite capable of assigning ban duration for themselves.

I agree there is much that can be done to improve admin tools just do not do it at the expense individual server owners control rights.

[Little*Butterfly]

Hi, when I said "centralised database", I meant it was for the X Group servers. Only our highest ranking administrators have access to this database, what we call "Globals". It was desirable to have this because of repeat offenders who jump from server to server and cause trouble. Now, for example, when we Handicap a player for cheating (Aimbot/Triggerbot/Wallhack), it is automatically reflected to other servers connected to the centralised database. It is not required to have a centralised databased for the Unvanquished project as a whole but the functionality should be there for gaming groups like the X Group, who manage multiple Tremulous 1.1 servers. Either this or a very different mechanism for storing ban information, which can be synchronised between multiple servers.

[Ishq]

Right. I don't have any plans of creating a centralized ban database for Unvanquished, except, maybe for all servers controlled by us, as you said.

[ViruS]

There's a possibility of storing the information on the same database for 1.1 with the unv server stats (ref: Sixthly's AA site) but I don't really see much point if the I.D. system is different. Having a centralized database for a number of unvanquished servers does seem reasonable, in a way it reflects on Valve's VAC automatic anti-cheat tool that they have. No system is perfect though, keep that in mind.

[Asvarox]

I actually think "centralized ban database" is an idea worth investigating. Server Operator would be able to choose servers from where his server would "fetch" bans, and use these data to at least warn online admins that "known" player is connecting

[ViruS]

That sounds more ideal the way you say it.

[Little*Butterfly]

I understand we're calling this mechanism 'ban database' for clarity but if something is being developed to this end, I'd like it to offer way more than simple bans. Again, speaking from our experience on the X group servers, we classify player restrictions in different categories:

1. Handicap
   A handicapped player means they're unable to deal any kind of damage and they take two-fold damage. This was our developer's way of dealing with repeat cheaters who use aimbots/triggerbots/wallhacks etc. Think of if as the way of shaming them rather than banning them. It is also a way to allow them to do other things like build if their appeal for cheating is under way.

2. Denybuild
   It was desirable to have full support for removing build rights from whole netblocks, to catch those evading deconners and intentional grief builders.

3. Forcespec
   When we have players who are real jerks by intentionally sabotaging their team, such as opening a critical door intentionally and telling the opposing team in public chat "hahaha.. door open!", we used to mute them. Then they resorted to deconning. When we added a denybuild, they resorted to intentionally blocking their teammates. We have someone very special who likes to "play" on our servers. We call him "Persi", which is one of his known handles. The problem with him is that he uses a spanish ISP which has a broad range of netblocks and low DHCP lease time. We can't ban everyone because we have regular players who log from the same ISP. What we did is put a global forcespec on as many netblocks we could identify. This way when a regular player logs on, they can't play until we manually add them to our whitelist. That was our mechanism of dealing with this abuse.

4. Mute
   Speaks for itself ;-)

This restrictions database does not need to be in MySQL. It can be a simple, password-protected, listener daemon equipped with a plaintext file in which player restrictions are stored. I'm thinking something like

{ serial: 05042013-001;
network: 192.0.43.0/12;
restrictions: nobuild, mute;
desc: example.com netblock restrictions;
}

{serial: 05042013-002;
network: 192.0.44.12/29;
restrictions: -nobuild, -mute;
desc: allow our friends from example.com to play;
}

Whenever a client connects, the Unvanquished daemon would query this listener daemon, supplying the IP of the connecting client and fetching the restriction class for this client. To extend functionality, certain admin levels are able to edit entries. It is a thought thrown out there :-) It needs further enhancements such as fool-proofing it to prevent entries such as 0.0.0.0/0 etc. I'm no developer so I'm sure you devs can some up with something even smarter.