* Process procs now properly utilize deltatime when implementing rates, timers and probabilities (#52981)
* Process procs now properly use deltatime when implementing rates, timers and probabilities
* Review fixes
* Geiger counters cleanup
Made hardsuit geiger code more similar to geiger counter code
Geiger counters are more responsive now
* Moved SS*_DT defines to subsystems.dm
* Rebase fix
* Redefined the SS*_DT defines to use the subsystem wait vars
* Implemented suggested changes by @AnturK
* Commented /datum/proc/process about the deltatime stuff
* Send delta_time as a process parameter instead of the defines
Also DTfied acid_processing
* Dtfied new acid component
* Process procs now properly utilize deltatime when implementing rates, timers and probabilities
Co-authored-by: Donkie <daniel.cf.hultgren@gmail.com>
* Adds SIGNAL_HANDLER and SIGNAL_HANDLER_DOES_SLEEP to prevent signal callbacks from blocking (#52761)
Adds SIGNAL_HANDLER, a macro that sets SHOULD_NOT_SLEEP(TRUE). This should ideally be required on all new signal callbacks.
Adds BLOCKING_SIGNAL_HANDLER, a macro that does nothing except symbolize "this is an older signal that didn't necessitate a code rewrite". It should not be allowed for new work.
This comes from discussion around #52735, which yields by calling input, and (though it sets the return type beforehand) will not properly return the flag to prevent attack from slapping.
To fix 60% of the yielding cases, WrapAdminProcCall no longer waits for another admin's proc call to finish. I'm not an admin, so I don't know how many behinds this has saved, but if this is problematic for admins I can just make it so that it lets you do it anyway. I'm not sure what the point of this babysitting was anyway.
Requested by @optimumtact.
Changelog
cl
admin: Calling a proc while another admin is calling one will no longer wait for the first to finish. You will simply just have to call it again.
/cl
* Adds SIGNAL_HANDLER and SIGNAL_HANDLER_DOES_SLEEP to prevent signal callbacks from blocking
Co-authored-by: Jared-Fogle <35135081+Jared-Fogle@users.noreply.github.com>
About The Pull Request
Ears currently behave strangely compared to other organs, especially their most closely related sensory organ, eyes. They only assign a deafness trait for quirks, mutations, and clothing (which prevents empaths from noticing hearing damage deafness), have lots of unnecessary procs for dealing/assessing damage, and several audible events check istype() for earmuffs specifically for whether a mob can hear something.
This cuts down on all of that. I removed most ear related procs from mobs, tied deafness explicitly to TRAIT_DEAF (and added a new source for hearing damage), and generally neatened up related code. As a direct result, empaths can now detect deafness from hearing damage, as I assume was intended. I also fixed a bug with examining with med HUD's or as an observer not showing a person's quirks, though I'm not sure people will really care about the info with med HUDs. Also, full revives/regenerating organs now remove all damage from existing organs rather than only trying to replace missing ones
In addition, Inacusiate and Sensory Restoration no longer instantly cure all hearing damage when applied, they now rapidly decrease both ear damage and deafness each tick. This isn't really a fix, but I figured I'd throw it in since I think cobby wanted to move away from instant fix microdose chems, and I punted the restoreEars() procs anyway
Fixes: #51435Fixes: #48974
Why It's Good For The Game
Brings ears in line with how other organs operate, makes them easier to understand, and restores (what I assume to be) intended functionality for the empath quirk and medhud/observer examines
Changelog
cl Ryll/Shaps
fix: Empaths are able to detect deafness derived from hearing damage
tweak: Inacusiate and Sensory Restoration no longer instantly heal all hearing damage when applied, instead rapidly removing both ear damage and deafness.
fix: MedHUDs and observers now display quirks as intended on examine
/cl
If you came here thinking this was some game feature then you are in the wrong place. Here is where I ramble about code.
This adds /datum/element as a sort of sibling to components. Only one of each type gets instanced and they do not get tied directly to any particular thing like a component does. Basically they're a very lightweight component for doing simple functionality that doesn't have much state.
Originally this concept came about as a kind of component that could be shared between many parents to reduce some resource costs. Doing this would allow us to componentize more behaviors that are a part of too many things to be viable to have a whole component for every single one. For example a component on every space turf would be entirely unviable. With elements it's much more reasonable.
This implements a prety bare framework and a couple components are migrated to it. It's ready to be used but I fully expect I'm going to need to refine how it works for all the usecases we'll want it for.
Also: this fixes the qdeleted signal. This signal isn't even possible because after qdel is done there's nothing to receive a signal anyway. I've changed it to a qdeling signal instead. I need it to work for some elements to know when to clean themselves up.
