[Feature] Portable Atmospheric Depot

[Kubius]

Shiny new fully-animated device in the portable-atmospherics category, serving as a specialized hybrid of the portable air pump and gas extractor designed specifically to pressurize or repressurize rooms with a far greater deal of efficiency and smoothness compared to breaking open a canister (albeit at the cost of needing to secure molitz as a catalyst).

The device can be loaded with molitz (up to a cap of just below 100) - once activated, it consumes one unit per full refill of its pressure capacity (this value can be changed), and shortly thereafter transfers the generated atmosphere to its tile. If it runs out of molitz, it will automatically shut down and emit an alert.

Ideally, this would be an item for purchase via the Quartermaster's office as an initial method of introduction. This saves the trouble of having to find a location for it on each station variant.

WARNING: This is almost certainly incompatible with the material stack system and maybe with new materials at large. I don't have access to it on the 2016 branch, so that will need to be fixed before you patch this in (the count system could probably be placed in the istype checks currently commented out, with something like "istype && stacksize > 1 means amount = stacksize"); alternately, you could select an entire other resource.

Also, I heavily recommend that an atmos nerd look at this as well; I was able to successfully pressurize an area on my local test environment, but things may have changed since this variant of the game, and I'm playing with forces I don't fully understand.

https://github.com/goonstation/goonstati...ospheric-d

[Triacontakai]

I would suggest putting this in the warehouse in the same room as the ABC-U since this would be pretty nice for building

Awesome device though!

[kyle2143]

Pretty cool, good sprite too. I've never really liked having to haul a bunch of canisters to an area to re-pressurize it or using the pumps. I like the idea of using a non-atmos resource to generate atmosphere. Can you click drag a bunch of material into it like the furnaces?

The one thing I'm not a fan of is your proc declarations with the whole path in it, which makes me realize I need to change some of mine to be consistent. All the procs you created are in the atmosgen object so you can just use proc/procname inside the current object and just the procname for overriding a proc like Process from obj/machinery. But that's just preference, and I feel like that's mostly what I've seen around the codebase.

EDIT: I take back everything I said. I've seen the light. Force all proc declarations to have the absolute path.

[Kubius]

Can you click drag a bunch of material into it like the furnaces?

Yep! I tested click-drag locally and it's fully functional.

[elan_oots]

The one thing I'm not a fan of is your proc declarations with the whole path in it, which makes me realize I need to change some of mine to be consistent. All the procs you created are in the atmosgen object so you can just use proc/procname inside the current object and just the procname for overriding a proc like Process from obj/machinery. But that's just preference, and I feel like that's mostly what I've seen around the codebase.

Ew relative pathing sucks

On a more serious note, declaring the full path of a proc makes searching for code so, so, so much easier. So much so, in fact, that TG actually mandates you format proc paths that way in their code style guide.

[kyle2143]

I disagree, I think the relative paths make it look cleaner. Though I suppose I see your point considering you can declare new procs for datums anywhere in the codebase outside dm which can make it tough to figure out where everything is. But, if you ask me, THAT is what should be guarded against in a style guide since it's terrible.

[elan_oots]

I disagree, I think the relative paths make it look cleaner. Though I suppose I see your point considering you can declare new procs for datums anywhere in the codebase outside dm which can make it tough to figure out where everything is. But, if you ask me, THAT is what should be guarded against in a style guide since it's terrible.

I think relative paths make it look awful, but the asthetics of relative versus non-relative paths are up to the person. However, you get a tangible benefit from using non-relative paths in that you can search the codebase more easily.

As to code placement, being able to group related components next to each other even if they're not related in the object tree is actually one of the very *very* few things that DM does well. Enforcing rigid object tree placement would completely invalidate stuff like TG's module system (not that it's on g16, but whatever) or having all the chemistry tools grouped together.

[Noah Buttes]

I disagree, I think the relative paths make it look cleaner. Though I suppose I see your point considering you can declare new procs for datums anywhere in the codebase outside dm which can make it tough to figure out where everything is. But, if you ask me, THAT is what should be guarded against in a style guide since it's terrible.

Extensive use of relative pathing is an excellent way to make your codebase harder to maintain.