If however an admin attempts to add a manual ban for a player who was present during the current round, a player who still has a mob somewhere in the game world, the proc will prioritize the mob's ip and computer id variables, not the things entered in the banning panel form.
- Adds two new types of bans: admin tempbans and admin permabans. These ban types are in reaction to the rising number of banworthy admin issues. The original intent was to make admins unbannable ingame, so players could not spoof admin computer ids to get admins banned, with the assumption that admin issues will be rare and a big deal when they happen. They have however started becoming ever more common, so some tools are required to allow for admin self-policing.
- Each admin can have a maximum of one active admin ban (temporary or permanent) logged to their name. This is to prevent rogue admins from just banning everyone who could ban them. These bans are also not intended to be 'permanent-permanent'. They are intended to serve as a temporary fix, to get rid of rogue admins until the server host or another admin with rdp access (or +PERMISSIONS if you use DB_Admin) can deal with the rogue admin's removal. Once that is done, a normal permaban or tempban can be applied, and the admin permaban/tempban removed, restoring the banning admin's 1 allowed admin ban.
- Admin bans are considered a big deal, so they also send a message to irc, when they are applied.
- NOTE: Admin bans only check the connecting person's ckey. The risk of computer id spoofing still exists, so it's better not to have them check ips and computer ids. The admin abilities are given based on ckey anyway, so a ckey ban should be enough in most cases.
Other changes to bans
- Added a few variables to the funciton that adds a ban: maxadminbanchec (which is for admin bans and checks how many bans the admin can still apply); announceinirc and blockselfban (which prevents admins from applying the ban type on themselves. Currently applied for permaban, tempban, admin permaban, admin tempban)
- Changed the appearance ban database constant from APPEARANCE_BAN to APPEARANCE_PERMABAN, to make it more compatible with the ban log at http://www.ss13.eu/tgdb/banoverview.php
- Added a missing sanity check to topic.dm for appearance bans
- Renamed appearance bans to identity bans in admin panels (as per Pete's request)
Made paths to sounds in robot/emote.dm more specific so the game doesn't have to find the files itself.
git-svn-id: http://tgstation13.googlecode.com/svn/trunk@5039 316c924e-a436-60f5-8080-3fe189b3f50e
- Uncommented a piece of code in IsBanned() that was only commented for testing purposes. Admins now once again ignore any bans to their name, except for daemon bans.
git-svn-id: http://tgstation13.googlecode.com/svn/trunk@5036 316c924e-a436-60f5-8080-3fe189b3f50e
- The current, file-based ban system is now a legacy system, the use of which is strongly discouraged for servers, which are constantly online.
- Added a database-based banning system, with a new baning panel, accessible through the 'banning panel' verb. Servers, which use this new banning system, will get the new panel up even if they use the old 'unban panel' or 'display job bans' verbs. These remain there for legacy support purposes. (Panel screenshot below)
- The most notable benefits of the new system are the ability to add offline bans, meaning the person does not have to be connected for a ban to be applied to their name. The second benefit is the ability to look up all previous bans that the person had.
- The major disadvantage is the complete incompatibility between the old and new system, meaning you have to either do a lot of copy-pasting or playing around in code to sync the old system with the new one. Servers upgrading to this system might want to consider a purge of all bans, if they don't want to go through this. Due to the incompatibility, there are no transition tools provided. Please contact me (errorage/rageroro) in #coderbus for help in syncing your database. The /tg/ legacy and database systems have been synced.
- The server configuration defaults to use the legacy system, as the new one requires the database to be set up. Please hash BAN_LEGACY_SYSTEM in config.txt as explained, to use the new system. If the database connection fails, the server reverts to the legacy system.
If any bugs or errors appear with either the legacy or new ban system, please let me know ASAP. The same applies if there are any syncronization problems between the legacy and new system, resulting in banned people unbanned or unbanned people banned.
Panel screenshot:
http://www.kamletos.si/new%20ban%20panel2.PNG
git-svn-id: http://tgstation13.googlecode.com/svn/trunk@5034 316c924e-a436-60f5-8080-3fe189b3f50e
- Standardized the database library code
- Deleted a few unused database related files (karma and forum activation), so they won't get in my way later. They work off of no longer existent database tables.
- Made it so the server maintains a constant connection with the database, which is established on world/New() and never broken, until the server ends. If 5 consecutive database connection attempts result in no connection getting established, the server will not attempt any more connections. Made all existing database connections use the global continuous connections. Currently we need two, as we have two databases, but the old database is going to get moved into the new one.
- Fixed the spaghetti-like report in the permissions panel, which happened when someone had many permissions enabled.
- Added database connection reports to display to dream daemon on server startup.
git-svn-id: http://tgstation13.googlecode.com/svn/trunk@5015 316c924e-a436-60f5-8080-3fe189b3f50e
>tried to make the comments less confusing.
>Removed the procs for rebuilding the lists (they weren't meant to be used and half were broken anyway).
>added a directory. It maps ckey to client like so directory[ckey] = client. It could be used for PMs, banning, and various other admin tools rather than using \ref[]
>var/list/admins is now a list of clients whom are admins.
>var/list/admin_datums is what var/list/admins used to be. A map from ckey -> admin datum
Most of this is so I can add modular admin ranks in a non-horrendous way and fix some existing issues.
>var/list/client_list is now var/list/clients (laziness sorry)
>removed some needless loops and stuff.
git-svn-id: http://tgstation13.googlecode.com/svn/trunk@4951 316c924e-a436-60f5-8080-3fe189b3f50e
/obj/admins is now /datum/admins because that's what datums are for you silly people
Moved var/datum/marked_datum from /obj/ to /datum/admins
admin datums are persistent throughout the round. They are stored in the var/list/admins rather than the ranks. This is so admin preferences may be moved into the datum to have them persist even after Login/Logout/Disconnects.
git-svn-id: http://tgstation13.googlecode.com/svn/trunk@4749 316c924e-a436-60f5-8080-3fe189b3f50e
-Almost every instance of 'for(mob in world)' has been killed. Because GODDAMN was it being run a bunch. Instead, a series of global lists have been made, and they are all handled auto-magically through New()'s, Del()'s, Login()'s, death()'s, etc...
Lists are as follows:
-mob_list : Contains all atom/mobs by ref
-player_list : Like mob_list, but only contains mobs with clients attached
-admin_list : Like player_list, but holds all mobs with clients attached and admin status
-living_mob_list : Contains all mobs that ARE alive, regardless of client status
-dead_mob_list : Contains all mobs that are dead, which comes down to corpses and ghosts
-cable_list : A list containing every obj/structure/cable in existence
Note: There is an object (/obj/item/debuglist) that you can use to check the contents of each of the lists except for cables (Since getting a message saying "a cable," x9001 isn't very helpful)
These lists have been tested as much as I could on my own, and have been mostly implemented. There are still places where they could be used, but for now it's important that the core is working. If this all checks out I would really like to implement it into the MC as well, simply so it doesn't check call Life() on every mob by checking for all the ones in world every damn tick.
Just testing locally I was able to notice improvements with certain aspects, like admin verbs being MUCH more responsive (They checked for every mob in the world every time they were clicked), many sources of needless lag were cut out (Like Adminwho and Who checking every single mob when clicked), and due to the cable_list powernet rebuilding is MUCH more efficient, because instead of checking for every cable in the world every time a powernet was broken (read: A cable was deleted), it runs though the pre-made list, and even with a singulo tearing all the way across the station, the powernet load was VERY small compared to pretty much everything else.
If you want to know how any of this works, check global_lists.dm, there I have it rigorously commented, and it should provide an understanding of what's going on.
Mob related in worlds before this commit: 1262
After: 4
I'm helping
git-svn-id: http://tgstation13.googlecode.com/svn/trunk@4179 316c924e-a436-60f5-8080-3fe189b3f50e
- Fixed a runtime error which happened when you tried to unban someone through the 'display job bans' verb.
git-svn-id: http://tgstation13.googlecode.com/svn/trunk@4148 316c924e-a436-60f5-8080-3fe189b3f50e
