Teshari hud darkness overlay keeps getting deleted globally, and worse it keeps them from spawning after. This is a cheap fix to correct this, but I have no idea what's causing it in the first place.
Someone had already added a 'return-only' override for hear_say for new_player mobs to keep their ghostears from working in the lobby, however ghostsight/eyes/whateveritscalled has not worked as it should and it seems like nobody thought to add a show_message block for emotes.
'chu heard me. S'what it does. When you're on a call, there's a "Start Video" button next to each person. When you click it, you actually look through their thing, like a ghost might if they ghostcalled. You have to stay within 1 tile of a video showing communicator to see it.
Multiple people can share one communicator video stream by setting it on a table or whatever, and examining it. There's a message like "It appears to be showing a video: [view]" and you can click view and you can all look at the video. COLLABORATION. SYNERGY. OTHER BUZZWORDS.
I also added the feature of DECLINING requests from people.
Also communicators show up on a special camera list on security consoles, but the same EPv2 network visibility turns this off as well if you wanna be all hidey. This does mean that people with the visiblity on serve as sort of roaming AI cameras for the AI as well. So the AI can watch you repair the outside of the station or whatever if you want.
They obviously have little windows on them. And this is how they used to be. Was probably an oversight when they were converted to another format or something. Airlocks without windows are preeeetty silly.
*screams forever*
This one almost got me. Organs were defined in two places, probably because of a merge error, and /obj/item/organ/external/head/removed() was defined in THREE places. Pls. Why you do this. PLSSSS.
* The /datum/category_item/player_setup_item datums did a good job of organizing the code for loading/saving/editing preferences data, but all of the code that applies preferences to newly created player mobs was still in a single function.
* This change adds a new proc to player_setup_item datums: copy_to_mob() which is called from the traditional copy_to() proc, allowing each preferences datum to apply its own character data to the mob.
* This allowes new preferences to easily compartmentalize their new code.
* I also moved all the code for existing preferences from copy_to() into the copy_to_mob() on their respective preferences datums.
