DZD

That is wonderful.

I'm having issues connecting with synirc.net as well, the IRC link in Regens' post crashes my Hexchat client entirely, and whenever I try connecting to it manually it fails to connect.

It's impossible to say, do burn and brute damage in one bullet directly, but it's possible to make bullets do special things upon hitting a mob, such as creating an EMP or giving the mob firestacks (this is how ion bolts and dragon's breath rounds work). As far as armor piercing ammo, it already exists; you can print out AP ammo for SMGs and the sec rifle that you can order through cargo (its name escapes me at the moment).

For its current purpose, mob overlay code isn't absolutely horrible. If you wanted to have people be able to morph to look like different species, you'd have to restructure how species external organ overlays are handled, as at the current moment humanoid mobs get their set based on their species. You would also need a new slime overlay for the different species body parts (such giant Grey heads, tails, etc.), and would thus need sprites for those. This is largely due to the fact that mob overlays are broken up into arms, legs, a head, and a torso so that de-limbing can work. Slime people actually hijack this a bit because they're basically humans with a slime overlay layered on top.

This is still the main issue with this idea.

Not exactly certain how feasible this would be, given the amount of fuckery that is already involved when working with humanoid overlays. It would in all likelihood require some amount of restructuring of humanoid appearance code. Also, fun fact, slime people are actually all black-eyed baldies with an overlay on top of them.

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).

Oh, what's this? Another atmospherics circlejerk. Greeeeeaaaaaaat. Largely true, although quite a few of them have the same issues with it that you bring up in this post. 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? 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. 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. 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. 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. 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. 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. 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. 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. 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.

Looks like the issues with it hanging the mob process were solved. https://github.com/ParadiseSS13/Paradise/pull/2999

Well, it looks like demons have taken over my PC (gifs below).

And Spacemanspark was never seen again.

That has to be the best way to use the traitor money briefcase.

Played some of that game with a friend, it is great fun. It gets to be extremely chaotic (and thus, extremely !!FUN!!) if you have multiple people with the manual, and they're all frantically trying to yell bomb disarming instructions at the person who has the bomb.

They already get their species changed to the shadowling species, which is a subtype of shadow people; however the species change happens as hatching finishes. The strange thing is, after the species change, they shouldn't at all be catching on fire/suffocating because their species no longer has the properties of their original one.

I'll see about fixing this. Just to make sure, are you having these issues while in the cocoon while hatching, or afterwards?

Poor Kharshai.

NO ERP! In all seriousness, this thread is absolutely hilarious.

False, you forgot to mention how Kagura got hit by the moon a few times, and suffered burns because she had to enter the atmosphere every time she wanted to punch The Earth, until she realized that she could set her fists on fire before trying to punch and thus not be burned.

Seven. I don't know why you guys reset it after I posted, maintainers don't count.

I am sorry, butI had to have the streak broken at lucky number 13. Let me make it up, 4.

You should be able to build a mecha plasmacutter and equip it on a Ripley, and it serves as a fairly decent ranged weapon.

There is no rest for the chef once the server population has gone over 70, especially not when somebody stuffs all of your food into one sandwich and leaves with it.

That drawing is absolutely amazing, especially the looks on their faces.

3 dreams waiting to be crushed by a badmin.