In addition to fixing the problem, it makes sense. The observer pattern is overkill for an object type we own; doing it directly in Destroy() is more efficient.
I like the ones I wrote, but these are proooobably better.
They have normal units, which are worn on the back and you can grab the paddles out of to shock people.
Then there's compact units, which are worn as a belt, and serve the same purpose.
And finally there's the combat units, which allow revives through spacesuits, and have no safety so you can zap living people on harm intent (good for antags? CMO?).
These appropriately check for blood, a heart, etc. So, in that way, they're a bit more realisic than my original ones which I was sorta lazy in writing.
Emagging them turns off the safeties, allowing them to zap people who are still alive.
I actually cleaned up their sprite choice code a little and added a sprite for the 'combat' one since previously it was just the emagged sprite (flashing exclamation point). Now it's just got a red heart monitor, and the emagged ones keeps the exclamation.
Did make one balance change in that compact ones use twice the power (inefficient small capacitors? or something?).
* Fixes Baystation12/Baystation12/issues/17443 - Runtime in radiation.dm,30: illegal: sqrt(-2.857143)
* Updating radiation power to below zero should simply delete the source.
* Fixes at least one cause of Runtime in radiation.dm,41: Cannot read null.z in an effort to fix Baystation12/Baystation12/issues/17411
Shuttles now set themselves up upon being instantiated instead of relying on a monolithic proc in the shuttle controller.
Shuttles can now be defined more cleanly on a per-map basis, as well.
Accidentally fixes a broken admin shuttle.
* Hooks up informing Master the gameticker actually starts and stops the round subsystems will actually fire! What ho!
* We should convert the gameticker as an MC subsystem someday, and probably completely rewrite it while we are at it becuase it is crazy. But this should bridge the gap until then.
* The vast majority of gas mixtures never use their `graphic` list. Prime candidate for making a lazy init list.
* While we are here, add nullchecks to ZAS's use of the graphic list a bit. /turf/update_graphics was technically already null safe, but its even better to not bother calling it at all right?
* Initializing a list in the type definition (of any type) incurs a hidden proc call ("init"). Simply by moving the init of the lists to /New() we speed up creation of /datum/gas_mixtures (which happens *often*)
* The list variables still get initialized by the time the instance is created, so this has zero impact on other code, its just starightup faster with no downsides.
Fixes a line printed about staying close to your patient printed in error, and makes syringes work on laying patients again.
The do_surgery overrides are from a bygone era.
Tested == yes
* For various reasons its best to not instantiate lists until they are actually going to be used, especially if there is a good chance that a given list variable might *never* be used during the lifetime of an object.
* These macros make it simple and concise to add remove and access entries in lazily created lists.
* Based on https://github.com/tgstation/tgstation/pull/25386
* Create macro for defining new subsystem types.
* Create PreInit proc to handle setup that needs to be done before the map loads
* Rename garbage_controller subsystem to garbage so it matches its global SSgarbage variable name.
* Every pipe in a pipeline has a reference to the pipeline. This needs to be cleared, both so the pipeline can be gc'd, and also so the pipes don't try and keep using the qdel'd pipeline.
* Same story for each pipeline in a pipe network, and each machine in a pipe network.
* Pipe networks are also in the pipe_networks global list. While the controller would detect and remove it from the list on the next tick, cleaning up ourselves is the responsible thing to do.
* /datum/reagents/Destroy() does everything /datum/reagents/delete() does and more, and delete() is called only from /obj/effect/Destroy() which is *itself* redundant with its parent /atom/movable/Destroy()
