* fixes secrets topic check_antagonist
* removes code related to check_antagonist topic that doesn't work or does nothing
* changes the name of the button in the secrets panel
* removes old secrets panel topic check_antagonist
* player panel antag button no longer relies on secrets topic
* player panel antag button no longer relies on secrets topic
* readds something i shouldnt have removed
Now you can set the mode after the round starts, to be saved as the
default for next round and on
Otherwise you can now choose rather or not the mode change is for the
current round only or saved as the new default mode.
* Podspawn admin verb, like spawn, but more IC
🆑 coiax
admin: New 'Podspawn' verb, which functions like 'Spawn', except
any atoms movable spawned will be dropped in via a no-damage, no-explosion
Centcom supply pod.
/🆑
Essentially, sometimes you want to spawn stuff in, quickly, in an adhoc manner.
Use of the full Centcom launchbay is fine if you're doing a full blown drop or event
or want some customisation, but sometimes you want a quick supply pod.
The admin smite "Supply Pod (Quick)" has been used for this purpose, but it has a side
effect of setting people on fire and damaging them, which isn't what you want
if it's just for spawning stuff in.
* Adds option to Game Panel->Create Object
* Code review I
Spiritual successor and extension to #17798, an almost entire rebuild of the SQL ban system backend and interface.
Bantypes are removed per #8584 and #6174. All bans are now 'role bans', server bans are when a ban's role is server. Admin bans are a column, meaning it's possible to ban admins from jobs.
Bans now have only an expiry datetime, duration is calculated from this when queried.
unbanned column is removed as it's superfluous, checking unban status is now done through checking unban_datetime. unban_round_id column added. Each ip and computerid columns rearranged so ip is always first, like in other tables. Bans now permit a null ckey, ip and computerid.
Ban checking is split into two procs now is_banned_from() does a check if a ckey is banned from one or more roles and returns true or false. This effectively replaces jobban_isbanned() used in simple if() statements. If connected a client's ban cache is checked rather than querying the DB. This makes it possible for a client connected to two or more servers to ignore any bans made on one server until their ban cache is rebuilt on the others. Could be avoided with cross-server calls to update ban caches or just the removal of the ban cache but as is I've done neither since I think it's enough of an edge case to not be worth it.
The second proc is is_banned_from_with_details(), this queries the DB for a role ban on a player's ckey, ip or CID and returns the details. This replaces direct queries in IsBanned.dm and the preferences menu.
The legacy ban system is removed.
The interfaces for banning, unbanning and editing bans have been remade to require less clicking and easier simultaneous operations. The banning and jobban panel are combined. They also store player connection details when opened so a client disconnecting no longer stops a ban being placed.
New banning panel:
Key, IP and CID can all be toggled to allow excluding them from a ban.
Checking Use IP and CID from last connection lets you enter only a ckey and have the DB fill these fields in for you, if possible.
Temporary bans have a drop-menu which lets you select between seconds, minutes, hours, days, weeks, months and years so you don't need to calculate how many minutes a long ban would be. The ban is still converted into minutes on the DB however.
Checking any of the head roles will check both of the boxes for you.
The red role box indicates there is already a ban on that role for this ckey. You can apply additional role bans to stack them.
New unbanning panel:
Unbanning panel is now separate from the banning panel but otherwise functionally the same.
Ban editing panel:
Actually just a modified banning panel, all the features from it work the same here.
You can now edit almost all parameters of a ban instead of just the reason.
You can't edit severity as it's not really part of the ban.
The panels have been tested but I've not been able to get my local server to be accessible so ban functionality isn't properly confirmed. Plenty of testing will be required as I'd rather not break bans.
cl
admin: Ban interface rework. The banning and unbanning panels have received a new design which is easier to use and allows multiple role bans to be made at once.
prefix: Ban search and unbanning moved to unbanning panel, which is now a separate panel to the old banning panel.
/cl
1. there was an option for cancel when the input already had a cancel button
2. hitting either of these cancels did nothing, and it continued on with the
transformation
3. there were some 1's and 0's that shoulda been TRUE and FALSE
* -Fixed intelli potions requiring you to have Xeno toggled on in special preferences to be notified.
-Split xenos, intelli potions, and mind transfer potions into separate roles for a more precise role management.
* -Made sentience potions and mind transfer potion roles bannable from jobban panel.
-Gave Sentience potion role its own toggle in game preferences.
* Fixed bad reference
* Cleaned up role references
* Cleaned up a few defines
* Cleaned up more defines
* Adds note_severity and updates dbconfig. New SQL stuff too.
* whoops please don't hack into my database >:^(
* UI change, changed how it's stored in the DB, removed some queries when it returns, changed stuff to key.
* Update sql_message_system.dm
* this was not defined
* random indent
* wait how did this get here
* okay enough web edits I promise
* just kidding I got u
* Update common.css
* Added buttons, changed UI again, standardized the inputs, added severity for appearance bans, fed the dog
* forgot about the banning panel
* added an asset cache
* corrects asset datum var name
* converts to using key instead of ckey for user facing logs and ui
* more key_name for airlock wires
* futureproofing check for if key changes
* --onlyckeymatch script argument and fail/success counter
* fix
In preparation of pixel movement, I want to refactor our slowdown system to something more modular, and something that doesn't require /quite/ as many proccalls/calculations a tick. The way this works is intended to only have things recalculate when it's necessary, rather than calling it every move.
However, I've left movement_delay() in, as without completely redoing a lot of code it's not /quite/ ready at this point to tear it out completely, but I'm hoping everything can be transitioned over to this system later.
* Qdels all queries, adds sleep handling
* DB Core messages admins about undeleted queries
* Compile fixes. Adds missing set waitfor
* Remove world/New shennanigans. Add DBQuery/BlockingExecute()
* Less spammy notifications to admins about undeleted queries
* Increase dbcore fire time to 1 minute
* Upgrade undeleted query warning
* Better place of death
* Fix build
* Remove BlockingExecute, see BSQL PR for why
* Yep, missed that one.
* Psyche, that's the WRONG QUERY!!
The logging is now stored in the persistent client/player_details datum,
that will survive an entire round
The existing mob log is retained and a new admin verb is added to access
it. It will only show logs for the mob in question, across all players
who possibly spent time in that mob
A new log type is added that tracks the mobs the player changes across
into and the times they occured, to better help admins manage complex
situations, this also appears in the mob log as a record of the players
who entered/exited control of the mob
