About The Pull Request
Removes commie and cappy golems, and all connected parts and features.
Why It's Good For The Game
You're downloading 5 mb of capitalist and communist songs and talk sounds every time you log into a server, which makes it take much longer to actually join the game. While this was a good meme and became even better when cappy golems would fight the communist ones, they are:
Really really underused for what they are
Really really boring and simple without all the special sounds
Really really not worth keeping gutted
Changelog
🆑
del: Capitalism (golem) and Communism (golem) are dead.
/🆑
Adds in a new type for the lighting system, the directional one. It piggybacks on the overlay lighting to create a directional effect + adds a nice visual cone mask to make the effect feel really directional.
Also: made the static light system respect the light_on variable.
It feels really nice to shine AT things you're looking at with flashlights and the such, it makes maintenance scouring much more immersive too.
Adds more paranoia as you dont see light behind yourself when you've got a flashlight. Plus makes ambushes more fun
Intent combos suck ass as it is and we don't need to make them worse by having obscure shortcuts for gimmicks that can be done with the strip menu, I've seen this used accidentally dozens of times and maybe once on purpose
About The Pull Request
Ports and improves my interview system that has been previously used in the summer ball and toolbox tournament events. Allows for a 'softer' panic bunker, wherein players who fall below the required living time limit can still join the server and be restricted to filling out a questionnaire. Upon completing the questionnaire, the player may be allowed into the server by an administrator. If the application is approved, they get a notification that they will be reconnected and upon reconnecting will have all verbs as they usually would. If the application is denied the user is put on a cooldown after which they may submit a new questionnaire.
Players who are being interviewed (herein interviewees) have no verbs other than those required for the stat panel to function, as well as a verb to pull up the interview panel. Interviews do not persist through restarts, and the ability to join that is granted by an accepted interview is only valid for the duration of that round.
Open interviews are listed under a new 'interviews' tab for admins, which is VERY similar to the existing tickets tab.
Below is what a player who is flagged as an interviewee will see when they join the server. They can do nothing but respond to the questionnaire or leave.
image
This is what an administrator sees after an interview is submitted, they will also see a corresponding message within their chatbox, and an age-old BWOINK when an interview is submitted.
image
The interviews tab, which is similar to the tickets menu. You can open the interview manager panel to view all active (including non-submitted) interviews, queued (submitted) interviews, and closed interviews.
image
FAQ:
What happens if someone submits an interview when no admins are on? It's treated like adminhelps are, the message gets sent to TGS to be dispatched off to configured end-points (like Discord or IRC), and the user is notified that their interview was handled this way.
Can you configure the questions? Yes, in config/ there is now a interviews.txt file in which the welcome message and the individual questions can be set and modified.
Can this be turned on and off during a round? Yes, it can be toggled like the panic bunker. It requires the panic bunker to be raised in order to function.
Can interviewees have further questions asked to them? Yes, if you admin-pm them, which is possible using regular means or a conveniently placed button on the interview UI, they will be able to respond to the message.
Technical details
To use the interview system you must have the panic bunker enabled, this is an additional setting for the panic bunker. It can be set through the PANIC_BUNKER_INTERVIEW setting in config.txt, or alternatively enabled in-game as prompted during the panic bunker toggling process. It also can be toggled on its own using a verb added for this purpose, Toggle PB Interviews found under the server tab. These new actions are included in the logging for the panic bunker. I have also added a reporting stat to the world topic status keyword, which now reports if the interview system is on using the keyword interviews.
As mentioned above, for server operators, configure the questions and welcome message in config/interviews.txt.
Note to maintainers and those with big brains I had to add a call to init_verbs on the stat panel window being ready because seemingly a race condition exists wherein the add_verb of the 'view my interview' verb doesn't cause a refresh of the tabs (and therefore doesn't show the 'Interview' tab) when running in dream daemon but running it directly from visual studio code properly shows the tab. Adding a init_verbs call directly after adding the verb didn't seem to help.
A note for downstreams
If you don't use the HTML stat panel (which may not be a bad thing) then you will have to do some conversion from the HTML stat panel stuff used here to the old style stat panels. It's pretty trivial, but just be aware of that. You can see how I used to use the old stat panels in my PR from the summer ball, here, which should be helpful.
Why It's Good For The Game
This allows for a softer version of the panic bunker which impedes the flow of malicious players while allowing genuine players a chance to enter a round to gain enough time to not be affected by the panic bunker's restrictions.
Changelog
🆑 bobbahbrown
add: Added the interview system, a 'soft' panic bunker which lets players who would normally be blocked from joining be interviewed by admins to be selectively allowed to play.
/🆑
default_features and mutant_bodyparts have been used ambivelently since a long time, so I'm merging the two together and replacing relevant 'in' list access operations with '[ ]' for performance while I'm at it.
This PR lets you post up for high-fives with your buds so you can slap some skin and show off how well you vibe together. To initiate a high-five, simply stand next to another person with a slapper (the *slap emote one) in hand, and hit the offer item button (default G) to let the people adjacent to you know you're available. They'll get an alert that you're offering a high-five, and clicking it will follow through and award you both a small positive moodlet, or they can just walk away and leave you hanging, earning you a negative moodlet.
Is a high-five not enough to show the world how tight your crew is? Double the fun! If whoever initiates the high-five has a slapper in both hands, and the taker has two hands free, you'll go for the mythical high-ten for a louder slap and extra emphasis! Woo!
It now uses view() instead, and is cooldowned per each check, instead of per each successful salute
EDIT: I've changed so the commmissioned bots invoke salutes for even more performance, as AnturK suggested.
The attack chain is a bit of a mess, and the introduction of signals hasn't helped in simplifying it.
In order to take a step into untangling this, I re-ordered the attack signals to no longer be by source type and instead to be grouped more modularly, as they are all members of the attack chain and function similarly. They all share the trait of potentially ending the attack chain via a return, but had several different names for it. I joined it into one.
Additionally, fixed a tk bug reported by @Timberpoes by adding a signal return check at the base of /mob/proc/RangedAttack
Lastly, removed the async call of /datum/mutation/human/telekinesis/proc/on_ranged_attack, which was added as a lazy patch to appease the linter complaining about a sleep on a signal handler (namely in /obj/singularity/attack_tk). Fixed the problem using timers.
Also cleaned some code here and there.
imo; the ss13 audio-scape is quite barren, you can only hear most things if you can see them, which in my opinion doesn't make much sense. This changes that so you can hear further away, but falloff is much higher, so in reality you will only hear things relatively quietly when they're out of sight.
This PR increases the hearing distance of most sound by 9, excluding sounds such as antag items that are meant to be used stealthily
This PR also replaces Byond's inbuilt falloff system with something I made, (And thanks to potato for helping me throw together a formula for it). This fall-off system makes sound fall off more naturally, with sounds being full volume within a certain range, and then softly falling off until they are completely quiet. This makes for a smoother transition between "This sound is full volume" and "I dont hear this sound".
Co-authored-by: ff <ff>
Originally I wanted to fix an issue where the `get_up()` `do_after()` would ignore the callback checks, because it was `uninterruptible`, so that made me refactor these procs to allow for higher granularity on checks and standardize behavior a bit more.
There's more work to be done for them, but one thing at a time.
* Removes the `uninterruptible` check in favor of the more granular `timed_action_flags`
* Cleans code on the `do_atom`, `do_after_mob`, `do_mob` and `do_after` procs to standardize them a little better.
VV-related code cleanup
Added code to trigger the proper setters for several variables that have them.
Added some admin logging for var-edit teleports.
Cleaned-up some code all around.
* Self_attack for arms if the hand is empty
* Oops
* Light runtime fix
This is not my runtime, but I will fix it all the same
* return better good
* How about a variable name that actually fits
* asdf
Added / improved documentation for buckling procs and variables
Removed / moved some unused things (removed 'buckling' var on mob, moved can_unbuckle() and can_buckle() from mob to living, removed can_unbuckle() and can_buckle() from slimes because they were ignoring everywhere it was checked anyways)
Moved can_buckle() check to is_buckle_possible() with the rest of the checks
Allowed mobs to buckle other mobs to things on the same turf as them ( I don't see why this was blocked in the first place. We have mobs on the same turf as each other all the time)
Changed silicons to use user_buckle_mob() instead of their own do_after system - now slightly longer to buckle mobs from another turf but instant to buckle mobs from the same turf. This means that borgs can't combatspin people who are still standing but have a slight slowdown, but can load people even faster if they're stunned/incapacitated and lying down. (But honestly, I did it for consistency, not balance)
Implements the ?. operator, replacing code like A && A.B with A?.B
BYOND Ref:
When reading A?.B, it's equivalent to A && A.B except that A is only evaluated once, even if it's a complex expression like a proc call.
fix: Borg tablets now correctly work when the borg is out of power (though you'll get no networking until you get that power issue sorted out).
fix: Borgs that are synced to AIs can correctly view and print photos once more.
* Start of work
* More work
* Finish visuals for main page for AIs, start work on behavior
* More functionality--authenticating and calling shuttle
* Set security level
* Message list
* Purchasing shuttles
* Emagging, messaing associates, nuke codes, permission fixes
* Sending message to allied sectors (done?)
* CentComm -> CentCom
* Resolve part of feedback
* Remove now unused pageComponent variable
* Change children to not use array
* Split lines
* Flex box allied stations
* Don't use ternary
* Fix lints
* Rebuild tgui
* Change icon to biohazard
* Clean up color property
* Rebuild tgui
This is a pretty big change all around. The gist of it is that it moves the mobility_flags into traits or variables that can track the sources, and to which we can append code to react to the events, be it via signals or via on_event-like procs.
For example, MOBILITY_STAND could mean, depending on context, that the mob is either already standing or that it may be able to stand, and thus is lying down.
There was a lot of snowflakery and redefinitions on top of redefinitions, so this is bound to create bugs I'm willing to fix as I learn them.
The end-goal is for every living mob to use the same mobility system, for the traits to mean the same among them, and for no place to just mass-change settings without a way to trace it, such as with mobility_flags = NONE and mobility_flags = ALL
Fixes AIs being able to strip nearby people. They've lost their hands usage.
