[The scripting paradox: NTSL edition.]

 

Reasoning for closing the PR was:

 

• NTSL is already an incredibly powerful tool for those who know how to actually code in it. You can mute out words from telecomms that contain a specific word or few words, mute specific people, change people's messages, etc etc. We don't want any more buffs to telecomms, even fairly minor ones because it doesn't need any. I doubt this one feature is going this one feature would make it horrendously OP, although it would add more flexibility to telecomms, which is already incredibly flexible. If you're going to cry and complain that a minor buff like that isn't reason enough to take something like that down, remember another department that endlessly got minor buffs/additions to the point where it's now a horrendous monstrosity of bad balance? (Hint, it starts with an "R", and ends with an "esearch and Development")

• This was discussed between Neca, Fox and myself. We were all generally in agreement that telecomms didn't need the buff for the reasoning discussed above. The codebase isn't a democracy, generally decisions about minor PRs are made between Fox and myself, while on larger ones we will consult with head admins about. For changes that we don't have any particular like or dislike for, we'll usually poll the admins and community to see whether or not people want it.

 

 

[pAIs in secbots.]

 

Going to echo what I said on the Github PR. It's absolutely ridiculous that a role that is for bored ghosts who want to get back into the round is as powerful as secborg/ED pAIs. Either they need to be nerfed down to a reasonable level (AKA not infinite baton/taser/handcuff bots that are easy to repair and have no need to ever recharge), restricted to security access and policed like security officers/secborgs, or they need to be outright removed.

 

EDIT: My vote is to remove them for the time being, it is much easier to disable it and re-enable it when it isn't shit than to rely on somebody having the spare time and drive to make them not shit.

 

[Surrealist Compliments]

 

"Softly seething, surreal breathing..

Ignite the cannon with sphagnum lanthum..

Laud the armies of diphthongs with your superannuating Diphtheria..

And I will ever be your combustive tablature of igneous geometries."

 

I'm not sure what I should think.

 

EDIT: Help me.

"Les caresses de tes yeux fertiles sont plus douces que toutes les gifles de tes mains rouilies."

Roughly translated, "The caresses of your fertile eyes are sweeter than all of the slaps of your rusty* hands."

*The word "rouilies" doesn't seem to match any modern spelling of a word exactly, it may be an archaic spelling which I cannot match up to a modern equivalent. Another possible meaning is "retted."

 

[Machosketch]

That is wonderful.

[IRC has been moved]

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.

[Armor Piercing and EMP Ammo]

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

[Additional Slime Aesthetic Choices]

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.

[cult rune colors!]

 

Sprites would need to be converted to greyscale for this to work.

 

This is still the main issue with this idea.

 

[Additional Slime Aesthetic Choices]

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.

[Accelerate the atmospheric spread]

 

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

 

[Accelerate the atmospheric spread]

 

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.

 

[Tesla Engine]

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

[The Wizard Lightning Bolt Spell]

 

Err, what? This isn't at all how the lightning bolt spell is supposed to work, so either it is completely broken at the moment (it worked fine last time I tested it a month or two ago).

 

First of all, it will ALWAYS bounce 5 times, meaning that if there are at least 2 people in range and they don't move out of range, it will hit 6 targets, and can hit the same target multiple times, this multi-hitting is important and we'll come back to it. Secondly, it doesn't require you to stand still, but takes about 10 seconds to reach full charge, and if you release it exactly 50 damage per bounce, note that each bounce will also stun. The fact that it hits multiple targets, bounces, and does damage makes it great for dealing with smaller crowds, where something a bit more deadly than magic missile is necessary. Now, back to the multi-hitting, in an ideal situation, you fire your lightning bolt at a group of two people who are in bounce range of each other, with nobody else in range. In the ideal situation, where each bounce does 50 damage, both people will take 150 damage (that puts them in hard crit) and get stunned (items dropped and cannot move) for 2 seconds, and are then downed (think stun baton stuns) for an additional 2 seconds after the last bolt hits them (they're completely stunned in between bounces). If you panic fire lightning bolt early, it does a minimum of 15 damage per bounce, and will still stun. The spell itself can be somewhat mitigated by torso armor with a lower Siemens coefficient though, although you're still going to get stunned and damaged, as there aren't easily accessible sources of torso armor with a Siemens coefficient of 0.

 

That said, the long chargeup time does hamper it a bit, but you could just as well release it early for an emergency stun. Fireball and a few other wizard spells are pretty lackluster though, considering they're either fairly weak, or have a decent chance to kill the wizard as well as the intended target (fireballs are more often than not the main contributor to the deaths of wizards who take it as a spell).

 

[Screenshot thread!]

 

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

 

 

 

[Screenshot thread!]

 

 

[Added a swarmer page.]

And Spacemanspark was never seen again.

[CLEANSE, PURGE, KILL.]

THIS IS AN AUTOMATED ANNOUNCEMENT. YOUR MAIL ORDER "MEMBER OF THE HOLY ORDERS OF THE EMPEROR'S INQUISITION" HAS BEEN SHIPPED AND WILL ARRIVE IN 2-5 BUSINESS DAYS. HAVE A NON-HERETICAL DAY.

[Rate the avatar/signature of the person above you.]

Definitely a trustworthy-looking face (monitor?). The cat and instructional poster definitely don't make me think that he is a psychopath. 10/10 would trust again.

[PhantasmicDream Art]

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

[PhantasmicDream Art]

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.

[Shadowling Evolution Overriding species]

 

Can't changing the species to shadow people fix it? I think I saw that on some admin panel on local, and while I didn't look at the code at all, it should fix it, right?

 

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.

 

[Shadowling Evolution Overriding species]

 

 

GODDAMNED SNOWFLAKE SPECIEEEEEEEEEEEEEEES!

 

 

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

 

[Do you play a musical instrument?]

I used to play the piano, haven't actually done so in years so I'm probably horrible at it now.

[New Xenoarchaeology?]

I apologize for xenoarch being extremely delayed, but recently I haven't had a large amount of free time to dedicate to coding a system from scratch due to issues coming up in real life. That said, I'll likely go on a xenoarch coding binge as soon as I get a week or so off classes (holiday break at the very latest). That said, /tg/station does not have a xenoarch system to my knowledge, and /vg/station uses the same xenoarch system we used to have, AKA code monster Caelcode xenoarch.

[Changelog Discussion]

Quick correction to the Shadowling change. They already had thermal + night vision, they are just able to toggle it now, and have access to it both before and after hatching instead of solely after. Shadowling thralls now also have toggle-able night (not thermal) vision.