Shadeykins

It was that or potential book burning type behaviour (maybe a war or something), it was more or less a cover to not go too in depth with ANCIENT HISTORY. I can probably edit that bit as well to figure something else out.

Fixed.

I had the funniest moment where I thought you were the OP for some reason, and that you were just confirming your desire to brutalize monkeys. Anyways. We already have E-N, and I think he fits his role just fine (Sparky, and annoying!).

H'oh boy... Blown up 64x64 sprites. As a fair warning, all the sprites in-game and in the masterfile are pretty much solidly 32x32 which means if you're going to take on the task of uploading the missing sprites (which you are free to do), you're going to have to upload new versions of the existing ones if you want it to look good/cohesive.

To be fair, Plot... The opinions of the NT Rep should ALWAYS align with those of CC. He's the corporate pawn, guy!

http://nanotrasen.se/wiki/index.php/Shadeyboo Flattest wrote up the bulk of this, and I fluffed up a bunch of details and proofread it. Please give input, especially if you're an admunz. After eight months in development, we hope it was worth the weight. This is a WIP still, but it's reaching polished state and we need teh suggestions on existing content. (but really, let me know if Flattypatty and I can put this live to the Vulp page)

Seems pretty straightforward to me, I believe the prefix handle is :7 though, not :8. I also forget the name of the language (despite having a Vulp character). I'd also change the introductory formatting (I'd feel dirty changing someone else's page) * Vulpkanin is a free race, requiring no unlock. * Vulpkanin have a unique language that only they can speak and understand, called Caniluzut. It can be used over radio. Use this in game by typing say ":7 * Vulpkanin have claws, and unarmed damage applied by them counts as sharp. * Vulpkanin have good cold resistance, but very little heat resistance. * Vulpkanin are able to wear gloves normally despite their clawed hands, unlike [[Tajaran]] and [[unathi]].

I'm still far more in favour of a more compact design, preferably with the two eastern sets depicted in this picture as something else (another variety of equipment, or perhaps even the tables could go there). You could then have the wall chargers in the position where the tables presently are, and put the pepper spray dispenser above the SecVend

And that's the actual, honest to god issue with it. They're not antags.

Actually that'd be a great idea, and would allow for crafty antags to deliberately sabotage the engine without running the risk of a ban.

I believe this was a deliberate change, the NT Rep used to have a different stamp.

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?

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

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

I'd say the room should be organized a bit differently. Pull the lower wall up one and use those sweet armory lockers along the top wall and have reinforced tables with flashes and flashbangs along the lower, with the refill dispensers there instead. Otherwise, yes!

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.

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.

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.

Looks good! I went through and proofread the entries, fixed some spelling/grammatical errors and touched up on some formatting inconsistencies. I got about as far as "Sec Hardsuit Helm" before taking a break. If you don't mind, I'll probably group them into equipment subtypes later. (Weapons, Armour, ETC). I'll also go through the masterfile later and upload crisp 32x32 versions of all the security icons later, as well (Some of them are pretty blurry). Of course if you wanted to do these things feel free to let me know, and I'll leave it to you.

Done.

I'm apparently supposed to bring my "frownface" brigade here. No. Just add a morgue tray into the execution chamber, it's less coding and has the exact same effect. A DNC implant is easily abusable, a morgue tray in the execution chamber is not.

A total rework of objectives would be nice. As it is 50% of them don't even register if they're done (they're broken to hell right now), and some of them are literally impossible. "Steal the AI." or "Steal the brain of X" and then "Die a glorious death." are impossible objectives to complete when they're put together.

Having fascism somewhere in the lore/background doesn't mean acting like a fascist in-game. Nobody (but CC, fucking adminbus loophole) is above Space Law. That's for a good reason - to prevent the slippery slope of internet shitlery. Yes, and the idea here is that CC, Central Command, IE: NanoTrasen probably has a vested interest in that technology and would pressure the subordinates onboard the station to get it.

That's not in Space Law. We can't do that, for rules are the limiting factor in our roleplay. There would probably be pressure from NT itself to accept the deal. I mean, come on. It's NanoTrasen.

This. Blueshield has bridge, basic brig, basic engineering, basic medical, basic science and that's about it. Their default access is actually pretty laughable.