Jey123456

well, if they have an hardsuit it remove the main interest i had in the suggestion. I dont really care that miner get hurt since they generally can be saved by other miners anyway. What i liked about it was that miners would finally have to actually be careful with mining outpost. Nothing i hate more than seeing that place with the eva sas overriden wide open, holes to space etc and not a soul mentioning it to engineering to get fixed since they dont give a fuck about it, they have suits.

Instead of a hardsuit, how about giving them a weaker version of an odysseus or something similar to act as an eva recovery vehicule, having the ability to grab the miner in an internal air area with no other capacity than transport and maybe a small amount of drug to keep the patient alive in critical. Main reason i like this idea is because its an extra encouragement for miners to be carefull with the mining station (and encouragement for them to report damage and get them fixed) since theres an unsuited staff on board. It becomes moot if the mining doc is also running around in a suit all day.

Its not really possible since they are 2 opposing concepts (ZAS is a room based atmospheric, LINDA is tile based), the closest to a hybrid solution i can think off, is exactly what i wrote and did a pull request about (LINDA for the short distance tile by tile atmospheric, air currents for the multitiles long distance atmospherics). If you can think of an algorithm that can efficiently generate rooms dynamically (one of the biggest problem on ZAS was updating rooms) then please elaborate, you do not need to know coding to propose suggestions on this thread. Just understand basic cycle and logic. I can handle the coding if the idea is good. Just keep in mind that the reason why the air currents was not over the whole room was performance. Determining the constraint of a room require a lot of cycle every update, this is why i went with a compromise of determining the optimal air path in the room instead. As far as coding knowledge / experience goes. Offcourse there's no class in byond that i know off, but ive been programming extensively in C++ for a little over 21 years now and am a university graduate in video game conception / programming. C++ is my main language obviously, but i am able to use a little over 10 programming languages without any problems (and i have yet to meet a language i could not learn in a matter of hour). Now for byond its a little different, its not the language im lacking in, its the standards expected by the paradise station maintainers. For that I'm counting on them to enlighten me since the requirements they generally complain about are not written down anywhere that i know off. I don't have much free time i can dedicate to coding for paradise, but i enjoy the simplicity of byond language as a distraction so i do not mind spending a few hours every now and then on it so long as its on something that i find interesting (atmospherics for instance). I do mind spending time only to be shutdown by the maintainers which is part of why this topic is here. It's partly to ask the playerbase what they want, but mostly to ask the maintainers what it is they expect of an atmospheric system. I know that in the PR tiger said LINDA is working exactly how he wants it to be, but well, unless me and tiger have majorly different expectation of the atmospheric system (any slower/less dangerous than what we have would be no atmospheric system) i refuse to believe it really is what the maintainers believe.

theres already a small medical room with a sleeper on mining. Maybe add a locker with some medkits i suppose. I love the idea, if only for the fact that it mean miners will have to be careful about the mining station since the medic would not have a hardsuit on all the time i presume. Having a medic with mining access would be pretty usefull for miners that get hurt tho.

considering station is fine with 300k, and tesla can give about 17m, that would have to be one hell of an efficiency drop

their power need nerfed. I mean 10mw + is completly useless (and make any other powersource useless unless the main one become free, and usually if its free the round is over either way). As far as im concerned, the main engines should not be round ender if not maintained but should ensure their own system destruction (blow a good chunk of engineering for instance). Give engineer a chance / opportunity to recover the round. wire the panels, power the turbine and run on aux power. Both tesla and singularity should slowly damage something that if not repaired / maintained should cause it to go haywire and deal limited destruction. As for the precise what, i dont know nor do i have any idea . Anyway, thats what i think, personally i find main engines ugly, but thats because i play atmo tech and i hate how weak the gas turbine is without bribing science and being lucky (and by the time you get the parts to reach 400kw power on the gas turbine, the round is over)

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.

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)

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.

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.

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.

on many occasions, theres neither hop or temporary captain when those low pop shifts occur.

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)

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.

i do believe the armor / shield should be easier to obtain for security indeed. Putting it behind a warden/hos wall instead of only hos would go a long way toward that. The shotguns i think are too much, tasers and maybe some kind of flashbang / pepperspray grenades (anything non lethal) would be more than enough to deal with a civilian riot.

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)

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.

My solution to this was shutdown partially because it was not needed according to tiger . 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.

making them unbolteable and draggable (similar to pipe dispensers) shouldn't be complicated at all. The part that sometime get complicated with those fixed machinery, is if they have connections to other machinery needed and the likes.

i miss depressurization too, thats why im working on that in my free time i find it pretty silly that a 4 tile long corridor open to space on one end barely take any air from the other end

a mix of room + tile by tile would be unbelievably heavy on the cpu. One of the few reasons why zas was so heavy, was the whole room concept, since room are not static, you basically have to constantly recheck the room definition whenever something happen (wall is built / destroyed, door open / close etc) I am currently working on an addon for LINDA that should greatly improve its room equalization speed at minimal cpu speed while improving the realism in the process. Depending on how it goes, i might have something to show for it soon. Altho this has very little to do with this suggestion since even under zas id have loved a faster refresh on the pda atmo scan heh.

it already does if you just do the math so im not sure what would be the point, not to mention i cant think of any case where it would be of any uses except maybe high pressure scenario but then your a bit fucked since it imply screwing with the high pressure room to go inside grab the readout and screw it again to leave.

It definitely did a good job of blowing out the wall it was placed on. Maybe needs to damage walls a little more, though. it was not the explosion that blew that wall. Thats a c4, they are special item that first destroy whatever they are on and then create a very weak (4 light damage range) explosion. c4 are the closest we have to what could be called a shaped charge. Since just about every bombs in ss13 are pressure bombs, and pressure bombs just dont normally have the power to damage metal much (youd need a fucking ton of pressure), let alone what we call plasteel (reinforced walls), there is a reason why their containers are generally metal, and ripping the container is where the energy of the bomb was at its highest, once the container breach it generally mean that it just barely reached a point where it could break metal, past that point the pressure only go down very fast. I can understand to a point why realism would not be usefull here, thats part of why i did also apply the fix to the existing explosion in that pull request.

lol, yea, but i mean, it doesnt do anything more than the name . not sure what else i could name it . Its really only to give atmo cartridge something special, since right now, you could use a science one just the same (all you get is the gas scanner)

this is simply a post to see what the players who dont check git think about this suggested feature. The code is already done (its a 10sec thing to code really ) https://github.com/ParadiseSS13/Paradise/pull/3194 The result is very simple as well. pda equiped with an atmospheric access cartridge have the refresh rate of their atmospheric scans changed from 10 seconds to 1 second. this allows atmo tech to read the state of a room atmospheric much faster and without having to either wait 10 seconds after coming in the room or spamming the pda action in their hand.