Jey123456

thats exactly the main problem with atmo tech. They have no job on paradise, so most of the time, atmo tech will either be ssd early in the round or busy in some useless / self imposed project and as such not interested in doing whatever you need their cooperation with. Atmo itself on paradise is a joke and extremely rarely in need of actual atmo tech to fix. a magical pipe dispenser wont really fix that since pipes are not needed (you could seriously remove 99% of the pipes on the station and still be fine by moving a few air pumps wherever air problem occured. Hell atmo tech would likely be more fun without the pipes / main atmo system since then even a slight atmo problem would actually be a problem that need fixing .

i dont really agree in requiring the head of a department to send the request to another head to get the guest pass, it seem like a step backward. Whole reason why the guest pass arent used right now is because when they do are needed, noone is here to give them since they generally are busy with whatever created the need in the first place. Thats why i suggested moving the system from requiring the head of the area to operate a terminal and instead have a system where whoever need the guest pass can request it and the related head simply have to approve / refuse on their pda. (and i suppose giving an alert to the ai would also go a long way)

By that logic, ghost shouldnt be able to see main atmo either (not that it matter on this server). Some people spent multiple rounds optimizing their change to its piping to achieve top air distro / scrubber performance. I'm sure there are many other example where special method / arrangement can be used to optimize the result. Theres absolutly no reason why some should be hidden and other not.

any job whose sole enjoyment rely on learning secrets / tricks, is a job that should be reworked / improved. Learning is fun sure, but when its the only thing a job has to offer for fun then once you did learn it, its not fun anymore. Sure metagaming happen, but it will happen with or without the machine being viewable by ghost. Once someone is ghost theres very little they cant figure about a round as it is. If that so called metagaming was so much of a problem then maybe we should simply remove the vision / hear of ghost, hell remove dead chat too so they cant use that to metagame with each other !.

i think just improving the guest pass system would achieve that goal (and also help engineering). Right now the way it work is that someone (anyone with access) has to go to a guest pass terminal, fill in the info (reason, time, receiver name etc), then finally hand it over to the person who need it. Its fine when theres no emergency and everyone is sitting at their desk, but sadly when they are needed the people who should give the pass are generally too far / busy to do it. Moving those terminals to outside of the specific areas (cargo, R&D, engineering, security etc), leaving the requesting / filling part to the person who need the ticket. And then simply give a pda alert to every active leads in the department offering to grant or deny the request at the simple press of a button in the chat (similar to how you can reply to a pda message directly in the chat) would likely greatly improve the situation. as a backup solution in the event the leads for the dep are unavailable, anyone with the requested access could manually approve the request directly on the terminal i suppose (essentially close to the current requirement for guest pass). Only difference is that this scenario would be a lot less likely since heads could handle those quickly and easily so long as they have their pda / pda messenging is functional.

There is nothing to nerf, emergency oxy tank already have way less air than the one you put on your back / air tank slot on eva suit. On a big tank you can last hours (longer than any shift really) without ever emptying it. On the yellow emergency tank (the extended), you get around 45minutes maybe an hour. The blue one is like 30mins altho i cant say i timed any of them. I do know that the blue emergency tank will drain pretty darn quickly.

maybe the actual solution instead of a dedicated job for it. Would be a better way for emergency response job to actually reach said emergency. Either by making it faster / easier to get a pass voucher to the section the emergency is in (right now it imply someone with all the access you need give it to you, but that same person could very well just be busy in the emergency). If there was a way to quickly print / give said temporary access pass by the ai or remotely by the person with access (maybe a pda alert when someone request one) then paramedic could do its job a whole lot better and would invalidate the mining doctor suggestion.

We don't need more traitor shit that can be meta'd by anyone with half of a brain. You can fucking triangulate the device if you make it leave messages. which is not such a bad thing considering we wouldnt want the traitor to just have it on non stop / plant it somewhere and leave it here enabled forever. As long as its faster than removing the headset of your target, and on top of that silence pai radio then by the time you see that little message telling you your fucked, your already fucked .

hence the vote instead of instant round over. Id be fine with the round ending immediatly (no shuttle) if the vote pass to end the round. Say nuke ops is dead, wait 5mins, start an automated vote. 5mins is enough for the players to determine if its recoverable or not. If they vote to continue the round then its just extended. If they dont the round is over.

I couldnt get it out of my head so i wrote a quick proof of concept from my theory on page 4. This is nothing but a proof of concept but feel free to comment on it / test it out. https://github.com/Jey123456/Paradise/c ... fc4ecdb6f1

ah well, it probably should be over after the nuke explode . But not when nuke ops fail.

nuke ops as well at the very least. When they win the round is over either way, and sometime they lose without doing much if any damage at all.

I fully agree with that. Not giving a chance to atmo / engineer to actually repair whatever damage is merely insulting those "support" jobs. Offcourse there are times where the damage is just too much, but most of the time your able to fix / work around unrepaireable area in a matter of 5-10minutes if the engineering staff work together.

i7 generally have a few more of the advanced instruction sets / cache optimisations available than their i5 variants. Which count for a lot when your bottleneck is not cpu but memory bandwidth / latency related

Having part of it simulated (like prisoneer camp for instance) would not really be a problem. If i understand the other limitations properly, that would mean the mobs on the asteroid are not marked to live in space ? It would be possible to add an in between tier (unsimulated ground or something like that), that allow for those specific mob that dont need air or heat to survive to live on it. Its pretty normal for dogs and chicken to die on the asteroid so im assuming your refering to the specific mining related mobs. For those who want to build small bases on the roid, that still work even on unsim turf, you just need to make a floor. The Blood, vomit, overlays, some effects could also be added to that new tier of unsimulated. The whole point of unsimulated is to not have to simulate the thousands of turf that become active whenever an atmospheric related incident occur on one of the station on the asteroid. Another alternative that would require a lot less changes and still greatly reduce risk of the asteroid becoming contaminated with air (cpu load) would be to only surround the constructions on the asteroid with a line of unsimulated version of their turf. Essentially acting as siphon if a breach / atmo problem do occur it stop right here instead of spreading all over the place over the course of hours. I mean all that complaining about LINDA being so heavy, and yet we have the asteroid which represent a huge chunk of that load for no particular reasons .

I have no intentions of contacting TG since its not a change to LINDA but an addon. Its not TG i wanted to improve the atmo off its Paradise. Parity was maintained and the cpu could have been reduced (as per my proposition on page 4) sadly its obviously not wanted so meh. Enjoy your slow atmo .

please show me where those large changes to LINDA are, i can link you the diff clearly showing only 2 line change in linda. https://github.com/ParadiseSS13/Paradis ... 3214/files see the LINDA folder changes, 1 line insertion in LINDA_system.dm 1 line insertion in LINDA_turf_tile.dm Those 2 lines are the only changes to LINDA in that commit, beyond that, its in Processes/air.dm . Now if you want to call it part of linda, then fair enough, but there is no functional change to the air process either, merely splitting calls. Its not like the data is not out here. 99% of my changes are internal to the aircurrents.dm file exactly to avoid maintainers complaining about lots of LINDA modifications. This code does not modify LINDA in anyway, it modify the air process and add aircurrents. The one and only real argument you have that i have no problem acknowledging. Is that it use more cpu, yes it does, 180% the cpu for 400% the speed, I still wont agree that it correlate with more lag but this is obviously too high for you, hence why i brought up an alternate way to achieve my goal with 80% or less cpu usage compared to the current LINDA and still atmospheric spread acceleration.

And apparently we, as maintainers and coders can't be clear enough to you in a nice way, so I'm going to word this very bluntly: We don't want your PR if it's anything remotely like the last one. We told you the criterion something will have to meet to alter LINDA, and from what you've already described, your hypothetical PR would not meet that criterion. Again, if you're hellbent on making changes to LINDA, I highly recommend you get it past LINDA's original coder and creator, over at TG, first (and even then, there's no guarantee will backport it). What part of no changes to LINDA are you misreading ? as far as i know, the air_process call is not part of LINDA but paradise's (obviously LINDA has its own version since it kinda need a process manager) and its the only actual file that would get more than the 2 hook insertions in that PR. My suggested PR is indeed similar to my old one in the sense that it reuse the same principle with very different settings inside to result in a lower cpu usage all across the board (at the cost of slower low pressure difference equalisation) To match your complain about CPU usage. I'm pretty confident i can both increase the rate at which most of the air equalize and drop the actual cpu usage of the whole atmospheric system down to 80% of what linda currently use (maybe even less). No modifications to LINDA are required for that, merely a slowdown in the airprocess so that my air currents code can handle the heavy lifting and leave the fine tuning to LINDA

In the atmospheric topic, i remembered of a stupidity i saw on baystation years ago, i somehow expected they would had rectified that long ago but i guess not since our turf are still simulated down here. Any particular reason why we are keeping them as such ? I mean from a cpu load point of view, it makes no sense for most of the asteroid to end up in the LINDA workflow everytime an airlock / window / wall is forced open inside one of the stations on it (especially that with LINDA speed, that workflow will basically never end due to the sheer distance until it reach an unsimulated to empty in. For those that dont understand what im saying. Basically we have 2 types of turf (floor), simulated and unsimulated. Simulated are the floors used in stations shuttles etc. They have the code in place to handle atmospheric simulations. Unsimulated are kindoff a cheat floor used to save on performance by not simulating atmospherics on them and simply assuming they are vacuum. The atmospheric code handle them as such (the space with the stars you see outside the station for instance, is unsimulated turf). I cannot think of any reasons why we need the asteroid dirt / ground (not the bases on the roid, but the actual rock) to be simulated. I suppose someone could wall off a corner and make it breathable, but is it really worth adding such a strain on the atmospheric code when its already among the top 3 cpu usage on the server ?

I am indeed not willing to accept as true that you tested the last commit before you closed the PR under a lag scenario on both current version and the PR (cpu time is only meaningfull if its either too long per execution block, or the total represent 100% of the realtime). I'm willing to bet that if given an half decent computer (a third of live core speed is enough) my PR would actually lag less under heavy atmospheric work than the current version. I have yet to see live atmospheric code go above 12% cpu and any lag that come from it is not from too much cpu usage, but too much at once. Anyway i disgress The discussion is not about my old PR but my next one. I made this topic in the first place to gather idea on various approach (didnt pan out much on that side) and a general feel of what people wanted / if it was wanted. Read the concept at the bottom of page 4, this is the one i want us to discuss before i actually go and take hours off my free time for it.

The test you did was invalid as far as cpu usage comparison goes , since in one test your cpu was not overloaded and the other was (which meant a lot of extra cycles wasted trying to catch up/ thread context switch in the os etc). If you want to do a proper comparison test, do it on a machine that can actually support it (not saying it shouldnt run on your machine, the latest version should be just fine for said test since i fixed the long duration execution block issue). If you use identical test scenario youll see that its not more than twice the cpu, its around 180%. The lag from the cpu increase was already contested more than once for the very simple reason that even under extremely heavy atmospheric load on live, cpu is not used anywhere near full capacity. The version of the PR just before it was closed already included a fix that is very likely to reduce the lag not increase it (increase cpu yes, but spread over multiple execution blocks. But anyway this topic is not about the PR itself, its about what is wanted for an atmospheric related PR to be considered more than just run once on some machine that could not be further away from live spec. Increasing the rate of LINDA to 0.5 sec would be stupid, it would not fix the problem, it would still be exponentially slow according to the distance instead of volume. The only part where the 4x speed would really matter from switching that, is short distance (< 10 tiles). Wind speed (amount of air that pass by a tile) does not depend on how far it is to the low pressure point, it depend on how much volume there is in between (ok its more complicated than that once you go into fluid dynamics but for the sake of keeping it simple lets not) Not to mention why would switching linda to 4x be even mentioned (400% cpu) when 180% cpu for 4x spread speed (and nearly linear speed over distance and instead affected by room dimensions) was shut down for lag reason ? As for what i had in mind for my next PR (the one im still waiting for some kind of approval on the concept before i actually take the time off my free time to do it, see page 4 last post). There is no changes directly to linda except the same exact 2 lines to hook in from the PR that was closed. The only changes to the current atmospherics would happen in the air_process to slow it down even further A quick tldr in case you dont feel like reading it, the result would be lower cpu cost across the board, slower low pressure difference equalization and faster high pressure difference equalization. The slower low pressure difference equalization (say 106 to 102kpa in a room) is the price that would be paid for the lower cpu and radical increase in high pressure difference (say 100kpa to 50kpa in a room)

its a start at least. Hopefully maintainers will add to it.

so after giving it some more thought, i had an idea on how to tweak my PR that should satisfy the cpu worries (altho i still firmly believe they are unfounded, but well, its not like the maintainers seem to particularly want a faster atmospherics so i guess ill put all the chances on my side ) I'm thinking about removing the wind effect from LINDA all together and slow it down to 10 second per cycle split in 20 0.5s cycle (essentially drop the cpu usage from linda by a factor of 5 and split it over a lot of small increments to camouflage the very long interval and reduce risk of lag spikes from them). This obviously would mean that LINDA would not be fast enough to handle anything but very short range / low pressure equalization but thats all i need it to do for my plan to work out. To that, i would add a special independent call in the airmaster to do a turf as soon as possible (next 0.5 interval) that would be added to doors state change and wall destruction (everything that would create an instant air state change, creating a wall change the air paths but does not actually create any new path so theres no need to instant refresh here) With LINDA cpu usage essentially out of the way, i could tweak the air currents system to run at a much faster rate (hell, even every 0.5 sec would be possible), since the air currents system by itself is much lighter than LINDA due to it not operating with the same kind of precision, it means that we can use it to greatly accelerate the large air equalisation (anything above the treshold) pretty quickly, and then let LINDA do the finishing touch slowly for the last few spots that have a small pressure / temperature difference. I did not try it out yet, its only something i thought off while taking my walk, but im confident that i could end up with a system that is faster than LINDA for high pressure differencial equalisation over a room, faster on atmospheric spread, more realistic winds (no wind pushing you back and forth on the same 2 tiles). At the cost of less cpu usage than LINDA currently use in similar scenario and slower low pressure difference equalization. What it would mean is that the cost of reducing the cpu for LINDA while accelerating the important / large spreads would be that rooms with 106kpa on one side and 102 kpa on the other would equalise about 5 times slower than right now, but room with 100kpa on one side and 50kpa on the other would equalize much faster than now. I believe it would be a good compromise since small pressure / temperature difference do not matter nearly as much as big ones, but before i go out of my way and spend another few hours on that, id like some kind of confirmations that it would at least be properly considered once i do the pull request for it. If possible id also like some thought from the maintainer as to what to keep an eye out as far as the mythical standards goes. I know tiger mentioned having the define in air_define but im sure theres a lot of other things out there that aren't really mentioned anywhere and yet expected of PR

It's Jey, and , to answer your question, it would not. First thing first, it would require much larger changes to LINDA (which are a big no-no from what i could gather from the maintainers). But on top of this, would not really change the actual calculations since the heaviest part of the calculations is to determine which tiles to work on (changing it to 2x2 or 3x3 would reduce the share_air part of the deal, but would increase exponentially on the air group generations and canatmopass tests along others). Plus it would not really address the largest problem on linda, which is an exponential slowdown of air movement by distance (instead of by volume). A small 10x1 corridor with a breach at one end would only see 0.09kpa drain from the other end and would very slowly increase as the first tiles finally empty out. Changing it to a 2x2 or 3x3 square would indeed divide the issue, but the actual problem would remain just on 2-3 larger dist. Now offcourse if someone can think of a way to handle those 3x3groups with no changes to LINDA and less than 3times the cpu cost, it would be a step in the right direction.

it most definitly wont fix my gripe for sure, but it would be a step toward fixing it. I mean right now, for all intent and purpose, mining outpost could be completely open to space it would not really change much and thats my gripe. Mining outpost exist as a sealed construction protected from the harsh environment from the asteroid, but since miners walk around with their own little protection they have no respect for the outpost. At least if someone else need the place to be liveable theyll complain at the miners and slowly induce a minimum of respects to their remote workplace. I dont really care either way, from my point of view, mining doctor is not needed in anyway, this is simply the one reason i could find why they would be beneficial to have. As far as saving miner goes, any miner can just toss the miner into the sleeper on mining outpost, throw in 29cc of omnizyne and if its not enough, drag his now stable ass to med bay.