-
-
Notifications
You must be signed in to change notification settings - Fork 683
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] [RECOUP] [PORT] Removes Auxmos in favour of LINDA #11813
base: master
Are you sure you want to change the base?
Conversation
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.
…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)
Bugs left: Gases dont go to tiles that fire has broken glass ontop of |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
@PowerfulBacon I need some help with this, as there are 3 (THREE) calls that should make the UI update, yet they dont update the UI once a tank is removed from a canister. Unless you know how to fix it, i'm resolving this bug as a feature. |
Return true in the ui act call, if its outside a ui act call then raise a call to update_ui(). Something not working can't just be resolved as a feature, it has to be disguisable as a feature to do that. If all else fails just set auto updating to true in ui_act, unlike TG our UIs don't auto update by default |
Canister UI autoupdates because of canister pressure and tank pressure either way, so autoupdate is on. All three attempts did not resolve the issue. Removing the if statement for the related proc that fires once ui_act("eject") is called does not fix the issue. |
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
About The Pull Request
This PR is a recoup of #11165 , due to @JixS4v no longer having time, i've taken upon myself to finish jesus's work.
This should update our atmospherics systems to modern TG. If all goes well, that is
Ported TG station PRs:
Warning: There are a lot of PRs.
share()
canonical. Saves cpu time, makes the simulation proper tgstation/tgstation#63785init_gaslist_cache
to match current code standards tgstation/tgstation#65431change_area
proc to be more accurate tgstation/tgstation#65758Why 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
Screenshots&Videos
Put screenshots and videos here with an empty line between the screenshots and the
<details>
tags.Changelog
🆑 JixS4v, XeonMations, HowToLu, nicbn, Ghilker, haukeschuemann, LemonInTheDark, Tlaltecuhtli, TiviPlus, AlinaStarkova, Putnam3145, TemporalOroboros, esainane, vincentiusvin, ninjanomnom, RandomGamer123, norill, timothymtorres, Pickle-Coding, Arkatos1, zxaber, GuillaumePrata, Aerden, GoblinBackwards, Kylerace, TheBoondock, Tastyfish, MacBlaze1, MTandi, ShizCalev, 13spacemen, spessmanturtle, GoldenAlpharex, Mothblocks, SyncIt21, skylord-a52, san7890, jlsnow301, Hoolny, JohnFulpWillard, ZephyrTFA, FlufflesTheDog, EliteCreature, Sealed101, nikothedude, Deadgebert, TwistedCicrularConvexLens, Jacquerel, mogeoko, tralezab, lessthnthree, intercepti0n, Ghommie, Higgin, chestlet, mc-oofert, afonamos2, SmArtKar
remove: auxmos
add: LINDA
add: smartpipes
/:cl: