Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MDB IGNORE] Deprecates Auxmos in favour of LINDA [PORT] #11165

Closed
wants to merge 121 commits into from

Conversation

JixS4v
Copy link
Contributor

@JixS4v JixS4v commented Jul 9, 2024

About The Pull Request

What it says on the tin. Crossed requested this.

Progress:

Maints, feel free to add or remove PRs on this list to taste. Ping me on discord to request changes to the list otherwise.

Good news though, a lot of the work was in that initial commit.

Reverts #8264 (Sowwy bacon)

Why It's Good For The Game

Auxmos? It's terrible. Just terrible. You know who's behind it? A real bad guy. Kicked out of Beestation! Can you believe it? Total loser!
And lemme tell you, it's causing us nothing but trouble. Big trouble. The biggest! But LINDA? Now that's a system. So good. The best system, maybe ever in the history of systems.
TG - smart people, very smart - they're handling LINDA. They know their stuff, not like those Auxmos bozos. Trust me.
We're gonna throw Auxmos in the garbage, folks. Toss it out like a rotten orange. And we're bringing in LINDA. It'll be amazing. So amazing. We'll fix atmospherics like you wouldn't believe!

Testing Photographs and Procedure

Currently untested since it's a WIP Screenshots&Videos

Put screenshots and videos here with an empty line between the screenshots and the <details> tags.

Changelog

🆑
remove: auxmos
add: LINDA
/:cl:

@JixS4v JixS4v marked this pull request as draft July 9, 2024 00:09
@JixS4v JixS4v changed the title Deprecates Auxmos in favour of LINDA Deprecates Auxmos in favour of LINDA [PORT] Jul 9, 2024
@JixS4v
Copy link
Contributor Author

JixS4v commented Jul 9, 2024

It's normal that this is failing, it's literally less than half done

@EvilDragonfiend EvilDragonfiend added the Priority: Critical THIS IS VERY IMPORTANT label Jul 9, 2024
JixS4v and others added 10 commits July 9, 2024 13:38
…(#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
@JixS4v
Copy link
Contributor Author

JixS4v commented Jul 9, 2024

After the PR run is finished this still needs to actually be made to work
screaming-baby-made-of-ash-v0-6740zeldjc6c1

Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@JixS4v
Copy link
Contributor Author

JixS4v commented Jul 15, 2024

wtf how is this shit not failing checks, this is the worst code ever

Copy link

github-actions bot commented Sep 9, 2024

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@JixS4v
Copy link
Contributor Author

JixS4v commented Sep 9, 2024

Seriously

@Nakalon
Copy link
Contributor

Nakalon commented Sep 15, 2024

Wait, will you be the man to dust auxmos? the fuck? are you jesus?

@EvilDragonfiend
Copy link
Member

mapping is killing this guy, I suppose.

@EvilDragonfiend
Copy link
Member

image

You need to check the error details.

@JixS4v
Copy link
Contributor Author

JixS4v commented Sep 20, 2024

image

You need to check the error details.

I know about this yeah. I haven't had time to get to this. These are trivial to deal with anyways

@JixS4v
Copy link
Contributor Author

JixS4v commented Sep 20, 2024

mapping is killing this guy, I suppose.

Barely, everytime a mapping PR gets merged I weep a little

Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

Copy link

This PR has been marked as stale due to being in an unmergable state for 7 days. Please resolve any conflicts and add testing evidence, then contact a project maintainer to have the stale label removed.

@github-actions github-actions bot added the Stale label Oct 20, 2024
@github-actions github-actions bot closed this Oct 31, 2024
@XeonMations
Copy link
Contributor

Not on my watch you dont, bot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants