Warriorstar

ERT set their PACMAN too high Cyberiacyberiacyberiacyberiacyberiad

Maybe put that list in a gist or something but this is a really good idea, I want to comb through it. What are the odds we can do a quick check of every list to intuit what types it stores so we can see how many /lists of strings, how many /lists of mobs, etc.

Empyrion. It's an open world space sandbox that's generally eclipsed by more notable games in the genre like Space Engineers or No Man's Sky, and it's janky as fuck, but there's a ton of great community content (look up Eden Reforged once you get the basics down), you get to build different kinds of structures from terrestrial hover vessels and small space ships to large capital ships and entire stations. There's a bunch of very generic but mostly satisfying weapons, space combat is fun, there's factions, player XP, and tech trees. It sets out to do a bunch of things and executes some of them well and others not so well but there's dozens of hours of content in it. Ostranauts. It's a top-down salvaging/combat/exploration/shipbuilding game from a largely one-man studio, the same guy who did NEO Scavenger if you're familiar. It's fun and in the almost exact same cassette-futurism universe that SS13 exists in. The atmosphere is solid, there's mechanics for safe space travel, wiring up your spaceship, generating power through fusion, etc. and dozens of kinds of ships to scavenge parts from.

Chef is probably the best singleplayer role on station. Not only do you have the kitchen to yourself, but the game mechanically reinforces your autonomy by giving you CQC to give the beatdown to assholes who break in. As much as I appreciate the sentiment that SS13 is a cooperative roleplaying game, that only works if the other crew aren't the most obnoxious brats ever to grace the sector. No amount of roleplaying potential can fix a situation like: Assistant: *walks up to kitchen door with a locker slamming the airlock* Chef: What do you want? Assistant: Let me in. Chef: Why? Assistant: *starts hacking door* Chef: Stop it, I'm warning you. Assistant: *breaks in* Chef: *knocks their block off* Assistant: I BROUGHT YOU MEAT, I'M TRYING TO HELP Chef: I DON'T WANT YOUR HELP AND I DIDN'T ASK FOR A BUNCH OF ANIMAL CARCASSES AND WHY DIDN'T YOU START BY SAYING THAT INSTEAD OF WORDLESSLY BREAKING INTO MY DEPARTMENT (repeat every shift)

Relatedly: Big brain golem gaming (diamond farming from a watcher tendril if you're unfamiliar).

Big brain Theta gaming.

shshshsh

@Veterankyl you're all good. I have to close this out after that. Thank you everyone for your support. I'll do my best to make sure everyone is part of the ensemble cast. I can't make any promises on when I'll be done, but I promise it'll be worth the wait. Maybe. Stay tuned.

full disclosure, i am an (extraordinarily inconsequential) member of the dev team. despite this, and being in the private dev channel, i *also* don't see the vote tracker, so publicizing the private dev channel (specifically, distinct from the vote tracker) wouldn't change the result whatsoever, because not every decision is made in a town hall setting complete with peanut gallery, nor should they, nor can they. for my part--without retreading the existing (salient) dicussion points regarding admin energy/burnout/harassment; that not everyone *should* be a part of every conversation, even as an observer; and that 99.9% of the time the "problem" is just that maintainers have lives and are busy and things fall between the cracks, which won't change if decision-making is publicized--i think: to say "right now we get nothing but a yes or no", followed by affected and charlie posting PR comments that are *not* just a yes or no, followed by saying "i don't know why you're cherry picking examples", and then "sometimes we do get explanations but" is self-defeating. if your argument is "right now we get nothing but a yes or no", and the response is direct, objective, contradictory evidence, it's hard to take the assertion seriously. if the argument is that this is a slowly aggregating trend, then you need a trend *line*. in other words, specific, objective data showing the difference between how many PRs have been closed with no explanation between the previous dev policy and now. people's feelings and impressions about the situation aren't going to cut it (especially the kinds of comments that start with "it just seems that"), especially since contributors tend to place disproportionately high emotional value on their PRs, either because of the time spent, the emotional investment in the community, the perceived quality/value of the implementation, the hope for the desired outcome, or the jarring nature of normally having one's PRs accepted only to have one specific one denied. admins are not responsible for anticipating and shaping the emotional reaction of contributors. the dev team already walks on eggshells to try and work against this. the policy shouldn't be tailor-made to optimize against emotional blowback from contributors. i've lost track of the number of times i've heard that transparency in decisions like this is _ipso facto_ better than opacity but the impetus for this discussion seems to be that the lack of transparency discourages contributors. there are already plenty of venues and opportunities for contributors to get blessing to work on something: in a design doc, in a github discussion, in the discord. putting names to decisions only gives contributors ammunition against individuals, which is precisely why things are the way they are now. never explaining decisions discourages contributors. always publicizing decisions discourages the dev team. that's why we have two phases to the process, the public decision making venues, and the final say the dev team has. i think there's a belief that if this level of transparency is enacted people will suddenly discover their PRs are being denied for nefarious, petty reasons, and not just what it is now, which is things fall through the cracks, the dev team is busy, miscommunication happens. the vote against on the banana cream pie sound effect PR is an individual instance of a PR denial by a member of the admin team for no stated reason, which was allowed *before the new dev team structure and policies*. is not an indictment of the current dev policy writ large, or a microcosm of the behavior of all of the dev team. the failure to share an explanation here is a *mistake*, not an enforcement of the new policies, and considering we are all fallible humans adapting to a new organizational structure, things like this are bound to happen. in other words (or the same words as above, which apparently require incessant repetition): maintainers have lives, are busy, and things fall through the cracks. if this was allowed under the old dev team structure/policies, then asking for the old dev team structure/policies back will make this happen _more_. like, the thing you want back is the thing that caused the thing you don't want to occur. and if the PR author *is* discouraged, there are already venues for the PR author to request clarification in cases like this. they can ping the team in discord; they can DM the admin who closed the PR; they can post a thread; they can reply on the PR since closing a PR does not lock the comment thread, that's a separate action; they can even (but i'd save this for the most egregious cases) file an admin complaint on the forums, after all, voting against a PR is an admin action. ultimately, by being a contributor, you're placing trust in the admin team to maintain the trajectory of the game and community. the admin team already goes above and beyond in terms of organizational transparency: you know the name of every admin member, mentors and admins are selected on an evidentiary basis with an application process and standards team members are expected to uphold; every ban appeal is publicized, every admin complaint is publicized, affected not only provides public profiling and round stat APIs, they also bust their ass every year to put together a state of the server sharing all the salient highlights of codebase and production development; the entire development team policy is public, and i can guarantee that there are no dev team members who don't uphold themselves to those policies. the dev team channel isn't private because we have something to hide; it's because there needs to be a place where lightweight, informal conversation can occur without input from a peanut gallery or disproportionate hysteria in response to non-binding or casual discussions of the game without firm conclusions before official decisions are made and properly communicated to the community, and there needs to be a way for individual admins to perform their functions without worrying about emotionally overinvested gamers keeping excel spreadsheets of all the times they feel they've been wronged, personally and deeply, by Admin Alice or Headcoder Harry.

Okay, no worries. I need at least one roboticist for story reasons and I don't want to make a player character do something that conflicts with their personality, but I think I can fit you in.

@Medster and @Spacemanspark: would either of you describe your roboticist characters as "mischievous" or "impulsive"? And if not, would either of you be okay with me having your character do one or two things that are uncharacteristic? Also, holy fuck I did not expect this many responses. The INFERNO thread was up for 5 months and got 18 responses, this has been up for less than 24 hours and there's already more than 40 submissions. I will try very very hard to make sure everyone gets to make an appearance.

Sorry, Bartender isn't available for story reasons.

Yup, that works fine!

Sadly the bartender role isn't available for story reasons.