…(#56317)

Basically when a group with a breakdown timer one tick away from settling merges with a group with hotspots in
it, and the one with a high breakdown timer is larger, the group would settle without respecting the timer of
the hotspot group, causing fwoosh levels of flame.

There's two other ways to achieve this, if you had one group of tiles that are close to the same gasmix as
another
group, and they became inactive, we'd have the same issue. I've solved this by moving the hotspot subprocess to
after active turfs and before excited groups, just for safety ya feel me?

It's still in theory possible, but much much harder. The hard solution to this would be to integrate heat with
how we reset excited group timers, and split excited groups into smaller portions, but I'm not sure I like that
idea.
I need to mull it over.

When I was in the process of developing my atmos fixes/optimizations, I focused heavily on maintaining the area
of excited groups, since growing delayed self_breakdown(), and lead to shitty behavior which I thought was the
result of my sleeping changes.

This was not the case, those who came before me knew better, as always.

Especially now, since I've unhooked breakdown from excited groups gaining new tiles, my concern was unfounded,
and actually lead to shitty behavior and wasted time.

I failed to recognize the value in random garbage_collect()s, they help prevent mass gas equalization over large
spaces, they make gas appear to move more consistently when in these large spaces, and they lessen the amount of
self_breakdown()s over large turf lists, which is very helpful for lowering the overall overtime of the
subsystem.

This fixes my mistake, and purges the excited cleanup subprocess from the air subsystem. It's free real estate
babyyyyyyyy.

Why?

delta_time is about maintaining behavior when changing the wait of subsystems
SSair's wait is dynamic by design, we hardly ever hit below it. What is important then, is maintaining behavior
across each process.

The key point here is making sure excited groups and turfs share the same amoumt of gas each process, no matter
how high or low wait is. This is why subprocesses are a thing in the first place, to maintain this consistency.
delta_time fucks with this, and will end up changing behavior if wait is ever changed.

Makes both the act of starting a rebuild, and the full rebuild itself yield.
This might? Expose some things that rely on parent existing, but that was a problem before, if a rare one. It'll
need cleaned up at some point, but I'd like some feedback on how I'm acomplishing this.

Oh and I changed a very slight detail about how volume is used, instead of storing it throughout the whole loop
and applying it at the last moment, we just operate on the pipeline's volume step by step. This fixes like,
pipes being wrenched up while a rebuild is in progress, and the behavior is older then git, but I figured I
should mention it

* Raises the quantize threshold from 1E-7 to 1E-4.

This makes gas dissipate as expected, and should help with the amount of useless gas floating around the station
at highpop

Adds a garbage_collect() call to the portion of pipeline code where all gasmixes are in one place, this should
clean things up properly.

Changes BREATH_VOLUME from 2 to 1.99. This is imperative
Documents a FUCKING HELLBUG in quantize/breathcode that can lead to breaths just not working sometimes. I'm not
sure how to fix this totally, so I'll document it and pray.
See <https://www.desmos.com/calculator/5icdlnktus>
Adds a unit test to check for this sort of failure.

Addendum for people tweaking this value in the future.
Because o2 tank release values/human o2 requirements are very strictly set to the same pressure, small errors
can cause breakage
This comes from QUANTIZE being used in /datum/gas_mixture.remove(), forming a slight sawtooth pattern of the
added/removed gas, centered on the actual pressure
Changing BREATH_VOLUME can set us on the lower half of this sawtooth, making humans unable to breath at standard
pressure.
There's no good way I can come up with to hardcode a fix for this. So if you're going to change this variable
graph the functions that describe how it is used/how it interacts with breath code, and pick something on the
upper half of the sawtooth
NOTE: I've made this change with a focus on o2 requirements. Changing this will effect other settings, but most
all of them can be ignored, as none will notice.

* Thank you moth man

Co-authored-by: Mothblocks <[email protected]>

* Docs the purpose of the breath unit test, and better explains partial pressure

Co-authored-by: Mothblocks <[email protected]>

Fixes mining not making turfs active, I forgot to add a type arg when I added one to AfterChange(). This isn't the only source of the issue, but it's the most prevalent one

Cleans up total_moles_specific() slightly, there's no point iterating a list if you already have the gas id. Removes a null assignment and if check, they don't catch anything as things are now, and if someone passes null to the proc I want a runtime

Oh and I reordered a bit of atmospherics.dm to make a comment make sense. Don't worry about it

This reverts commit 59537a4.

Writes some documentation on hotspot itself, perform_exposure, hotspot_expose, and process.

Shouldn't have any visible effects. Atmos machines would occasionally complain about parent pipenets not existing during an update and this should resolve a category of those kinds of warning.

(This is a pain side effect of rebuilding being non instant, shoulda been dealt with a long time ago. Thank you -Lemon)

This PR takes the atmospherics.dm in _DEFINES and split it into several files to lower the mess, increase readability and improve on the code for later uses
Also added some docs here and there

…ied by the inverse of the consumption multiplier. (#61557)

The moles in the min checks in reactions.dm will be multiplied by the inverse of the consumption multiplier. This will allow reactions to fully react when it has available gasses. It also makes some of the code easier to read.

Fixes (#61380)

From the issue report above:

Alright. So there's this pattern in reaction code

Looks like this

tgstation/code/modules/atmospherics/gasmixtures/reactions.dm

Lines 597 to 604 in 00154ae
 var/nob_formed = min((cached_gases[/datum/gas/nitrogen][MOLES] + cached_gases[/datum/gas/tritium][MOLES]) * 0.01, cached_gases[/datum/gas/tritium][MOLES] * 0.1, cached_gases[/datum/gas/nitrogen][MOLES] * 0.2)
 var/energy_produced = nob_formed * (NOBLIUM_FORMATION_ENERGY / (max(cached_gases[/datum/gas/bz][MOLES], 1)))
 if ((cached_gases[/datum/gas/tritium][MOLES] - 5 * nob_formed < 0) || (cached_gases[/datum/gas/nitrogen][MOLES] - 10 * nob_formed < 0))
 	return NO_REACTION

 cached_gases[/datum/gas/tritium][MOLES] -= 5 * nob_formed
 cached_gases[/datum/gas/nitrogen][MOLES] -= 10 * nob_formed
 cached_gases[/datum/gas/hypernoblium][MOLES] += nob_formed

We take the minimum of a few values, theoretically because we want the reaction to run with the lowest amount feasible.
So if there's 20 plasma, 10 o2, and 2 n2, and the reaction takes 4 parts plasma, 2 part o2, and 1 part n2, we'll only end up using 8 plasma, 4 o2, and 2 n2. Since we can't react without the n2 and all.

The if check is there to serve as a backup and prevent negative outputs, theoretically because they wreck havoc, though honestly they don't really, so long as the right bitflag is returned the whole mix is garbage collected anyway. Alright sanity check though. that's fine.

You notice how here, because he removes 5x nob formed from tritium, he includes that in the if check? If you scroll out to the right you'll notice that he multiplies the inputs in the min by the inverse of their scalar. At least that's what we want trying to do, mixed the two up.

You get the picture. The min serves to get the lowest possible amount to remove so the reaction can go through, and the if check serves as a sanity check wrapping around it.

The issue is people have been misusing it, for a good while. (Including in this instance)
They most commonly forget to include the inverse scaling in the min(), which leads to these weird fucked phantom gas minimums that aren't listed anywhere, but still stop the reaction.

See:

tgstation/code/modules/atmospherics/gasmixtures/reactions.dm

Lines 690 to 697 in 00154ae
 var/heat_efficency = min(temperature * 0.3, cached_gases[/datum/gas/freon][MOLES], cached_gases[/datum/gas/bz][MOLES])
 var/energy_used = heat_efficency * 9000
 ASSERT_GAS(/datum/gas/healium, air)
 if ((cached_gases[/datum/gas/freon][MOLES] - heat_efficency * 2.75 < 0 ) || (cached_gases[/datum/gas/bz][MOLES] - heat_efficency * 0.25 < 0)) //Shouldn't produce gas from nothing.
 	return NO_REACTION
 cached_gases[/datum/gas/freon][MOLES] -= heat_efficency * 2.75
 cached_gases[/datum/gas/bz][MOLES] -= heat_efficency * 0.25
 cached_gases[/datum/gas/healium][MOLES] += heat_efficency * 3

They need to be updated to not do this, and use min() properly. It leads to dumb graphs like this https://www.desmos.com/calculator/xufgz8piqw (Healium formation graphed out. p is freon, b is bz. if either are reduced below 0, the reaction stops. If you notice this leads to really strange scaling deadspots, and a lot of frustrating behavior)

Thanks to @GuillaumePrata for bringing this to my attention, love you man.

major cleanup of modules/atmospherics folder and all related files, still many missing
-cleanup of procs name
-cleanup of vars name
-documentation of some of the procs
-minor changes to some for() logic (no in game changes just early continue or as anything checks)

No in game changes, only code and docs

This reverts commit 9a4e856.

…me missing fusion powers

…pid I wanna kill myself what the fuck aaaa

…sequences :clueless: (tgstation#62320)

Ever pump hot nob into a tank of oxygen, see the pressure rise to 8000 kpa for a few seconds and have that deafening explosion sound play right after? This attempts to eliminate those by making the pressure transfer proc thingy in gas_mixture account for resulting temperature. The old one is preserved if the temperature difference isn't too big because it's most definitely more performant. The minimum temperature difference of 5 is completely arbitrary and I won't mind changing if asked. Math is a bit messy by necessity but I hope the comment is adequate.

While I'm at it i also changed the return value of those procs to return a removed gasmix instead of directly merging. I sort of needed this for a clean implementation of assume_air in #62284. Will need more testing though. Found a better solution.

Writes a small unit test to check for this too.

Cuts down on one unintended cause of explosions.

About The Pull Request

ALLLRIGHT so
Multiz atmos was letting gas flow down into things that should be well, not flowable into
Like say doors, or windows.

This is weird.

Let's get into some context on why yeah?

First, how do things work currently?

atoms have a can_atmos_pass var defined on them. This points to a define that describes how they interact with
flow.
ATMOS_PASS_NO means well, if we're asked, block any attempts at flow. This is what walls use.
ATMOS_PASS_YES means the inverse
ATMOS_PASS_DENSITY means check our current density
ATMOS_PASS_PROC means call can_atmos_pass, we need some more details about this attempt

These are effectively optimizations.

That var, can_atmos_pass is accessed by CANATMOSPASS() the macro
It's used for 3 things.

1: Can this turf share at all?
2: Can this turf share with another turf
3: Does this atom block a share to another turf

All of this logic is bundled together to weed out the weak.

Anyway, so when we added multiz atmos, we effectively made a second version of this system, but for vertical
checks.

Issue here, we don't actually need to.
The only time we care if a check is vertical or not is if we're talking to another turf, it's not like you'll
have an object that only wants to block vertical atmos.
And even if you did, that's what ATMOS_PASS_PROC is for.

As it stands we need to either ignore any object behavior, or just duplicate can_atmos_pass but again.
Silly.

So I've merged the two, and added an arg to mark if this is a verical attempt.
This'll fix things that really should block up/down but don't, like windows and doors and such.

Past that, I've cleaned can_atmos_pass up a bit so it's easier for people to understand in future.
Oh and I removed the second CANATMOSPASS from immediate_calculate_adjacent_turfs.
It isn't a huge optimization, and it's just not functional.

It ties into zAirOut and zAirIn, both of which expect to be called with a valid direction.
So if say, you open a door that's currently blocking space from leaking in from above, you end up with the door
just not asking the space above if it wants to share, since the door can't zAirOut with itself.

Let's just wipe it out.

This makes the other code much cleaner too, heals the soul.

Anyway yadeyada old as ass bug, peace is restored to the kingdom, none noticed this somehow you'd think people
would notice window plasma, etc etc.
Why It's Good For The Game

MUH SIMULATION
Also fuck window gas
Changelog

cl
fix: Fixed gas flowing into windows from above, I am.... so tired
fix: Fixes gas sometimes not moving up from below after a structure change, see above
/cl

…ying to figure out why every single turf is marked active

* Micro optimizes ssair's turf init, saving 2 seconds

Most of this is making existing operations do more legwork, or cheaper.
I did add cycle checking to ONLY init turf linking, which required
creating a new proc.
Did some horrible horrible things in said proc to save like 0.8 seconds.
I think it was worth it.

…r (#63785)

Each time we intialized a turf's atmos, we checked all the turfs around
it to see if they were different. This meant each pair of turfs talked
to each other twice.

If we instead do the comparing in a second loop, we can use
current_cycle to ensure we only compare a pair once. This saves 0.5
seconds of atmos init.

Speed

We should just straight up not be processing turfs if the adjacent turf
isn't correctly setup

It used to be on a seperate subsystem with a second wait with the idea
of reducing the cost of explosions, but since they're instant now
there's no reason to not just have it on SSair. Gets rid of my excuse
for process_cell runtimes too

<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->

## About The Pull Request

I done fucked it lads. Space turfs are never initialized, so asserting
all shareable turfs have a cycle below 0 is not safe. instead we'll use
-infinity. if that ever breaks I'll eat my shoe
Closes #73961

This reverts commit 4979288.

This reverts commit d21e4ab.

This reverts commit dabd6e3.

 into LINDA-FINALLY!!!!!!!!

…ficantly by 33% (#74233)

It is faster to operate on a gas list, especially if cached, then it is
to operate on a datum.
Doing this cause I'm seeing cost in merge() post #74230

Hits on a few other important places too. self_breakdown and such. Worth
it IMO

Could in theory go further by caching the global list. I'm tempted I
admit but it needs profiling first and it's late

EDIT: I have not slept, and have gone tooo far

[Micros /gas_mixture/copy and copy_from, adds a new proc to handle
copying with a ratio,
copy_from_ratio](tgstation/tgstation@91da000)

[91da000](tgstation/tgstation@91da000)

The ADD_GAS sidestep saves us 0.1 seconds of init (used to at least.
Ensuring we don't break archive is gonna have a cost. I don't want to
profile this so I'll estimate maybe 0.05 seconds). The faster version of
copy_from is just well, better, and helps to avoid stupid

[Optimizes pipeline
processing](tgstation/tgstation@bf5a2d2)

[bf5a2d2](tgstation/tgstation@bf5a2d2)

I haven't slept in 36 hours. Have some atmos optimizations

Pipelines now keep track of components that require custom
reconciliation as a seperate list.
This avoids the overhead of filtering all connected atmos machinery.

Rather then relying on |= to avoid duplicate gas_mixtures, we instead
use a cycle var stored on the mix itself, which is compared with a
static unique id from reconcile_air()
This fully prevents double processing of gas, and should (hopefully)
prevent stupid dupe issues in future

Rather then summing volume on the gas mixture itself, we sum it in a
local var.
This avoids datum var accesses, and saves a slight bit of time

Instead of running THERMAL_ENERGY() (and thus heat_capacity(), which
iterates all gases in the mix AGAIN) when processing gas, we instead
just hook into the existing heat capacity calculation done inside the
giver gases loop
This saves a significant amount of time, somewhere around 30% of the
proc, I think?

This doesn't tackle the big headache here, which is the copy_from loop
at the base of the proc.

I think the solution is to convert pipelines to a sort of polling model.
Atmos components don't "own" their mix, they instead have to request a
copy of it from the pipeline datum.
This would work based off a mutually agreed upon volume amount for that
component in that process cycle.

We'd use an archived system to figure out what gases to give to
components, while removing from the real MOLES list.

We could then push gas consumption requests to the pipeline, which would
handle them, alongside volume changes, on the next process.

Not sure how I'd handle connected pipelines... Merging post reconcile
maybe?
This is a problem for tomorrow though, I need to go to bed.

Saves about 30% of pipeline costs.
Profiles taken on kilo, until each reconcile_air hits 5000 calls

[old.txt](https://github.com/tgstation/tgstation/files/11075118/Profile.results.total.time.txt)

[new.txt](https://github.com/tgstation/tgstation/files/11075133/profiler.txt)