Shadeykins

If I recall correctly, the idea of lasers with magazines got shot down because it's a drastic powerup to lasers. If they're "special weapons" though that aren't readily available and the magazines can't be used on standard e-guns, I personally see no issue with their implementation!

If they're extra slots with the absolute lowest priority possible (meaning if anyone else has an antag preference on without pacifist enabled gets it over you) then I agree with the suggestion as stated before. Otherwise this just strips what could be potentially interesting antagonists to boring pacifists who quietly take their objective and then do nothing the rest of the shift.

These all seem sensible suggestions that add a fair amount of import to station goals. I especially enjoy that failure of these goals is met with a penalty.

Reviving this idea. * Incorporate Auto-Accent into the character setup screen so it becomes a set-it-and-forget-it feature. Existing implementation (for those of you who don't use it) means it has to be toggled on a round-by-round basis.

Here are the Paradise GitHub's standards, because Paradise doesn't actually have explicit code contributing standards/best practices. * Do not push directly to the repository, always make a pull request. (Nothing to do with suggestion). * Your pull requests should be atomic. Balance changes, bug fixes and new features should all be in separate pull requests. (Nothing to do with suggestion). * Your commits should be atomic. Make one commit for each distinct change, so if a part of a PR need to be removed/change, you can simply modify that single commit. (Nothing to do with suggestion). * Please document and explain your pull requests thoroughly. What each commit changes and why. We do not want to have to read all of your commit names to figure out what your pull request is about. (Nothing to do with suggestion). * Make sure to use the mapmerge tools on all map edits to the primary map files. Pull requests that contain edits that don't use the mapmerge tool will be automatically denied, unless explicit permission was given. (Nothing to do with suggestion). * Any pull request that is not solely composed of fixes or non gameplay-affecting refactors must have a changelog. See here for further instructions, and here for an example changelog. Alternatively, inline changelogs are supported through the format descriped here. (Nothing to do with suggestion). * Any type and proc paths MUST use absolute pathing unless the file you are working in primarily utilizes relative pathing. Before you even attempt to erroneously bring this up, here's what's meant by pathing. https://nanotrasen.se/wiki/index.php/Code_Contributing_Standards This is from an abandoned wiki page that was established over a year ago when the idea for having code contributing standards first popped up. The idea never took off, and Paradise has never had "code contributing standards"--the original thread still exists under the wiki development subforum. The only "standards" for the codebase are that your code compiles, you're using the efficient calls as to not cause undue stress on the server, and that a maintainer approves it. I also genuinely fail to see how something that hasn't even been coded can be in violation of non-existent coding standards. and last but not least... * PRs should not have any merge commits except in the case of fixing merge conflicts for an existing PR. Use git rebase or git reset to update your branches, not git pull. (Nothing to do with suggestion). Please tell me where my non-existent code violates the GitHub guidelines, or the non-existent guidelines for the Paradise codebase. Maybe then, once this mystery has been solved, I can appreciate why you seem to randomly hate a suggestion for what seems to be absolutely no reason at all.

Drop the reliability of them, but nerfs beyond that? Not so much. The #1 reason batons get used is on derpy, trespassing greytide (to remove them from a department) and people who won't bloody well peacefully accept a demotion. Security 9/10 times will ignore you calling for them if it involves a demotion.

This is the entire reason I keep beating a dead horse, because as I've explained (both via explanation and by literally showing you what this sort of code would look like in a standard, easy to parse programming language) this is a simple variable check. in BYOND terms, it's performing a check after the attackby to look at the table, which judging by the fact that failure %'s are in place prior to conducting surgery, already happens prior to the menu being called. Despite that you've persisted on this line of logic that this is somehow "major code snowflaking" and the argument that my suggestion would somehow create instability/undue work/pressures on coders/maintainers. Then, when I respond to your assertions, you say I'm being "remarkably condescending". Yes, a QoL PR got pushed through on the GitHub (or not yet merged, rather) which is great--I'm genuinely happy about this because it means autopsies won't make my wrist hurt. Actively trying to snub my suggestions for what seems to be no good reason, not so much. I'm not sure why you think I wouldn't be prompted to respond to you.

As the person who made the original suggestion, no. I brought it up as an option, but stated it's not a requirement because the map already references the table in the morgue as autopsy_table. I'm pretty sure I have the ultimate authority (as the person who made the suggestion) to call you out on deliberately misrepresenting what the suggestion is. It's literally a variable check, and I'd appreciate it if you stopped being ridiculous about it.

No to all the misc titles which usurp existing jobs/roles or give justification to poor behaviour. Also no to Stripper for obvious reasons No to Head of Service, that's the HoP and this will just create misconceptions.

I think Purpose's idea fits well in the same vein of this without reducing antags to pacifists (which they shouldn't be). It gears certain antag goals more toward the Mission Impossible or secret agent style of things, which is really neat.

I think the former idea is a good thing, but table-crafting is painful in comparison to utilizing a microwave or such especially given the sheer variety of things. I wouldn't mind seeing menus on the individual equipment, or maybe an in-game book that loads the wiki page.

Under the sleepers, too. Shouldn't be that hard, as long as our current BYOND spooky script supports the demarcation of tiles based upon what's on top of them... Basically blood you can't see and can't be cleaned with anything other than soap.

Second part was my main point here since proposed implementation was a variable check in one script that's already proc'd when the attackby on the scalpel fires; subsequently this required nothing to be cross-referenced which is why LTH calling it massive snowflaking threw me off. Interdependency in scripts isn't a bad thing and helps to make code more lightweight (you should always strive for as few functions as possible), but it does come with the caveat of less modularity. Again it still seems like a stylistic preferenc, as with adequate tabbing and proper commenting it's a non-issue, I've also always been of the "less is more" camp--which the proposed PR does an even greater job of so no complaints in that area. I seem to recall having a tool that labelled and categorized scripts at one point, and told you which ones had dependency or co-dependency with which. People who put closing brackets at the end of a line instead of on a new line deserve death. >:C Also, I'm pretty sure Purpose was responding to another post, not yours in particular.

Here's the explanation on the scheduler for those curious.

If I'm understanding correctly, more or less the inverse of the suggestion then? Have a limiter on them returning rather than them leaving? Either way I wouldn't mind seeing either implementation, and I also wouldn't mind the removal of bleeding or vomiting underneath machines/computers. Honestly removing bleeding underneath machines in and of itself would be a pretty damn good nerf to slaughter demons.

Primary point is here. The two lines of code involved in Tajaran glovesnipping was "snowflake". Snowflake was also used as an excuse when the PDA slot was slated for removal, because adding a button elsewhere was "snowflake". I can draw up a hundred more examples of this phrase being used for things people simply don't like if you're really interested. Either way, it's a throw-away phrase and the misappropriation of it is immediately evident to anyone who's learned to program in just about any standard language. I gave you a concrete example of how heinously easy it would be to implement the suggestion line by line, though the solution presented achieves the intended result to a greater effect (which is the only important takeaway here). Both solutions more or less involved the addition or subtraction of a check, and both involve bypassing a menu. In the PR's case it removes a requirement (checking if the autopsy surgery has been performed) and likely also axes the autopsy surgery from the surgery menu (thus touching on the autopsy scanner, and surgery scripts). In the original suggestion's case it adds one check, and touches one script. This is the crux of why I asked you to do some programming, because checks like these (else if ladders) are the absolute first thing you learn to do outside of outputting text to a screen and statement structure (where brackets go). BASIC is an easy language to start with, though lots of people find python, LUA, and C++ very intuitive as a lot of spooky script (dreamed up scripts like BYOND) are built from the logic/organization of these systems. Whether or not someone thinks one way or the other is "way too snowflakey" is irrelevant here, both are viable implementations. Again, "snowflake" is a throwaway term which seems to refer to a stylistic choice in programming rather than the efficacy or viability of certain solutions. In this instance we're literally talking about checking, or not checking a single variable. I doubt you are familiar with it, but the age-old joke about C++ programmers seething at their coworkers who learned Javascript first fits nicely here. This is the crux of why I've been responding to you and telling you to try your hand at programming, because you genuinely seem to not understand the basic underpinnings of how programming works. Either way, this suggestion has been addressed and something in the vein of it is on the GitHub now.

I suggest you take a programming course, because even a cursory understanding of programming will tell you how easy making a check like this is. "snowflake code" is an entirely subjective thing and is often assigned to features people don't like. This PR is a tidier solution though, and removes 44 clicks instead of 22 (even better) thus addressing the QoL problem.

I wouldn't mind seeing both of these die in a fire. They just encourage people to operate outside of the actual role of the IAA position. Lawyer is unneeded as well, it just encourages Phoenix Wright memery and IAA's are seldom competent enough to be part of a trial - especially those with the "lawyer" title.

If there's only 3 volts in the line, wouldn't a contactor just be a switch? *honk*

He's asking for options to have it travel to other Z-Levels rather than the current three it's restricted to.

So switches. Sounds good to me!

Honestly, as long as this means medical armbands are coming back into play I'm all for it... Those armband accessories were <3

I'll concede on this only if pacifists automatically get lowest preference for traitor, because if it randomly chooses too many pacifists you effectively have Extended+. This still feels a little hand-holdy though, SS13 is all about being forced into uncomfortable situations you have no experience with.

I think these almost got ported once before, or at least suggested. Not sure what happened to it. Either way, I'm all for them.

All I'll say is this. Please, please, please favour vertical over horizontal design. Horizontally oriented rooms in SS13 almost never look right given the shaky appearance of a lot of sprites on east/west orientation. Maybe this is subjective, but north/south layouts and north/south sprites always tend to be more aesthetically pleasing.