The initialize() routines of HE pipes, vents an scrubbers need to be atmos_init() after all.
If you register yourself with radio controller you need to de-register yourself too.
The initialize() routines of HE pipes, vents an scrubbers need to be atmos_init() after all.
If you register yourself with radio controller you need to de-register yourself too.
* These procs were repeated verbatim on the different subtypes of /obj/machinery/atmospherics/pipe. Consolidated them in the parent.
* Added little comment headers over the different types of pipes to make the file easier to read.
* to_chat() replacement.
* Revert calling target.init_dir() before connecting.
* This change was added in https://github.com/PolarisSS13/Polaris/pull/3775 to counteract `dir` not being set prior to New() for dynamically loaded maps. The root cause was /atom/New() not calling _preloader.load(). Undoing the change now that /atom/New() is fixed.
* The addition of the init_dir() proc itself however, is useful, because there ARE other times some atmos machinery will want to re-initialize its dir, specifically whenever it is rotated.
* init_dir() must be called in the constructor of all atmospherics machines capable of connecting to another. Since it has to happen for ALL machines, lets move that call to /obj/machinery/atmospherics/New()
* Rename /obj/machinery/atmospherics initialize() to atmos_init()
* These days `initialize()` is used to handle general object initialization that is moved outside of New(). The node connection discovery of atmos machinery needs to happen after all that, and so needs to be in a separate proc.
* Make sure to actually call atmos_init during system startup.
* This is PHASE 1 of a multi-phase conversion. In this first phase we implement the subsystem, but leave it processing the existing global list variables. In the next phase we will switch to use datum variables in the subsystem. The main reason for splitting into two phases is ease of code review; change the meaningful code without the hundreds of machines -> SSmachines.machinery substitutions.
* We did declare macros for adding/removing things to the processing lists, and convert everywhere to use the macros.
* Added var/is_processing to /datum to keep track of whether an instance is already in a processing list (prevents it being in the list twice!) and also debugging, making sure its not in two lists etc.
* NOTE: The global machines list is **no longer sorted** for performance reasons. As far as I know, the only module that actually ever cared was cameras. Our camera system already handles its own sorting in the cameranets anyway, so it should no longer be needed.
Adds toolspeed var, which is a multiplier on how 'fast' the tool works. 0.5 means it goes twice as fast.
Adds usesound var, which determines what sound is used when a tool is being used.
Changes a lot of code to use those two vars instead.
Adds 'ayyy' tools, which are ported from /tg/'s abductor gamemode. They're currently admin only but I might make them obtainable by xenoarch later.
Adds powertools, also from /tg/. CE starts with them in a new toolbelt that spawns in their locker, ported from (you guessed it) /tg/.
Changes welder sprites to look nicer, ported yet again from /tg/. Modified the blue welder slightly so it can be the electric welder sprite.
Adds various sounds from /tg/, for tools and welders.
* Remove remaining hard del()'s in our code.
* Replace deleted() and gcDestroyed with QDELETED macro.
* Fix some strange calls directly to Del() (capital D)
* Make Destroy() return qdel hints.
* Make a few of the Destroy()'s more comprehensive in cleaning up references.
* In edited Destroy() procs, converted to use qdel_null and qdel_null_list macros when possible for pretty code.
* Removed unused variable `sleevecard`
* 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.
* 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.
* This device converts CO2 to O2 using power and "algae". The extra carbon is a byproduct in the form of "graphite"
* This is intended for virgo3b, which has no oxygen in its atmosphere but enough CO2 for us to just extract it.
Leshana