Player Police 2: The Design

What do you want to see in Armagetron soon? Any new feature ideas? Let's ponder these ground breaking ideas...
User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Player Police 2: The Design

Post by Lucifer » Thu Jan 05, 2017 3:11 am

First off, this is not the thread to hash out what player behavior will be regulated specifically. But we will need to talk about what moderators can and can't do because that's the nature of the thread. Moderator guidelines and community standards belong in a different thread that someone should totally start.

So, I've actually been thinking about this off and on for the year or so that it's been proposed and added to the feature list for 0.4. As a result, I actually have a relatively mature design that's all in my head, never been written down, and thusly never shared. Sorry about that. ;)

Politically, I believe the Player Police guidelines should be part of the moderator guidelines here on the forums. I think this because I expect that any server that is blessed as an "Official" server must subscribe to the player police and adhere to the policies involved, unconditionally. Private servers that wish to benefit from the system will be free to customize it according to their needs, but official servers cannot customize the Player Police. Therefore, behavior and expectations will be the same between the forums and official servers, but enforcement will necessarily be different because they are different mediums of communication.

I believe that all Player Cops must also be forum users. They must authenticate through the forums to be able to do their jobs as Player Cops, and any problems with individual Cops can and should be brought here and discussed openly. And the top of the chain of command for all official servers and these forums will be the Evil Triumvirate, but any decision to sanction a cop will still affect private servers using the system.

How is the above two paragraphs a part of design? I won't answer that right now, but it's obvious overlap between the other post someone needs to make.

Ok, how is the system going to be put together?

First, we'll need the resource repositories to host the config files and mirror them with each other. Banlists need to be synced amongst all official servers and the repo's, private servers need to be able to at least sync one-way (from the repo's to the server), but should sync both ways.

Config files

The config files must be designed as a hierarchy.

First, there will be a base config file, appropriately named "Player_police_base.cfg". All it will have in it is this:

Code: Select all

INCLUDE Player_police.cfg
INCLUDE Player_police_users.cfg
INCLUDE Player_police_local.cfg
This file will be included with the distribution of the game, but by default will *not* be included in any server config files. The system must be opt-in. We will have the line at the appropriate place and commented out, with a comment documenting what you get when you enable it, as we do with all other config options.

This file also has to be included in everytime.cfg to ensure that changes to the system propagate.

Player_police.cfg

This config file will define the access levels and what each access level can do. It is not to be edited by anybody using the system because it will be provided for you from the resource repositories, and any edits you make will be destroyed when the next update comes.

Player_police_officers.cfg

This config file simply lists the Player Cops and what access level they have. Since it's included before Player_police_local.cfg, private server operators can modify it, but again, official servers cannot override this file.

Player_police_local.cfg

Private server operators can use this file to further customize their use of the system. Official servers can only customize if needed for technical reasons. This is the file you can edit to modify your use of the system. Also, official server operators can use this file to temporarily disable a Cop from being able to act if that operator believes the Cop's forum account has been compromised.

Syncing config files

Config files must be synced regularly, at least half-hourly. This allows changes to the config files to propagate, such as sanctions to Cops, and new Cops being added to the system. For POSIX server operators, you'll use a cronjob and a bash script provided. More discussion on the bash script below. For Windows/non-cron users, you'll have to find a way to do this on your own, but a batch file will be provided to do the heavy lifting, you'll only need to worry about making it update at least every half hour. Both shell scripts will become part of the game distribution, but will only be activated when server operators want to use them. And yes, I do intend there to be another 0.2.8 release if needed to get all this out there.

The banlist

The banlist is different than the config files in that it has to be synced both ways: to the game servers from the repositories, and back to the repositories from the game servers. For the system to be effective, I propose that the sync must happen at least every 10 minutes, but suggest it should happen every 5 minutes, which would make it 10 minutes before a ban on one server takes effect on another server. Independent operators are free to choose longer intervals, but official servers must choose 5 minute intervals, or if a technical reason prohibits them from doing so, 10 minute intervals.

Obviously software will need to be added to the repositories to receive the banlists and reconcile differences automatically so that bans that happen to different people on different servers at the same time get preserved in the resulting file. I suggest that this software simply use a database to store the current banlist and render it as a text file when it's requested. That's what I'd do, anyway. It will be called often enough by game servers to also do maintenance work on the list, like removing expired bans from the list. If a permaban feature isn't currently in the game, then we'll choose a large arbitrary number that tells the banlist manager that it's a permanent ban so that it can mark the database entry accordingly and ensure that it always provides that ban to servers. It should return a time period for the ban suitable for the possibility that the game server requesting it might fall out of contact with it for a day.

If necessary, the game should be modified to reload the banlist between rounds, so the shortest amount of time it will take for a ban to propagate will be one round. I think this change has already happened, so this is probably a useless paragraph.

The sync system

The scripts that do the syncing need to do it in a particular way in order to ensure that the files they download are secure. First, the resource repositories should provide https services, preferably with a real certificate that can be verified through an authority, but can use an unverifiable certificate in order to ensure the encrypted transfer takes place. Regardless of the use of http, the scripts need to download the config files and banlist from two different sources, compare the files to ensure they are the same, and then copy the files into place in the server config directory.

I considered including a sha check, but realized it's just easier to download the files and compare.

The resource repository software will have to take this into account to eliminate the possibility of false negatives happening in case they're not directly in sync with each other.

The repositories should sync with each other at least on a half-hour basis. They should stagger their syncing so that they're not all trying to sync at once, so if we have three repositories, one would sync on the hour and at hour:30, one at hour:10 and hour:40, and one at hour:20 and hour:50, and so forth.

The repository software to manage all these files is the most challenging part of the system to implement. :)

Cops and their privileges

I propose three levels of Player Police: Deputy, Sheriff, and Detective, with their responsibilities as listed:
  • A Deputy has access to kick and kill commands, but cannot ban anybody. They also only have jurisdiction on the server they're in at the time, meaning they can only enforce activity they see.
  • A Sheriff has access to bans, but like the Deputy, only has jurisdiction over activity they see.
  • A Detective has full moderator access, but has jurisdiction over all servers that subscribe to the system. That means that if something is happening in a server and there's nobody around to deal with it, a player can go find a Detective anywhere they can, be it another game server, these forums, the irc channel, or even a phone call, and ask them to come into the server to deal with the problem. A Detective has investigational powers to use as needed for the cases where a problematic person manages to escape before the Detective shows up. He can ask for log files from server operators, and server operators must give them. Detectives are awesome, we want lots of them, but we want to ensure that they are good, as well.
In the config files, there should be some separation between these three user levels, at least 100, to allow for customization by private server operators and also to allow for additions we may discover we need to have.

Now, when you have a problematic person and there are no Detectives available, but there is a Sheriff or Deputy, you can still find them and have them join the server. If the problematic behavior continues, they can act. If the behavior stops and the Sheriff or Deputy doesn't see it, they can't act, but they can file a report. That process is to be discussed in that other thread I mentioned.

Conclusion

This covers everything I've got in my head, with additions I thought up while writing it. So, discuss? Also, anybody willing to put together an initial implementation, I suggest you start with the config files and the sync system for those, put that out there for people to test, and worry about syncing the banlist second, rather than first. The first priority is forming the Player Police Force. The second priority is arming them with cross-server bans.

I'm also leaning towards adding the banlist and the sync to the master servers, but am nowhere near sold on the idea.

Edit: I forgot to add the part about the scripts and how they should manage the syncing, so if you read this and that part wasn't there, you have to go back and reread it.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

User avatar
Light
Reverse Outside Corner Grinder
Posts: 1644
Joined: Thu Oct 20, 2011 2:11 pm

Re: Player Police 2: The Design

Post by Light » Thu Jan 05, 2017 3:23 am

I think you're going through a lot of work syncing files when you could easily handle it outside of the game itself. You should read my reply on the other thread and see if that changes your mind on how you should set this up.

User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: Player Police 2: The Design

Post by Lucifer » Thu Jan 05, 2017 3:30 am

I'll read it, but it occurs to me that I didn't really discuss that this is all stuff that happens outside of the game process, basically in a cronjob.

I'll go read your other response now.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: Player Police 2: The Design

Post by Lucifer » Thu Jan 05, 2017 3:33 am

Ok, I read your post, and on technical details, I believe I have addressed like 95% of what you wrote. The remaining 5% is that yes, on the resource repositories, the config files should be in the database and rendered as text files when requested. That way, the syncing happens automatically.

Also, a web-based front-end to the Player Police database would be pretty easy to write if we're using the database for the config files and for the banlist. The php code for armathenticating is already out there and would obviously need to be used to authenticate Player Police on a web-based UI.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

User avatar
Light
Reverse Outside Corner Grinder
Posts: 1644
Joined: Thu Oct 20, 2011 2:11 pm

Re: Player Police 2: The Design

Post by Light » Thu Jan 05, 2017 3:38 am

Lucifer wrote:Ok, I read your post, and on technical details, I believe I have addressed like 95% of what you wrote. The remaining 5% is that yes, on the resource repositories, the config files should be in the database and rendered as text files when requested. That way, the syncing happens automatically.
In my reply I was ridding of the whole config idea. Basically it would work on the fly by checking your current status at the time of you logging in to the server, rather than on server reboots.
Lucifer wrote:Also, a web-based front-end to the Player Police database would be pretty easy to write if we're using the database for the config files and for the banlist. The php code for armathenticating is already out there and would obviously need to be used to authenticate Player Police on a web-based UI.
I already created one which I use for authenticating your login when you upload to the resource. It works for all auths, even though I only allow @forums there to avoid username duplication in the resource.

It would let us have mods, banned users, and anything else we want in the database, and if we decide to unban someone, they can instantly join the server rather than waiting for the server to reload the scripts. That also goes for promoting people to mods and whatnot. Since you would be sending and receiving very little data, it should be nice and quick, and only happens when a user joins the server, so it's not like it would be an excessive amount of requests.

User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: Player Police 2: The Design

Post by Lucifer » Thu Jan 05, 2017 3:41 am

I guess I'm not really understanding what you're suggesting. Are you suggesting having the game server query the repository database?

The system that I've outlined is supposed to work with existing capabilities as much as possible, and the only new development required is the config files, and the management on the repository servers that keeps everything in sync, and the scripts that get stuck in cronjob slavery to sync the game servers. One particular problem it solves that I didn't state explicitly (but I've run into at work, believe it or not) is that if the game server can't contact the repository for some reason, it can still operate, because it keeps a local cache of everything the repository has given it.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

User avatar
Light
Reverse Outside Corner Grinder
Posts: 1644
Joined: Thu Oct 20, 2011 2:11 pm

Re: Player Police 2: The Design

Post by Light » Thu Jan 05, 2017 3:51 am

Lucifer wrote:I guess I'm not really understanding what you're suggesting. Are you suggesting having the game server query the repository database?

The system that I've outlined is supposed to work with existing capabilities as much as possible, and the only new development required is the config files, and the management on the repository servers that keeps everything in sync, and the scripts that get stuck in cronjob slavery to sync the game servers. One particular problem it solves that I didn't state explicitly (but I've run into at work, believe it or not) is that if the game server can't contact the repository for some reason, it can still operate, because it keeps a local cache of everything the repository has given it.
I had a couple days of it being up and down, and realized the GPU fan went out and was overheating it. Yanked it out and it's running perfectly fine now, so maybe try again?

So, for my suggestion, completely forget about your config files. I would suggest we have two (could be one if we really wanted) tables. One table would have your auth and a user level so we could give admin, mod, etc to different users. The other table would basically just be banned IP addresses, along with maybe an expiration date. So, everything is stored in the database.

Now for your server, you would only need a very simple PHP script. You wouldn't need to have cronjobs running or anything, as the script will see a player join, then ask the database if that person is allowed in. If they are, fine .. and if not, they automatically get a boot. If they're banned, they could get a 5 min ban or something to avoid constant attempts to join. Maybe they're just muted, so we automatically mute them when they join.

So, the PHP script would never need updated, and never needs synced up as it is always querying the server to get the current status of a player using their IP on PLAYER_ENTERED.

In my opinion, this would by far simplify your idea. Only the server would need to be able to access the database server, so each user doesn't have to have anything set up for it. Everything would just .. work. It would make everything live as there would be no delay between changes to the database and your sync.

I know I'm not very good at explaining, but with how simple this is, I could probably write you an example tomorrow if you wanna check the idea out. It would obviously grow and end up doing more as time goes on I'm sure, but at least it could handle the immediate problem along with a few easy to add bonus features, and we could always take suggestions.

User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: Player Police 2: The Design

Post by Lucifer » Thu Jan 05, 2017 3:58 am

Light wrote: I had a couple days of it being up and down, and realized the GPU fan went out and was overheating it. Yanked it out and it's running perfectly fine now, so maybe try again?
Nonono, the problem I ran into at work is that our POS machines quit working because our internet was out temporarily. The stupid design is that when you take an order, the POS machine has to make an INSERT on a central database that it accesses through the internet. The smart design would make the INSERT on a local database, and that database would periodically update the central database. In the case of a lost connection to the central database, the POS would still function using only local information.

And that's the flaw in your proposal. If contact is broken with the central repository, then existing bans are lost. So Swag could get banned everywhere, and then attack the resource repositories and thus gain access to game servers again, because they're no longer able to enforce the ban.

That's why all the file syncing is there in my design. To allow servers to operate and enforce bans even if they lose contact with the repositories.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

User avatar
Light
Reverse Outside Corner Grinder
Posts: 1644
Joined: Thu Oct 20, 2011 2:11 pm

Re: Player Police 2: The Design

Post by Light » Thu Jan 05, 2017 4:06 am

Lucifer wrote:Nonono, the problem I ran into at work is that our POS machines quit working because our internet was out temporarily. The stupid design is that when you take an order, the POS machine has to make an INSERT on a central database that it accesses through the internet. The smart design would make the INSERT on a local database, and that database would periodically update the central database. In the case of a lost connection to the central database, the POS would still function using only local information.

And that's the flaw in your proposal. If contact is broken with the central repository, then existing bans are lost. So Swag could get banned everywhere, and then attack the resource repositories and thus gain access to game servers again, because they're no longer able to enforce the ban.

That's why all the file syncing is there in my design. To allow servers to operate and enforce bans even if they lose contact with the repositories.
Well, the same idea could work with a single script that would generate the cfg files I guess. It could in a sense be the cronjob you described and work specifically for that server and generate the configs to do everything I mentioned above. Maybe semi often check the latest update time on the database and see if it's newer than the last time you updated. Timestamp, version number, whatever we want.

We would then still get pretty up to date configs without constantly downloading them, and all of the above features would still be available.

This would still end up being a pretty easy thing to to make, and only requires one small script that never really needs updated unless new features are added that it doesn't handle.

User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: Player Police 2: The Design

Post by Lucifer » Thu Jan 05, 2017 4:22 am

Propagating the banlist in as close to realtime as possible is the most important part. That's the enforcement arm of the Player Police. The configs being propagated is only needed when changes happen, so we could even scale that back to "Update your configs because we've changed them" level of notifications. The reason the automatic update is in my proposal is more for convenience than anything else. A server operator spends a few minutes setting up a cronjob and edits a single config file, and he's now in the system. Further, if we make it so that the files downloaded come in a zipped archive, the game server will never need to be updated even if we change the structure of config files. As long as the initial INCLUDE isn't changed, we're golden.

I'm not in any way opposed to something that works in realtime, but honestly, I'd want that something written into the game itself, with a reasonable fallback (caching the information), and without delaying gameplay doing what essentially amounts to running a background check on every player. That requires a higher level of development and testing than my proposal here, and what I'm proposing can be bundled in a tarball and implemented on servers running right now, regardless of whether or not they're already using a script.

If we go point by point through your suggestion, I strongly believe we'll end up with something resembling what I've written here. That's because I've thought it through many different iterations. This isn't something I just dreamed up today, I've been thinking about how to design this system since the first Player Police thread was created.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: Player Police 2: The Design

Post by Lucifer » Thu Jan 05, 2017 4:32 am

Ok, I thought about it a little more and realized there's a specific concern you have that I'm not addressing, and I'm arguing back with concerns I have that your suggestion doesn't address.

Here's a fun thought: Your suggestion and my design are not mutually exclusive.

So, write your real-time script that checks people against the banlist, and make it capable of falling back to a locally cached system managed by shell scripts in a cronjob.

My design provides a mechanism for all this to work in a way that's not difficult for server operators to implement. Yours can easily serve as an add-on feature that makes the checking happen in a real-time fashion. If you want to add extra caching options to it, that's up to you. It's quite possible that your script and the system I've designed can be choices made available to server admins.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

User avatar
sinewav
Graphic Artist
Posts: 6199
Joined: Wed Jan 23, 2008 3:37 am
Contact:

Re: Player Police 2: The Design

Post by sinewav » Thu Jan 05, 2017 5:17 am

This discussion is good. I don't have anything to add other than my enthusiasm. I think official servers are long overdue.

User avatar
Lucifer
Project Developer & Local Moonshiner
Posts: 8610
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: Player Police 2: The Design

Post by Lucifer » Thu Jan 05, 2017 6:06 am

sinewav wrote:This discussion is good. I don't have anything to add other than my enthusiasm. I think official servers are long overdue.
Actually, if you know the config files well enough to write them to serve my design, you have that you can contribute.

We'll need someone familiar with bash scripting to write the retrieval script to sync all the files, and someone familiar with windows batch files to make it work there.

I can write the bash script, it's just a matter of time.

Anyway, if you come up with config files that can make this happen, post them and I'll take a look and more than likely stick them in 0.4. I don't have an 0.2.8 branch right now, and would prefer not to and let Z-Man handle it.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden

Word
Reverse Adjust Outside Corner Grinder
Posts: 4161
Joined: Wed Jan 07, 2009 6:13 pm

Re: Player Police 2: The Design

Post by Word » Thu Jan 05, 2017 9:36 am

Heh, I feel a little guilty if the old thread kept you up at night, but I'm happy to see the result and agree with sinewav.

User avatar
Light
Reverse Outside Corner Grinder
Posts: 1644
Joined: Thu Oct 20, 2011 2:11 pm

Re: Player Police 2: The Design

Post by Light » Thu Jan 05, 2017 1:39 pm

Lucifer wrote:So, write your real-time script that checks people against the banlist, and make it capable of falling back to a locally cached system managed by shell scripts in a cronjob.
I was getting rid of the idea of real-time, but it would be a lot closer than a cronjob since we can pull it only when necessary. So, we would be capable of checking for updates more often without causing a bunch of excess bandwidth usage.

Basically, since pretty much everyone can run scripts on their server, it would mean that anyone could easily set it up my way. They would put a script on their server, and it would automatically set up everything you mentioned above, with the added bonus of less delays because we are checking more often for updates. Teaching people to set up cronjobs seems like it would take a bit of effort as compared to having their config use SPAWN_SCRIPT.

So, what the script would do with my current idea is basically be a cronjob built into the game server, rather than the OS. It would, maybe every 5 minutes, check the latest version of the database. If the database says there's a new version, it will then make a pull for a config that my server would generate on the fly based on what we have in the database. There would be no manually handling the configs, rather just "add this person to the ban list" and it would add a row for them, as well as updating our version. Now the server can loop through that list and either ban or unban (if the ban expired), as well as sending an update of all the user levels.

It would be saved locally, so it would continue to work without the database server being online. It's basically what you were talking about doing, but I believe it's simpler than the way you're going about it.

On top of that, we could do a real-time check if you think it's a useful idea. It wouldn't really hurt anything, and would possibly give us the ability to have even better features.

One thing that you've mentioned above that I'm against though is banning through the game (adding to banlist from in-game). At least, it sounded like you were saying that. I think that would be a bad idea because we could either have people spoof what we're using to check, or if we make it something they can't spoof, they could intercept. I think it has to be handled outside of the game. This is only because untrusted people can run the script on their servers, and we don't want trusted people attempting to log in there and give access to the system.

So, yeah! We could have a real-time check with a backup that all goes on inside the script, and requires nothing more than a spawn_script command in their config. I could also try to make everything work for both AP and CT, which shouldn't be too difficult. If it ends up being necessary, we can have the server owner choose CT or AP in the script. It would be an easy thing to make.

Maybe we could get together in-game sometime later today? I'm at work at the moment so any time past 16:00 ET would work for me.

Post Reply