Kyet

I don't generally touch lore stuff. I don't really mind what the lore contains as long as it isn't used as a justification for un-fun gameplay. I consider lore that requires certain races to snip the fingers off their gloves / ends off their shoes to be un-fun gameplay. I don't think it adds anything that helps define the race as alien or interesting. All it does is add a tedious task that players of that race have to do regularly. "Unique" is NOT necessarily valuable or interesting.

I don't think they (or other species) necessarily need to conform to our understanding of biology. They're aliens. Not just that, but they're aliens in a sci-fi game. A soft sci-fi game, at that. I'm also not keen on making them take more brute damage, since brute is the most common damage type, and it would be a major and likely unpopular nerf to them to do that.

@TullyBBurnalot

About Antag Tokens: Antag tokens are given out by admins, at their discretion. Typically, they are only given out to antags who have their antag round ruined by an admin's mistake, such as if an admin accidentally crashes the server. You are never entitled to an antag token. If you want to know if you have any antag tokens, ahelp and ask. There is no other way for you to check if you have one. If you have an antag token, you can ahelp "''I would like to use my antag token to become an X''" (where X is "changeling", "traitor" or "vampire") at the start of the round, to become that type of antag. You cannot use antag tokens to become any other type of antag not listed above. You cannot use the same token more than once. Even if you die 20 seconds after using the token. You cannot use antag tokens if you are playing a job that is typically mindshielded, like Captain or Security. Admins may deny your request to use an antag token in any particular round. We typically do this when the round is expected to be short (stops you wasting your token on a short round) or the antags are already very numerous/strong (stops the round becoming too unbalanced). If we deny your request to use a token in a particular round, the token is NOT used up, and you can try again next round.

You do make a good case. I've been considering creating an item/structure that, when powered, blocks all teleporting effects into/out of an area. Primarily I was considering doing it for the syndie depot, but it could also work to balance telescience by making it impossible to just beam things out of the armory, for example. Problem is, if we're at the point of altering the map (adding jammers) specifically to counter telescience, perhaps you're right that we should just remove telescience instead.

Are you asking for surgery to work on them in particular? If so, that's probably not possible, because it would require changing them from simple_animal type mobs to full carbon mobs, which is undesirable for various reasons. Are you just asking for a way to heal them? If so, that's probably doable technically (all it would require is say, brute/burn patches to work on them).

Thoughts: Making spiders able to wrap people in crit introduces several new problems. What if the person then pops OUT of crit later? There's no way currently to resist out of a spider cocoon except attacking it from inside - which they may not be able to do. Plus, they're trapped inside for however long, and ghosting gives up their ability to respawn in that scenario. I've been debating, on and off, just giving them the ability to kill targets in crit much more easily, but the main argument against that is that I don't want to snowflake them, and I think that more generally it should be easier to kill targets already in crit than it currently is. Yellow spiders seem... I dunno. If spiders are going to slow people, a venom that does it makes more sense to me than using teslium. Blue spiders seem like a decent idea. No real pressing need for them, but a cold-based spider seems neat in theory.

Apr 3, 2019: Norwest has joined the team as a Trial Admin

May 30th, 2019: Spartan has returned from retirement to resume their position as a Game Admin. Harkness22 has been promoted from Mentor to Trial Admin.

Mar 28th, 2019: Mentor TinnCatt has been promoted to Trial Admin. Mentor Darkpyrolord has unretired and returned to being a Game Admin.

Mar 25th, 2019: Xerdies has been promoted from Mentor to Trial Admin Darkis95 has unretired, and is now a Trial Admin again

Hello everyone. As you probably know, I was recently elected by our staff team to be a Head of Staff for Paradise. You may not know exactly what a Head of Staff (henceforth: "Headmin") does, or what my plans are in particular. This thread is going to explain those things. First, what does a headmin do? Headmins have a few responsibilities beyond those of a normal Game Admin: Co-ordination and management of all branches of the staff team Handling Admin Complaints Enforcing staff policy and admin guidelines Moderating interpersonal conflicts, as needed Managing certain back-end things, such as our Patreon Voting on the acceptance/rejection of PRs submitted to our Github (IE: changes to the game's code, features, sprites, etc) Representing Paradise to other SS13 servers Handling anything that doesn't get handled by other people, eventually, for whatever reason Like any Paradise headmin, I will be doing these things, as they are inherent to the position. That said, most staff (including me) who run for election as headmin also have a specific platform that they run for election on. My platform was: Transparency Accountability Better Communication I know those sound a bit vague. So, let me give you some concrete examples of what I intend to do. First, let's take PR voting. Yes, headmins vote on PR acceptance. But I plan to do more than simply vote. I consider every PR author that contributes to our codebase to be valuable - part of the team that makes our server awesome. I want to encourage PR authors and grow the number of people who contribute to our codebase. As such, I will be following a set of best practices, designed to ensure PR authors feel valued, and treated fairly. My hope is this will encourage quality contributions over time. I will not be voting against any PR, any author's work, without first explaining exactly why, clearly and directly, on the PR itself. If my issue with the PR is fixable, I will explain how it can be fixed, and give the PR author some time to fix it, or at least respond, before I consider voting against the PR. In essence I want to be sure PR authors know they are getting a fair shake, that they never feel like they're being left in the dark, and they never feel like they need to guess what they need to do in order to get their PRs merged. If I consider a PR idea totally unviable, to the point it cannot be fixed, I will aim to say so as early as possible, so that the author doesn't invest more time into it under the false impression it has good chances of being merged. More generally, when I comment on PRs, I will aim to be very clear about who I'm speaking for, and what I mean. I will also make myself available to any PR author who has questions. While I recognize that this will give PR authors direct feedback they're not used to getting, ultimately I think (and as a PR author myself, I believe I have good reason to think) they will quickly appreciate it and be encouraged by it. I have also be encouraging other headmins and maintainers to follow these best practices. More generally, I want a more constructive, informative atmosphere on our github and I am working with everyone involved, especially the maints and other headmins, to achieve this. As part of this effort, I have already appointed someone to be responsible for helping to moderate Github, and discourage toxic comments there. Second, let's take accountability. I have already promised to put myself up for re-election in 6 months by the staff team, so, if they don't think I'm doing a good job after that time, they can boot me out and get someone else in. Accountability is for everyone, though, not just me. This includes admins, players, and even visitors who don't play here. If someone has an issue with an admin's conduct, they need to explain the issue in our Admin Complaints forum. It is against the rules to discuss bans and other punishments in our discord server, and for the sake of eliminating toxicity, holding admins accountable under our guidelines, and holding players accountable under our Discord rules, I will be enforcing this rule, and pushing admins more generally to do the same. Consider this your forewarning that under my plan, complaining about being banned in our Discord will not be tolerated like it has before. This also applies to in-game LOOC, deadchat, OOC and similar. This is not a new rule - such talk has been against the rules for a long time. What is new is that I will be enforcing the already-written rule, and encouraging all other admins to do so as well. Third, let's talk about better communication. One of the long-standing issues we have as a server, with our elected leadership, multiple branches of staff, etc, has historically been a lack of unified vision for the future of the server. Obviously, this is an enormous topic to tackle, and progress on it is going to require lots of work, and not just by me. It is the sort of thing that will require lots of discussion over a period of time. Still, I am already taking steps to move us in this direction. The first change you may notice is the creation of a #changes-wanted channel on Github. This channel is the new central repository for lists, posted by headmins and maints, of all features/PRs/etc they want implemented for the server. There are many benefits to this, such as helping PR authors choose a PR topic that's more likely to get merged, triggering healthy debate on server direction, etc. Ultimately though, this is just a first step towards what I really want for the server: a more general development roadmap. I know we're a volunteer project, a 2D spaceman game, and we're never going to be as organized/detailed in our future development goals as a professional game company is. Still, I don't think its unrealistic for us to take basic steps, like agreeing a list of long-term goals, trying to make progress towards them, and tracking that progress. This discord channel is the first step in that direction. I hope I've given you a sense of what I'm about as a head of staff. Obviously, the changes I want to make will require that I work closely with the rest of the staff team. My hope, though, is that I can push the server in the right direction. That I can get people pushing together in the same direction more effectively. And, if not, well, the staff can always vote me out again in 6 months. Here's to the future! -Kyet

Mar 20th, 2019: Saxis has been promoted from Mentor to Trial Admin.

Mar 19th, 2019: Regens has retired from his Game Admin position, to focus on their other role as Server Dev. Fethas and Falseincarnate have retired from their Game Admin positions, to focus on their other role as Coders. Sasanek12 and pazneria12 have retired from the staff team.

This thread has been replaced by the #changes-wanted channel in public Discord. Please see there for updated lists of what PRs/changes maints/headmins want or don't want.

Mar 17th, 2019: Spartan has retired from the staff team.

Feb 26th, 2019: R1f73r is no longer on staff. Mar 13th, 2019: FreeStylaLT has retired from the staff team. Kyet has been elected head admin.

I have 300+ unspent karma. At a certain point, you have more than you'll ever need, and its only polite to encourage donors to give it to someone else, instead.

https://github.com/ParadiseSS13/Paradise/pull/6431

This used to be an actual item, called the 'chem sprayer'. Technically its still in the code, but it was made admin-only, due to its strength.

This doesn't seem viable to me, for many reasons. Top three problems: - Command already has the ability to prioritize jobs, and even transfer crew between jobs, which largely fills the role of 'we need more people in job X' on the station. Why would command want to use a contractor when they can just hire a legitimate person into that role? - 200 karma is unafforably high. Even plasmaman is rarely played, and its only 100 karma. Requiring people to have 5 karma to even ask for a contract also means most players won't bother. - This would require a surprisingly large amount of dev effort. E.g. the contracts system you describe, not to mention the code to switch out their shuttle.

During nuke ops, security doesn't have time to be searching crew for contraband, and if someone is walking around in a nukie hardsuit, for example, they're likely to be shot by their fellow crew. More generally, not all crimes have equal priority. Security can and should focus on the most important ones. Sometimes that means letting more minor crimes slide. Specific complaints about someone's conduct in a specific round should go to ahelp at the time, or player complaint afterwards. Not in the guides forum. SS13 is not real life, and comparisons to real life are often unhelpful. Most crew members don't get in trouble most shifts. Given that the general opinion of this guide is that it is at best unhelpful, and at worst advising people to do things that might get them in trouble, I am going to lock this thread. Feel free to create a new guide, but I advise you to discuss it a lot more with other players, perhaps on Discord, before posting it.

There's a lot of stuff in this guide that seems highly questionable to me. Examples: "Merely "thinking" something is metagaming could make it so in the eyes of the staff and get you in trouble, so keep your damn mouth shut about what you always do, even if it is to rush science into replacing tiles." When a player has an opinion about whether something is metagaming or not, it is simply an opinion. When an admin does, in their official capacity, it is a judgement, and a ruling that must be followed. Encouraging people to do things they think the staff might consider metagaming, but keep quiet about it so they are not caught, tends to be read as encouraging metagaming by the staff. "This is useful for head of security, as it's hard to find someone who knows space law enough to play the role without them getting permanently banned for abusing their power" -- no, it isn't. We have plenty of HoSes that know space law well enough, and even if you don't you can look it up in many cases (e.g: sentencing times) as you play. "Security officers will sometimes try to commit mutiny against you even if they aren't antagonist" No, they probably won't. This is super-rare, and if it happens to you really at all, take a hard look at your own actions! "Department Proxy Sabotage: This requires you, the captain, to promote another crew member to have extended access, preferably with the knowledge of security, to go on a mission to infiltrate a specific department and purposely sabotage one of your own work stations." Why on earth would the Captain ever want to give someone extra access for the express purpose of sabotaging the station they are in charge of? I could go on, but I have to cut this post short for RL reasons. In summary: lots of the advice in this guide seems to be questionable, with some of it extremely questionable to the point of you probably getting bwoinked for doing it. Not the stuff you flag, though - I've never seen a captain get job banned for dropping the code below red during an emergency, but I have seen them get banned for doing other things you encourage, like deliberately trying to skirt around what admins consider to be metagaming. Overall, I think this guide needs a lot of editing.

War ops have the odds stacked massively against them. Stealth ops might be a 6v6 stealth operation. War ops might be a 6v60 full combat operation where the 60 have 20 minutes' advance warning to prepare. That is gonna be some steep odds no matter what gear you have. Experienced players know that war ops generally does not win, and thus, they will push for stealth ops. The result is that war op teams tend to be dominated by newer op players, and/or op players who don't actually care about winning. This further reinforces the fact they are unlikely to win. Ultimately, the ops' ammo and weapons are finite, whereas the crew can clone, use pets, golems, etc. Further, the crew controls the location of the disk, which means the ops have to come to them, through their defenses. The longer a nuke op round lasts, the better armed and more prepared the crew, while the more of the ops' resources are depleted. So, a quick stealthy smash-and-grab is always going to be more effective than a full-on drawn out military siege. Once the nukies' comms are compromised, they can't even co-ordinate effectively. The tactics that work during stealth, or surprise ops, like having one person create a distraction, simply don't work during war ops. A lone op somewhere else can create a distraction for a few minutes, but eventually, crew will kill them. In stealth/surprise ops this does not matter since you'll hopefully have the disk by then. In war ops it means you're down a player without reducing the strength of the crew significantly. For all these reasons and more, war ops are at a BIG disadvantage, to the point that many admins (including me) outright refuse to send ERTs during nuke ops, because we reason that the ops have little chance of winning even without an ERT / etc helping the crew. I'm not sure what could be done to make war ops a fairer fight... or even if we should make it one (truly a 6v60 fight where the 6 win may not be satisfying to most players). It definitely isn't a fair fight as things stand, though. Of all the ideas I've heard to make war ops a fairer fight, perhaps the one I like best is: upon declaration of war, turn 1-3 crew into traitors with objectives to assassinate different members of Command. This way, we're discouraging the HoP/Cap from giving everyone guns and all-access, without outright prohibiting it. We're also evening the balance in the number of players on each side, a little, and ensuring that the crew doesn't have 20 minutes' hassle-free prep time. Rather than outright prohibiting anything or making it impossible, we're introducing some disincentives that curb the most problematic behavior on the crew side, and even up the fight, without making anything totally impossible.

How to secure the disk (normal version): Carry it anywhere on your person How to secure the disk (nukeops version): Carry it anywhere on your person Move your person somewhere secure, ideally somewhere where you have a terrain advantage against the operatives (like brig, where you can shoot lasers through windows, and rechargers are nearby, or the bridge, which you can bolt down to prevent entry, even using emags). In the event that your location is compromised, order nearby crew to follow you, choose a new secure location to flee to, and goto 2. How to know which version of the above to use: If anyone is talking about NUKIES on the radio, use the nukeops version. Otherwise, use the normal version.