Accelerate the atmospheric spread

[Jey123456]

 

My solution to this was shutdown partially because it was not needed according to tiger

because it isn't a damn problem. LINDA is working 100% as it is intended to

.

 

So i am turning into the suggestion topic to see if people really are happy with how LINDA is currently working, i know that personally i am not, a breach 5 tiles into a corridor should not be ignoreable simply because LINDA air movement cut in half for every tile distance from the source (5tiles deep to a space breach mean only 3kpa is taken from the tile per cycle under normal pressure scenario) .

 

Trying to stabilize pressure in an over-pressured room is also a nightmare since it can take up to 10 minutes before the air a few tiles away get finally affected by a scrubber that happen to be slightly too far.

 

Fixing underpressurized room is not as much of a problem since you can leave the vents on their default settings and eventually it will be breathable, or you can run around with an air pump at 100kpa on every tiles of the room, since apparently humans move multiple times faster than air propagation from half pressure to full pressure.

 

There is a similar problem with heating up a room, you cannot just put a heater at 50C in it and hope for it to stabilize without ending up with the side where your heater is at 50C and the other side at 0. You have to grab it and walk around the whole room, since apparently the only form of heating that would work on the station would be having a heating element every 2 tiles.

 

 

I know i can be a pain in the ass, but i love atmospheric work, sadly on paradise atmo tech are nothing but engineers with no access to gloves since engineers can do our main work just the same (patching holes). Atmospheric itself is no threat to the station even when breached, people have multiple minutes to realise the area is breached and just walk out without even having their internal on. They also have no fear whatsoever of breached rooms, and will completely ignore firedoors / inflatable door (leave them open) since the impact is so little that nobody cares. Theyll just put on internals and walk in to do their thing like everything was fine.

 

This also mean theres essentially no real use beyond RP to the inflatable walls / doors since normally they would be used to isolate breached / damaged section from the undamaged section to avoid ruining the atmospherics here as well since the great LINDA do that on its own, once something is a few tiles away, unless you leave it be for 30minutes, there is no risk for it to become dangerous.

 

You can do a whole shift with no atmospherics so long as you have engineers and you would not even notice there is no atmo techs.

On the other hand a round without engineer and only atmo tech will very quickly be over unless the atmo tech request engineering access, or break in engineering sections to get the station in order / access to what he need to fix stuff.

 

[Shadeykins]

 

Most of the admins love LINDA.

 

Most of the players don't want anything to do with it and more or less want ZAS back.

 

Coders don't want to touch atmospherics because they took so much time putting LINDA in, and stripping it out in any capacity would invalidate their work (Which is a really, really moot point and bad practice as a programmer).

 

Atmos technicians don't even have access to use EngiVend and get air alarm electronics, making their job even more laughable. The only thing an atmos tech can do that even remotely matters is to reconfigure the scrubbers, and that's only ever relevant if there's a massive plasma fire.

 

I remember Fox (or Tiger) got fed up with people complaining once and put LINDA on 4x speed for one round. It worked just fine without a noticeable difference in server performance on the client side, so I'm not sure why it's speed hasn't been amped anyways.

 

ZAS is way more intensive at rest, but LINDA gets to be just as bad (if not worse) whenever there's multiple station breaches - rounds basically become unplayably laggy (Thankfully multiple major breaches is not the norm). The tradeoff is a basic at-rest performance boost at the cost of a full atmospherics system.

 

A simple solution in my mind is to change LINDA air movement to not be cut in half, and instead be cut into quarters or eighths so it pulls more pressure from tile to tile and has wider reach which is probably exactly what was done during that experimental round. If the argument against that is "it would create more lag", I'm unsure what to say - simulating actual atmospherics occurring (which is a major gameplay mechanic of SS13) is going to put pressure on the server. LINDA in it's current iteration basically prevents lag by virtue of not simulating full atmospherics.

 

I've always strongly been of the opinion that it would have been better to address the problems with ZAS and work on efficiency and performance (fine-tune it) rather than scrapping it entirely. Atmospherics could have been reworked from the ground up in a similar time-frame (LINDA took several months to implement, if I recall correctly), or ZAS could have been massively improved.

 

Every time I've brought that point up though, I've been told that "you're not a coder you have no pr's" (despite the fact I'm a programmer), so let's hope someone listens to you (as you do have pr's).

 

Either way, much like every other LINDA-related suggestion you can expect this topic to more or less be locked ASAP.

 

[Jey123456]

 

the thing is, the lag from linda is nothing currently, even in massive breach that lag could very easily be absorbed by running the process more often and do only part of it at a time (like i did in my pullrequest), essentially use the same cpu average, but not all at once. The actual cpu usage is nothing, were barely talking 12% in the very worst case scenario i saw. The thing is, when that 12% is done all at once every 2 seconds players will feel it, if its done in 4 smaller increments there is no impact worth mentioning.

 

So quite frankly, saying its too cpu intensive to have a proper atmospherics is merely not wanting to fix the lag from it. Cpu usage and lag felt by players are 2 very different things (unless offcourse cpu usage is 100%).

 

 

LINDA is one of the best ss13 atmospherics system i saw at dealing with short distance transfer in dynamic room area (zas had a lot of problems if you kept modifying the room like adding walls / isolate a breach etc). Its only real shortcoming is long range transfer, sadly its a big shortcoming that wont just disapear unless we do something about it.

 

[Shadeykins]

 

the thing is, the lag from linda is nothing currently, even in massive breach that lag could very easily be absorbed by running the process more often and do only part of it at a time (like i did in my pullrequest), essentially use the same cpu average, but not all at once. The actual cpu usage is nothing, were barely talking 12% in the very worst case scenario i saw. The thing is, when that 12% is done all at once every 2 seconds players will feel it, if its done in 4 smaller increments there is no impact worth mentioning.

 

So quite frankly, saying its too cpu intensive to have a proper atmospherics is merely not wanting to fix the lag from it. Cpu usage and lag felt by players are 2 very different things (unless offcourse cpu usage is 100%).

 

 

LINDA is one of the best ss13 atmospherics system i saw at dealing with short distance transfer in dynamic room area (zas had a lot of problems if you kept modifying the room like adding walls / isolate a breach etc). Its only real shortcoming is long range transfer, sadly its a big shortcoming that wont just disapear unless we do something about it.

 

Whenever there's multiple station breaches (especially around the bridge/in hallways) the sudden onset of performance related issues is pretty noticeable, meaning that if what you're getting at is an absolute certainty there's still a lot to be changed in terms of efficiency and performance.

 

Anyways...

 

It's a sore spot among the coders who constantly get attacked about LINDA, and an unpopular topic for admins who constantly have to deal with vocal backlash.

 

Really though, I'm not saying much of anything aside from unless you go ahead and make LINDA work as a proper and realistic atmospherics simulation (and not just space-wind ahoy), nobody else is going to.

 

Pretty much every suggestion regarding LINDA since it's inception on the server has been shot down, and AFAIK maintainers and coders don't ever want to do anything with atmospherics whatsoever again due to it being "snowflaked" everywhere.

 

[Jey123456]

 

The data i got is from live profiler on a round where it was lagging to hell and most of the time was spent on linda. the average per air processing call was 0.3sec. Thats 0.3sec lag every 2 sec (which in turn delay other tasks and snowball in larger lags).

 

If it had been split even just in 2, then the delay would have been of 0.15 sec every second, which is a lot easier for byond to catch up on (and cut it in 4 and you have 0.075 sec every 0.5 sec which would not even gonna delay anything at all internally.

 

LINDA itself is not efficient enough to handle long distance (even if you accelerate it your just wasting a lot of cpu time doing a conga line that drop by half in speed for every tile) thats why i had written an addon that took care of the long distance and let the short distance into LINDA's hands. Offcourse that pullrequest needed some cleanups before it would be up to paradise standards, but that would not have been a problem to do if there was even a little bit of interests by the maintainers instead of shutting it down due to it increasing cpu load (note cpu load, not lag)

 

[LiquidNightfury]

LINDA is honestly a pain in the ass system which is both unrealistic and unwieldy. Coming from someone who basically played nothing but atmos for a few months, it's just frustrating to work with, and any improvements to the sluggish jelly air and space wind would be awesome.

[Shadeykins]

 

If we cross the number of registered forum users against GitHub contributors (2472 vs 100), we can see that only 0.04% of registered forum users have contributed to the GitHub. That number shrinks considerably when we consider most people haven't even registered for the forums.

 

There was a wopping total of 170,000 characters (judging by deaths) for the year of 2015, and if every person had ten characters (unlikely) we still wind up with 17,000 unique users on the server for the year of 2015. Going by this number, we can see that only 0.14% of the players on the server (for the year of 2015) have a forum account and only 0.005% of players are a GitHub contributor/make active postings on the GitHub.

 

Roughly one in two hundred and fifty users makes a forum account to post, and one in twenty thousand looks at the GitHub on any regular basis.

 

.005% of players have a share of 99.96% of the power when it comes to PR's on the GitHub.

 

One GitHub users' vote counts for 20,000 players, as opposed to one forum user who's vote only counts for 250 (A much more reasonable, but still awful sample).

 

In other words, if a maintainer has said no you're going to need to make a clear-cut suggestion with demonstrable gains and get support from the headmins who can then override the maintainers (if they can, at all - I've honestly lost track of who runs the server since Necaldun left).

 

This is also why I'm against anything whatsoever being suggested/discussed on the GitHub, for reference.

 

[DZD]

 

Oh, what's this? Another atmospherics circlejerk. Greeeeeaaaaaaat.

 

Most of the admins love LINDA.

Largely true, although quite a few of them have the same issues with it that you bring up in this post.

 

Most of the players don't want anything to do with it and more or less want ZAS back.

Care to qualify this statement at all? It sounds an awful lot like you're trying to speak for a fairly large group of people without any actual proof that you embody all of their opinions. But nobody would do that, right?

 

Coders don't want to touch atmospherics because they took so much time putting LINDA in, and stripping it out in any capacity would invalidate their work (Which is a really, really moot point and bad practice as a programmer).

More criticism coming from somebody who has never so much as submitted a PR, but let me break it down anyway. The head admins and a majority of the admin team had agreed that ZAS was more or less shit (I'll get more into the reasons below), and that we should port LINDA. It was a fairly large project, but it had gotten to a point where the head admins at the time had even put up a monetary reward for anybody who was able to successfully port it. Tigercat2000 fully ported LINDA from /tg/'s codebase over the course of a week and even refused the bounty on it.

 

Atmos technicians don't even have access to use EngiVend and get air alarm electronics, making their job even more laughable. The only thing an atmos tech can do that even remotely matters is to reconfigure the scrubbers, and that's only ever relevant if there's a massive plasma fire.

There's a little something called the "atmos waterpack" that is a neat little tool that atmos techs have access to that is almost functionally useless under ZAS. It is equipped with an 8 tile range fire extinguisher, a nanofrost "grenade" launcher, and a metal foam sprayer. The extinguisher and nanofrost only work under LINDA, as you could not cool down atmos using extinguishers under ZAS so they only served to put out a small bit of fire before it ignited again, and nanofrost essentially only "froze" vents shut, as you similarly couldn't affect hotspots under ZAS because there were none. In short, firefighting is something you can actually do under LINDA, and with ZAS all you could do was vent a room, then refill it with air only for the tiny bit of remaining hot air to bring the room to uninhabitable temperatures.

 

I remember Fox (or Tiger) got fed up with people complaining once and put LINDA on 4x speed for one round. It worked just fine without a noticeable difference in server performance on the client side, so I'm not sure why it's speed hasn't been amped anyways.

Yes, a round that did not have any major breaches nor any plasma fires. This is really a moot point, if you want to see how laggy that can be, try to flood the station with plasma and light it while LINDA is running at 4x speed.

 

ZAS is way more intensive at rest, but LINDA gets to be just as bad (if not worse) whenever there's multiple station breaches - rounds basically become unplayably laggy (Thankfully multiple major breaches is not the norm). The tradeoff is a basic at-rest performance boost at the cost of a full atmospherics system.

LINDA at its current firing rate is quite a bit more efficient than ZAS unless you have an ungodly amount of active turfs. Additionally, large plasma fires under ZAS nearly always required a server restart due to the fact that the server was brought to its knees. LINDA can actually handle major plasma fires, and unless you manage to break a whole to space in nearly every room in the entire station, will be running a lot more efficiently than ZAS.

 

A simple solution in my mind is to change LINDA air movement to not be cut in half, and instead be cut into quarters or eighths so it pulls more pressure from tile to tile and has wider reach which is probably exactly what was done during that experimental round. If the argument against that is "it would create more lag", I'm unsure what to say - simulating actual atmospherics occurring (which is a major gameplay mechanic of SS13) is going to put pressure on the server. LINDA in it's current iteration basically prevents lag by virtue of not simulating full atmospherics.

Yeah, this isn't how LINDA works at all. If you're an actual programmer, try to actually read the LINDA code before you suggest how it could be changed. BYOND code isn't that difficult to read coming from a C-based language or Python.

 

I've always strongly been of the opinion that it would have been better to address the problems with ZAS and work on efficiency and performance (fine-tune it) rather than scrapping it entirely. Atmospherics could have been reworked from the ground up in a similar time-frame (LINDA took several months to implement, if I recall correctly), or ZAS could have been massively improved.

Ahahahahahaha. No. ZAS code was almost completely and utterly shit. It worked through almost literal black magic. The code was so old and horrible that nobody wanted to touch it with a 10-foot pole. It can take absolute ages to debug a shitty system and fix the problems with it, then fix the bugs you introduced while doing so. Introducing a working atmospheric system that uses sensible coding practices is leagues simpler. If you want to go through, revert to a version of the codebase where we still had ZAS, then fix it, feel free to spend a good month or two doing so.

 

Every time I've brought that point up though, I've been told that "you're not a coder you have no pr's" (despite the fact I'm a programmer), so let's hope someone listens to you (as you do have pr's).

There's a good reason for this. A large portion of the codebase is horrendously coded (usually the older the code is, the worse it is from a design and coding practice standpoint). If you ever tried working with pipe code you will know what a nightmare this can be. If you haven't even touched SS13 code, you haven't a single clue.

 

Either way, much like every other LINDA-related suggestion you can expect this topic to more or less be locked ASAP.

Blah blah blah that admins are dictators blah blah blah. These get locked because people start getting at each other's throats over a shitty system in a 2D spaceman game.

 

Pretty much every suggestion regarding LINDA since it's inception on the server has been shot down, and AFAIK maintainers and coders don't ever want to do anything with atmospherics whatsoever again due to it being "snowflaked" everywhere.

 

You want to know why we hate snowflake code? Why pretty much every modern codebase's standards tell people to avoid it? This is why. Ninja code is the epitome of snowflakey code and complete ignorance of object oriented code. BYOND is fairly shitty as a coding language in some respects, and lets you do hacky things like that, but that doesn't mean that you should. It makes code incredibly difficult to maintain, and at times even to comprehend, and makes it very prone to breaking. For that reason, ninja code was, for the longest time, the bogeyman lurking in all SS13 codebases. It touched so many different things nobody wanted to have anything to do with it. The best thing that could be done (and is currently being done or has been done on most of the major codebases) was to remove it and recode it from the ground up.

 

In short, ZAS was absolute horseshit. From a code standpoint, its code was horrid, difficult to maintain, and worked through literal black magic. From a mechanics standpoint, I'm going to ask you to take off the rose-tinted goggles for a moment and consider how shitty it actually was. One idiot breaking a window in escape would often result in half the station depressurized. One opened plasma canister would instantly fill up a room with plasma, which would inevitably spread as idiots opened shutters and spread it around, until somebody's damaged mechanical limb sparked and turned the blinding plasma deathtrap into a burning plasma deathtrap that eventually made the entire station uninhabitable and made the server run at a snail's pace. Wall slamming, especially from fires and breaches would permanently stun people against walls while they slowly died from high temperatures/depressurization. Let us not even bring up the fact that under ZAS, large bombs would create a pressure nightmare that would cause a noticeable drop in server performance until the round was over. ZAS was good in one respect, and that was creating murderous deathtraps. While that may be realistic, from a gameplay standpoint it was incredibly frustrating to deal with.

 

This has been said before, but I'm going to say it again. If you want to re-code ZAS and fix all of the issues with its code, then try to submit it as a PR, feel free. Chances are though, if you do that, the PR will be rejected due to ZAS being garbage from a gameplay perspective. If you want to code an entirely new atmos system that addresses the issues with both ZAS and LINDA, feel free to do that as well, although keep in mind you'll find that to be a difficult task.

 

[Jey123456]

 

this topic is not about recoding ZAS tho, its about improving LINDA atmospheric spread rate since right now, that part is shit.

 

ZAS was the other end of the spectrum, if anything in large rooms it was much too fast, and especially too randomly violent and had major trouble dealing with rooms changing shape.

 

[TullyBBurnalot]

 

I wasn't going to post here, due to the nature of what DZD said, but I would like to point out a couple of things.

 

First off, no, I don't go to the Git. I'm not a coder, I have no idea how code works, and I trust the Maintainers/Coders to be sane, as I have no reason to believe otherwise. As such:

 

If we cross the number of registered forum users against GitHub contributors (2472 vs 100), we can see that only 0.04% of registered forum users have contributed to the GitHub. That number shrinks considerably when we consider most people haven't even registered for the forums.

 

And the number shrinks even more when you consider the majority of those forum accounts are either one-shots for ban appeals, troll accounts, people who aren't here, people who aren't interested in code and people who don't actually contribute and just have an account on standby for whenever, or only participate in Civilian's Days, or any of that section.

 

Yes, these are all ways to contribute to the community, but believe or not, most people aren't interested in discussing changes to the codebase, and trust the Maintainers and Headmins to do their job properly.

 

There was a wopping total of 170,000 characters (judging by deaths) for the year of 2015, and if every person had ten characters (unlikely) we still wind up with 17,000 unique users on the server for the year of 2015.

 

I'm going to assume you mean there were 170,000 deaths in the year of 2015, which would be a nice estimate. If so, should I point out how that is a ridiculous way of estimating the total number of characters, considering how many times a single character dies?

 

And if that's not what you meant, here's a coder:

 

 

So yes, the death table is an incredibly poor and unreliable way of ascertaining how many characters exist, which invalidates your entire argument from this point forward. But I'll continue.

 

You also have no way of figuring out how many characters there are per player, but kudos for using the "best" possible outcome of 10 per player. Still, unreliable, invalidates the calculations.

 

Going by this number, we can see that only 0.14% of the players on the server (for the year of 2015) have a forum account and only 0.005% of players are a GitHub contributor/make active postings on the GitHub.

 

Refer to the above statement. And the above above statement because, surprise surprise, some people don't care about code, and most people aren't qualified to discuss it. Believe it or not, having everyone go to the Git would be a terribad bloody idea, because not everyone knows what the hell they're talking about, and not everyone understands code.

 

.005% of players have a share of 99.96% of the power when it comes to PR's on the GitHub.

 

And once again, above statement. I should also point out, currently, 5 players have the actual power to do anything on the GitHub, 3 Maintainers and 2 Heads of Staff. Because while we do take into account valid criticism, these are still the people that are entrusted with maintaining the codebase. Why yes, not all GitHub accounts are created equal. Imagine that.

 

One GitHub users' vote counts for 20,000 players, as opposed to one forum user who's vote only counts for 250 (A much more reasonable, but still awful sample).

 

No. Just no. No one's vote counts for anyone else's (and I dearly hope that 20,000 player figure is hyperbole. And even if it is, bad extrapolation is bad). The forum and the GitHub are all publicly available to anyone who wants to go there. And I know exactly what you're going to use as a counter-argument, to which I say:

 

1) There's a Changelog button the same size as the Forum button in-game;

 

2) Most people don't want to discuss code

 

At the end of the day, the Maintainers and Headmins make decisions based on what they believe would improve the game experience for the playerbase, which is information that they gather based on:

 

1) Yes, forum and GitHub posts, but also:

 

2) In-game experience;

 

3) Direct contact with the community;

 

4) Second-hand accounts from players and Staff;

 

5) Contact with the Staff and their own experiences in all these points.

 

This isn't a simple numbers game.

 

In other words, if a maintainer has said no you're going to need to make a clear-cut suggestion with demonstrable gains and get support from the headmins who can then override the maintainers (if they can, at all - I've honestly lost track of who runs the server since Necaldun left).

 

If a Maintainer has said no, odds are it was either a bad idea, a badly implemented idea, or something that is incompatible with current code. No, there isn't a big bad conspiracy out to crush the players so we can sit on our thrones built from skulls. Not all ideas are good ideas.

 

Also, the ultimate well-being of the community is what runs the server. That's why, even when unlisted, Paradise is still peaking at 70+ during weekends on peak hour. Guess the system's working.

 

This is also why I'm against anything whatsoever being suggested/discussed on the GitHub, for reference.

 

1) There's a Changelog button the same size as the Forum button in-game;

 

2) Most people don't want to discuss code

 

 

[DZD]

 

Fair enough, although inevitably whenever somebody brings up atmos, a shitstorm always begins because a few players can't put down their nostalgia goggles for a moment and still believe that ZAS was leagues better than LINDA.

 

I do agree that LINDA is too slow, and that speeding it up would be ideal in making atmospherics a bit more dynamic, however the main problem with it that was mentioned in the PR was performance. Anything that speeds up LINDA is ultimately going to increase CPU load, and simply increasing the rate at which LINDA updates is going to be one of the least efficient ways to increase the speed of atmospherics. Your PR did increase the speed of long-distance however it did have the drawback of causing a noticeable increase in CPU load, although less than increasing the processing rate of atmos.

 

The main issue with that is that the server isn't in a position to be able to just take a hit to CPU load at the moment, and it isn't something that you can easily notice in local testing. Atmos isn't the only major CPU hog, mobs (especially humanoids) and their Life() procs use up quite a bit, del uses up the most, and the humanoid update_icons proc is an absolute nightmare. Reducing some of that load might make enough room to speed up atmos. The other large issue was maintainability. At the current moment, we are almost entirely up to date with /tg/'s atmospherics code (the one difference is their use of subsystems, which does provide the benefit of reducing the processing rate of different systems, including atmos, when the CPU is under heavy load) and would ideally prefer to keep it that way. Any changes to ours is going to make it more difficult to keep our code up to parity with theirs. There isn't really any way to avoid this unless they were to implement the same system, but in this case the benefit of changing atmos code needs to outweigh the detriment of making it more difficult to maintain (keep in mind that we have a noticeably smaller coder:player ratio than the other major codebases).

 

[Jey123456]

 

But that is the problem, people seem to believe cpu = lag. Its not the case unless cpu is above 90% (and even then, properly balanced code could be lagfree above that).

 

The reason LINDA lag when there is too much load is due to it doing all that load in a single "cpu frame". a single execution block of 0.3 second every 2 seconds will have huge lag repercutions to the code, right off the bat, thats a 0.3sec lag minimum, but on top of that you have all the other process / spawn / sleep that ended up being late due to that 0.3sec and end up executing right away, if any of those are also long, it pile up and you enter a viscious cycle.

 

On the other hand, having that same cpu time of 0.3sec every 2 seconds, but spread every 0.5 secs instead, mean that the execution block is now only 0.075 second. This is small enough that byond do not incur any delays from it, players will barely if at all notice it either since byond update the remote screen in a thread for as long as no ticks are late.

 

Now offcourse, if during a 30seconds profiler rate during those heavy atmo round revealed that the air process was taking 40-50% of the cpu on its own, it would be a different story, but as of yet the worst case scenario i saw was 12% and it was barely playable for the reason i mentioned earlier. Theres plenty of unused cpu time to go around, it just need to be better shared.

 

 

On the parity side of thing, i fully agree, this is why when i wrote my PR i kept linda change to a bare minimum (2 lines insertion to act as hook, pretty much impossible to actually cause conflicts in merge)

 

[GelatinousGlob]

 

One way or another, LINDA needs some serious work, work no one seems to want to do because it is a bunch of shit to mess with, which is perfectly understandable. When LINDA was first implemented everyone was told to wait for updates and improvements to the system, most of which never came. Instead there were bandaid fixes such as vent and scrubber extensions, 'refill' button that just set the vents to triple the pressure (and causes more problems than it fixes). While it is something, it doesn't really help that much and more needs to be done at some point.

 

ALL THAT SAID, there are other simpler solutions that should be implemented eventually anyways.

 

If you want less complaints about LINDA without big coding updates, you need to redo the entire stations atmospherics pipe system. That means relaying 95% of the pipes on station into smarter configurations. If part of station explodes, trying to hook the pipes back up is a massive undertaking because they are laid pretty much randomly at this point. When the bar explodes I have no idea which sides the air is actually coming from, you can only try and locate the ends and hook them together and hope you didn't make an empty loop of pipe that goes nowhere.

 

If you did re lay the pipes, you could have pipe mains that largely go down the major hallways, that branch into rooms at logical points like near doorways (pipe drilling into reinforced walls is atleast a huge improvement itself right now), then once that pipe main is into the room you could branch it off tree-style to regularly laid vents and scrubbers that can more effectively fill and syphon rooms in reasonable amounts of time. The bar itself should have at least 8 vents to effectively fill it if not more, and not have half the room at 300 kpa and the other half at 5 kPa. At the same time, this would give a chance to create atmospheric nodes (like the little atmos closets that we have but are currently useless) where parts of the station can be individual cutoff or supplied by canisters or drained to allow easier repairs. Each department should have its own central atmosia node. Science should have a closet, medical should definitely have its own closet that can isolate it, security, command, arrivals hall, and engineering. Right now its all one continuous spaghetti mess and doing any fun atmosia stuff is very difficult if not impossible due to time constraints per shift mainly consisting of running around with a t-ray and trying to decipher that mess. It would make actually using atmosia for something other than grief possible as you could flood or cut off small areas of the station for specific purposes and objectives.

 

Also, air alarms would be more useful if changed to take an average of the room so they respond faster to breaches and make filling rooms easier to do. If you could get the average of the room, you could turn the shit off and let the room equalize instead of continuously pumping air in until you end up with twice the intended pressure. It doesn't have to update every second either, an average every 5-10 seconds would be enough.

 

 

To summarize, a repiping of the station would be the simplest 'fix' but is still a big undertaking. Add in atmospheric nodes for departmental air supplies, apply vents in a tree branch fashion for big rooms and halls, possibly make air alarms take average readings of rooms or larger sections, maybe reading and the averaging all the room's vents and scrubbers? Or otherwise make gas sensors read into air alarms and spread them around.

 

 

 

vvv Additional unrelated trash vvv

On an unrelated note, unless/until these problems are fixed you should really give atmosians more access. Engineers can use air alarms but atmosians can't use APCs, cant go into the engineer supply room, cant use engivends, cant go into tech storage, cant open engineer, welding, or electric lockers. Cant even use the ore vendor to get metal, plasma glass (which are the only job that even use it), or plasteel to fix atmosia breaches or upgrade the turbine or build other fire safe shit. Engineers meanwhile even have access to their own pipe dispensers both in secure storage and on the engi outpost. Amtosians might even benefit from a second pipe dispenser. Even expanding atmosia (hard to do without moving a lot of shit) or otherwise making a large construction area would give them more to do than sit in atmosia and formulate plans to burn the station down. There isn't even a lot of room for atmosia experimentation without tearing the entire place apart, that some of the reasons why I havent been able to test passive vents which have been broken, removed, re-added, removed again, added again, and are probably still broken. They were really the funnest vents that let you create some crazy things and can the results at high pressures. (BTW, passive vents are suppose to equalize gas and pressure from within the pipe and with the surrounding atmosphere, I don't know if LINDA broke them or if it happened afterwards, but I had a coder ask what they even did before to try to fix them but I don't think it worked or they didnt understand what I said, essencially they should act how you would expect a broken/open pipe into a room would do in real life)

 

[Citinited]

 

As is stated, most people wear rose-tinted glasses when it comes to ZAS and forget how shit it was when it stunlocked you/ had starboard primary instantly fill with plasma from a canister on the other side of the hallway / had flamethrowers and other things not work / had an entire room depressurise in seconds from a one metre breach / had the station be a deathtrap / other.

 

Also, people love to bring up the argument that LINDA is not realistic. It's a damn sight more realistic than ZAS (no, a one-metre breach to space will not explosively decompress a room as big as escape), and besides realism is a poor argument to make in this game anyway. LINDA actually will also make a room uninhabitable if that room is left unchecked; it just doesn't happen, you know, immediately.

 

Sorry for the sort of rant, this topic's been done to death and every time the exact same arguments are brought up.

 

[Jey123456]

 

people keep saying noone want to touch linda, but i do want to touch it. We are not allowed to touch it would be more appropriate. If the only constraint was using less cpu, i could very easily achieve it by editing linda directly . The only reason my PR used more cpu was because i was trying to retain LINDA parity on the code.

 

On that side, there is also another approach that would drop cpu usage by about 33% vs the current linda simply by slowing it down to twice the current speed, but editing the air currents code i wrote to pick up the slack and move more air. It would come with the cost of not looking as pretty since you would clearly see the lines appear when a section become active but other than that the result would be faster atmospherics at lower cpu cost.

 

Sadly the PR was closed by maintainers before it had a chance to be improved to fit their unstated requirements. (the only requirement i knew off when i wrote that PR was the linda parity, which i kept. Cpu was never a concern since live do not use even 2/3 of its cpu let alone all of it (probably average less than 1/3), but if cpu is a problem its easy to work around just the same. It merely mean paying a price somewhere else.

 

I pretty much live as atmo tech, i played under both zas, linda and the slow version of linda we have. I know full well that ZAS was nowhere near perfect and personally i see much more potential in LINDA than ZAS. Its just that this potential is mostly untouched since noone is basically allowed to touch it.

 

And yes, linda will depressurize a room given a very long period of time, but not if that room is a long thin corridor. The only time linda work somewhat ok, is if the breach is close to the center of the room (small room). No it should not instantly depressurize in an explosive fashion, sure in RL if a hole the size of what we have for wall tile was to happen a hell of a wind would show up for a fraction of a second, but thats about it, and in ss13 we can easily assume that those hole are much smaller, its just that a tile is our smalest unit for that kind of damage. I am not for instant and deadly breach. But i am also not for the extremely slow atmospheric spread we have currently.

 

[Shadeykins]

 

-snip-

 

Based on deathrows distributed by gender, as actual honest playercount numbers aren't readily accessible.

 

Whether or not this is a democracy isn't really relevant (vote wasn't the greatest word), as I was aiming to demonstrate share of power. Share of power is most commonly understood in the metrics of a voting system.

 

There's a lot of things that are slipped through in PR's that are not remotely discussed yet are pushed through because they go under the radar, a great example of this is UltimateChimera sneaking in a PR to remove the xenosuit on the outpost.

 

I brought up the point I did because it's related to maintainers having absolute veto and not being even remotely required to provide any solid reasoning for it, were this a suggestion that would be fine but work has gone into this and it provides positive improvement to the existing atmospherics system, so it's not.

 

CPU load does not directly correlate with latency, and rooms having greater reaction to atmospherics changes is a plus, not a negative.

 

Also, people love to bring up the argument that LINDA is not realistic. It's a damn sight more realistic than ZAS (no, a one-metre breach to space will not explosively decompress a room as big as escape), and besides realism is a poor argument to make in this game anyway. LINDA actually will also make a room uninhabitable if that room is left unchecked; it just doesn't happen, you know, immediately.

 

Actually...

 

When we're talking about a difference between a normally pressurized room and the void of space we're talking about air being sucked into the void of space at sonic velocity (or mach one), since SS13 works off tiles (we can assume metre by metre), the smallest possible breach (not accounting for corner window madness) is one metre by one metre.

 

We'll say escape is a wopping 100m^3 and has a standard volume of air at room temperature (Approximately 300K) if we do actual the actual calculations escape will contain half it's atmosphere in... (Down to lethal pressure levels)

 

3.4 seconds.

 

If you were standing near the breach this would qualify as explosive decompression in terms of effect on your lungs, whereas if you were at the other end of the room it would qualify as rapid decompression.

 

As the pressure will never equalize (there's not enough volume on the station to equalize with space) in another 3.4 seconds (or 6.8 seconds) escape would be at 0kPa. This is with a 1x1 metre breach, if we had a 2x2 metre breach (or four tiles exposed to space, remember that volume is exponential so this is 4x, not 2x) we're now looking at 1.7 seconds for a full drain to 0kPa, a standard bomb can make as many as ten to twenty breaches (5x5 or 10x10) which would drop the drain time into milliseconds (Full explosive depressurization across all exposed spaces).

 

This is using calculations provided by McGill University.

 

Math is FUN!!, but either way this isn't really about explosive decompression and doesn't implement it.

 

This is more about atmospherics being entirely closed off and PRs being outright refused/not even being deliberated simply because they are atmospherics PRs.

 

[Jey123456]

 

Its all a matter of balancing fun with realism when your talking about a "simulation" game. (as cartoony and exagerated ss13 can be, it still remain a simulator)

 

Having a room open to space is something rather common on ss13 so if it meant instant death for everyone with no internal, 5 sec death for everyone with no hardsuit whenever a breach occured in their vicinity. It would not be fun.

 

On the other hand, when breach are of so little impact that people have time to stand around, not worry about doors being open have a chat, do their thing and then finally gently walk out. Thats also not fun.

 

It comes down to finding a balance which we dont currently have as far as im concerned.

 

[tigercat2000]

 

There's a lot of things that are slipped through in PR's that are not remotely discussed yet are pushed through because they go under the radar, a great example of this is UltimateChimera sneaking in a PR to remove the xenosuit on the outpost.

 

 

Wh.. How do you even slightly draw this conclusion? Chimera got through a non-mentioned change because we were so stupid as to go "okay fine you don't get how to use the simple mapmerge tools, we don't need mapmerge, it's the asteroid anyways", which is definitely not happening again. What he did isn't even slightly acceptable, and I'm surprised we didn't ask for github support to ban him from the repo.

 

 

CPU load does not directly correlate with latency, and rooms having greater reaction to atmospherics changes is a plus, not a negative.

 

Wat

No really, explain this to me. Do you think that the server performance doesn't matter for a game that is almost completely handled serverside, clientside code doesn't even exist for anything but UIs? Because it really does. If the server is lagging badly, chat messages are no longer sent, map data to render is no longer sent, client input can get dropped, user interfaces might 'work' but won't actually allow you to call back to the server.

 

This is more about atmospherics being entirely closed off and PRs being outright refused/not even being deliberated simply because they are atmospherics PRs.

This PR was closed because not a single one of the coders approved of the performance impact, adding a lot of code to LINDA, and changing how atmospherics worked for the sake of a semi-sped-up simulation.

 

[Jey123456]

 

I'll explain it another time just for you tiger. Cpu usage does not equal lag, execution blocks longer than a tick do (more precisely, execution block that step on a pending process from a sleep or spawn) From the profile data i gathered on live (since i dont have the world.cpu value thats the closest i can get), its pretty easy to tell that even under very laggy situation the actual cpu usage rarely pass the 40% mark, and most likely never (except when a large lag like a ton of qdel are being handled) reach 100.

 

Lag as far as game are related, depend directly on how long it takes before the server can send an update to the clients, so long as its within the client standard delay (generally .ping will give you that) then the client will not notice any lag. Most of the lag you get in linda, is not from LINDA using too much cpu, the cpu LINDA use is most certainly a lot compared to other processes in ss13, but as far as live is concerned, represent only a small fraction of its capability. The problem is, you use it all in one block every 2 seconds. 2 seconds is an awfully long time with a lot of idle cpu time in between. Wasted cpu if you will, using that idle cpu is how you can reduce lag without giving up cpu work.

 

This is also why in my PR i did a commit to split said work and asked fox to retest it on his machine (machine that is clearly much much weaker than live, but that matters little since even in his test, linda + my code did not even reach 50% of his cpu)

 

 

On your semi sped up simulation comment, if you call 4 times the speed semi, then we can crank it up. IT could be 30 times if you want, hell it could be close to zas speed. It was merely a choice to keep it moderatly slow as to not change it too much. There was no code adding to linda beyond the 2 lines. Not sure where your "lot of code to LINDA" come from. Altho in the last commit i did add a bit of code to the air process file, but i believe that one is custom to paradise either way.

 

[Shadeykins]

 

Wh.. How do you even slightly draw this conclusion? Chimera got through a non-mentioned change because we were so stupid as to go "okay fine you don't get how to use the simple mapmerge tools, we don't need mapmerge, it's the asteroid anyways", which is definitely not happening again. What he did isn't even slightly acceptable, and I'm surprised we didn't ask for github support to ban him from the repo.

 

I'll provide the removal of the syndicate station (The one reachable via teleporter) as another example then, it was removed for "not working" when the only issue with it was it was wired incorrectly so the APC drained and it became unreachable.

 

Hardsuit syringe immunity/puncture removal is another example that wasn't discussed.

 

Vulpkanin implementation (And I do play one) was another thing that wasn't discussed.

 

Surgery rewrites to eye surgery (which makes eye surgery far more complicated than it should be and makes medical's job even more time consuming) was never discussed.

 

My issue is that a lot of seemingly 'minor' things that have a direct impact on server balance and gameplay (Syringe Immunity is actually pretty big) get pushed through the GitHub, and I've been told "lol why didn't you comment on the PR" quite a few times - most people don't even look at the GitHub which presents the situation where something may seem to have support along a core base of GitHub users but not the serverbase at large.

 

That's my main issue, and it's thankfully somewhat mitigated by the implementation of an easily accessible changelog which is definitely a step in the right direction.

 

Wat

No really, explain this to me. Do you think that the server performance doesn't matter for a game that is almost completely handled serverside, clientside code doesn't even exist for anything but UIs? Because it really does. If the server is lagging badly, chat messages are no longer sent, map data to render is no longer sent, client input can get dropped, user interfaces might 'work' but won't actually allow you to call back to the server.

 

CPU load doesn't impact latency.

 

CPU load only impacts latency when it peaks at upper thresholds.

 

If CPU load always affected latency your computer would start to stall and lag out every time you made a keystroke.

 

By spreading out the work over the course of several cycles (which is an efficient way of doing it) you reduce total load at any one time. You have mildly higher 'rest' usage but you're far less likely to peak above the 90% mark (which is where you start seeing slowdowns).

 

A CPU is at 50% load, let's say LINDA is 15% of that.

 

.5 seconds, 35% load.

1 second, 35% load.

1.5 seconds, 35% load.

2 seconds, 50% load.

 

As opposed to...

 

.5 seconds 38.75% load.

1 second, 38.75% load.

1.5 seconds, 38.75% load.

2 seconds 38.75% load.

 

This should have absolutely no impact whatsoever on perceived latency, but does let LINDA do more, faster, with less chance of stalling out.

 

This PR was closed because not a single one of the coders approved of the performance impact, adding a lot of code to LINDA, and changing how atmospherics worked for the sake of a semi-sped-up simulation.

 

Isn't a sped-up simulation where rooms actually properly depressurize/refill what we want, anyways?

 

If Jey is able to pull Live Profiler numbers that support no gains in latency, no net costs, and makes LINDA able to work faster I really don't understand why anyone would be against implementation.

 

[tigercat2000]

 

I'll provide the removal of the syndicate station (The one reachable via teleporter) as another example then, it was removed for "not working" when the only issue with it was it was wired incorrectly so the APC drained and it became unreachable.

 

it was removed because it took up an entire z-level despite having only been used maybe 10 times ever, and it was discussed thoroughly on github

 

Hardsuit syringe immunity/puncture removal is another example that wasn't discussed.

 

You mean the broken-ass hardsuit damage system? Because that was outright fucking hellish.

Syringe immunity was semi-discussed, but I'll give you that one, not many people talked.

 

Vulpkanin implementation (And I do play one) was another thing that wasn't discussed.

 

What do you call the 51 comments on the PR, then? Or the multiple forum threads discussing it? It was discussed to the point where most of it's features were removed, actually.

 

Surgery rewrites to eye surgery (which makes eye surgery far more complicated than it should be and makes medical's job even more time consuming) was never discussed.

 

It was removed for the organ overhaul, and yeah, it didn't get discussion- mainly because it wasn't optional to keep or get rid of.

 

[Shadeykins]

 

Vulp was discussed primarily after the fact (much like the new introduction of languages, and language over radio) if I recall. I'm looking pretty much solely at forum discussion, for frame of reference - they still lack lore which we're trying to work out.

 

On that topic (assuming you're aware) could you please post the mechanical benefits/disadvantages of Vulpkanin over on the Vulp lore rewrite thread in wiki discussion?

 

[Jey123456]

 

Could we please stay on the subject of suggestions on how to accelerate the atmospheric spread ?

 

If a good idea is provided to achieve faster atmospheric with even less cpu usage than my code, ill gladly even write it. I am not afraid of writing atmospherics code.

 

If the maintainers would be so kind as to give a reasonable sets of rules they are expecting for atmospherics changes ill gladly welcome them as well (altho they must be within logic, you cant have no change to linda and lower cpu usage)

 

[Spacemanspark]

 

Fair enough, although inevitably whenever somebody brings up atmos, a shitstorm always begins because a few players can't put down their nostalgia goggles for a moment and still believe that ZAS was leagues better than LINDA.

I'd like to point out that not all of us just play on Paradise 100%.

I happen to occasionally play on Polaris/ Bay/ Aurora/ etc., which has ZAS. I still know how ZAS feels.

I still think ZAS is better than LINDA.

As for changing LINDA's speed... heh.

I have some interesting [spoiler2]salt covered[/spoiler2] memories of being utterly destroyed by /tg/ space wind after they sped up their stuff. Honestly, almost worse than what people are saying ZAS did in terms of tossing you around.

Why?

ZAS might have done it a few dozen times, sure. It also broke bones, and death could be relatively fast.

LINDA, at an advanced speed, with faster space wind? You won't be able to get out of it without dying VERY SLOWLY/ waiting ten minutes/ having someone help you. It's less difficult than it is frustrating. It's even more antagonizing because it's not exactly throwing you around at the speed of light in a hilarious manner, it's just sucking you in a slower, but still impossible to escape from manner, and it's just feels like a giant 'fuck you' to the face.

[/salt][/rant]

[spoiler2]Essentially, I'm saying that if space wind doesn't start beating me with a giant stick and laughing at me, I'm fine with such a change.[/spoiler2]

 

[Jey123456]

 

I'm not looking for deadly wind, im pretty content with mild wind that would kill an ssd / someone not paying attention but that are not aggressive enough to pull someone whose trying to get away (unless they are in between a 500kpa room and a breach offcourse).

 

My only real gripe with LINDA as we have it now, is that it takes forever for atmospherics to spread out/equalize. Which make air alarm rather unreliable, siphon / draught also unreliable (since by the time the value reach the air alarm, for all you know half the room could be near vacuum).

 

This is why i went with a current approach in my PR, instead of approaching atmospherics on a tile by tile basis (which is very accurate but slow), i added on top a code that kicked in whenever a large amount of air was transferred, and handled transferring that air over multiple turfs (a currents in the context of my code). This allowed LINDA to handle the finishing touch, but made sure any large change to a room atmo would be spread faster. This is the solution i believe offer the best atmospheric spread speed / cpu usage and works best with our current LINDA settings.

 

Now that solution was closed / refused by the coders so im all hear as to an alternate solution that could be used all the while keeping the maintainers / coders happy.