Skull132

The long standing idea is to introduce more powerful random events. Specifically player driven ones, like random Vox appearing on station or whatever. For both extended and non-extended rounds. I don't think increasing extendo chance in secret is a good idea, extended is already the most played singular game mode, taking up 40 - 55% of the play time per year.

On the flip side. It is debatable whether "You need a good gimmick" to be a good antag. IMO gimmick culture is cancerous and needs to die in a fucking fire. Just play antag, create a bit of a story, and voila. You're good. People being disorganized is fine, this is the norm for new antag players. Another fun thing to point out is the idea that bad antag players get "punished for being bad at antag play". Arguably, the more players play antag and the more familiar they become with the role, the more welcoming (hopefully) the whole playerbase becomes towards the matter.

This is likely a bug with how restricted jobs was implemented. The novel code that I introduced is effectively a copy of how the original draftee list was composed, ergo, it does the exact same thing. So the code implementing the job restrictions is the code to look at to figure out why it's broken.

Age restrictions still apply. So new players won't get antags we consider to be "too complex".

So a bit of history. Last year, we decided to start messing around with code which handles antagonist selection. Specifically, a piece of code which forcefully drafted people who voted for the winning roundtype was removed, and some other changes were made. Following this, we saw a marked flux in the status quo of what round types go through and what fail. The spread of round types played started to suffer, according to our observations. The other changes mentioned were reverted in early December, late November. And the situation did not get better. So, now we've reverted the last change and are about to find out what's gonna happen! With this said, to make the barn big and red, here is what has happened: We reintroduced a mechanic which, on the condition that the currently winning round type does not have enough antagonists to start up, will forcibly draft into antag roles everyone who voted for the winning round type. This mechanic was reintroduced with the primary goal of having the played round types be more varied, by virtue of more round types getting passed their voting requirements. This mechanic was reintroduced under the premise that it did not prove an issue before. This will mean that you are likely to be chosen for antagonists that you would rather not play, specially when voting for secret. We understand that this may appear inconvenient, but we trust that most of you are able to see the necessity of antagonists in the grand scheme of the game, and are willing to play a less-than-desireable role some of the time. We will, of course, monitor this change. Primarily seeing how the round type spread is gonna work out from now on. Along with the disgruntlement of the playerbase, of course. Administrative policy on this matter (and how easy or hard it is to get out of forced antag status) will be clarified by Alb and Garn.

To be clear, he isn't saying that you did bypass. He's saying that you tried. Did you?

Just to shove my 2c in here. I still do not necessarily understand nor see the need for warp drives to exist. Just another under-explored muguffin to escape away from Bluespace because "Bluespace bad and silly" or some shit, in my opinion. Similar comments exist about bluespace gates, though less so.

Test merge is over for the time being. Time to gather feedback. Go here and fill this out: https://forms.gle/hvkEtSpk9S6PL36C9

I once had code for this. I remember my initial drive fizzled after people were unable to provide me with fonts to do shit with when I asked.

Well, that's an essay. But I'll cut straight to a point. The whole deal that echoes through your post, but is highlighted here, is that you seem to think you know what is useful to the survey runners. Basically you are attempting to impose your own view on the matter. Surveys are a tool for gathering information, nothing more. Their efficacy is not tied to how realistically attainable the options listed there are, they can easily be used to poll emotional understanding or wishes and hopes -- theoreticals. Your view completely annihilates this possibility. This is not productive. All of this starts falling apart when I ask, "What if we want to know if the playerbase would be interested in a rework?" For example, the ling and malf surveys, the prevalence of the theoretical rework option demonstrates that the playerbase is at least interested in the core ideas of the modes, and simply disagree with their present execution. Which is a completely valid piece of information to obtain, and one which would not be obtained by a simple, "Yes, remove; no, do not remove" poll. Another piece of information that can be interpreted from it is that the majority of the playerbase (rework + no votes) disagree with the present implementation of the modes. Which, if you wanted to call for removal, would be the one you would use. So, with this form of processing, I would not consider the answers we gave as "wrong". As for this. Yes, it is. We are a loose organization that has no real legal responsibilities towards standards, nor the capital required to enforce these standards. What you effectively request is that we write an SOP for running surveys. What you have to ask for every document or regulation added is: "Is this actually going to be used?" The fact is that 75% of all auxiliary documentation, such as this one, would be put on the wiki somewhere, and then forgotten about. It's really just how this all works. So no, this information would not be useful to document nor to codify.

This will not be codified. Because it is a dumb thing to codify. What you plan on getting feedback for will dictate how you set up the polls and what questions you ask. It is up to the decision maker to figure out what question he wants to ask, and how he wants to interpret the answers. Specially considering that all community polls are non-binding in nature. Sometimes a very clear binary choice is the most reasonable option. Sometimes degrees are permitted, with, if necessary, some inbetween choices being categorized as a super-group for a more cut-and-dry view on the matter, if it proves necessary. Obviously yes, there are certain practices in polling and statistics that might be beneficial to adhere to, but I assure you of two things. What you wrote is not clearly present in them, and the list of best practices is too long to actually codify.

Okay. First. Leave all of the pitchforks at the door stop, please and thank you. We have now embarked upon a long test merge of departmental security. The aim of this test merge is simple: to gauge the effect that departmental security will have on gameplay long-term. So basically, we're not interested in the question of, "Is this specific implementation mechanically fit for purpose," we're more curious about the effects this would have on gameplay once the playerbase has gotten used to it. The very long-term play here is to figure out if this method of implementing security is worth employing for NBT or not. This test merge is actually the last major stop before work can proceed in earnest. For this end, this test merge shall last a minimum of 1 week, potentially more, depending. We'll update if the latter ends up being the case. Regarding feedback. First, any critical bugs or oversights should be reported on the PR: https://github.com/Aurorastation/Aurora.3/pull/8209. Any actual feedback you are free to leave on this thread, but beware: we will likely also be submitting a structured feedback form, which is going to be our primary basis for any decisions made here. On top of what the admin and development team is able to gleam from their own observations. When submitting your feedback, please consider that implementation minutiae is not final. So if there's a vending machine missing or something like that, do make a note of it somewhere on this thread, but please do try to see the forest from the trees: we're primarily concerned with evaluating the gameplay effects. (Unless said minutiae is critical to gameplay, like missing job equipment or whatever, of course.) Implementation details can be hammered out in later iterations. Thaat should be it. Be civil. And enjoy the game!

Trenchcoats don't look contemporary enough for the setting, IMO. They look very 1990s era. Look at Deus Ex or that one game about cyborg cops for references on more futuristic designs.

Technicalities wise, I'm afraid Wezzy is leaning on being in the right here. The sprite has no outline. The size is bordering on too large in proportion to the other items. The primary accent colour belongs to the science department, not the medical department. In fact, none of the accents used mark it as belonging in the medical department. Like, the sprite looks good on its own, but it does not fit the rest, not by a long shot. Regarding the approval process. It would be incorrect to say that the maintainers do not lean upon people of expertise for their opinion. In the case of sprites, it would be Wezzy. However, I'm not exactly certain what behooved Wezzy to say what he did. Not that he even needed to say that. But this matter shall be pursued in private, for the time being, and should not be discussed further in the thread. Allow me to reiterate what I've reiterated before. The maxim currently pursued by the head devs is that anyone is free to put up their PRs with or without coordination. Just that, without coordination, you run the risk of having heavy changes be requested about things you would have known about prior, or having your PR be deemed unacceptable.

I mean, I can get that list at the drop of a hat from the server. Just good luck attaching such text to it.

Note that praise like this shouldn't be taken to undermine the points others have against this community. No one says it should, and it is your own doing to read into it as such. In fact, a common leadership maxim even suggests that this be the way to handle praise -- "Praise public, punish private." The entire concept being that you should do your best to highlight, publicly, the positive actions people have undertaken within your command. With modern psychology heavily reinforcing the idea that positive and constructive feedback is more sustainable than negative feedback. Some have pointed out, that because we've made mistakes, we should not be able to hold our heads high and proud over our achievements. Note that I'll clarify the definition of "Our" in a later paragraph. If people want to apply this as a personal standard, then that's fine, but that'll be their personal standard. Ultimately, the pragmatics of the situation are that we've existed as a community for 6+ years. Mistakes get made, people get discouraged, people don't agree with our views or ways of doing things, and eventually those people leave. This is. Natural, when dealing with as large a group of humans as we have been, summarily. There is no way to avoid this. Many have tried: I've watched young server managers start their own thing, sometimes out of spite, sometimes with very good intentions, running into this roadblock. Even I had a different view on community management than I do now, back when I started. But does all of this mean that we should bow our heads in shame, to not be proud of our achievements as a community, as a staff team, as a server? No, it does not. Because for 6+ years, we have offered an experience that a large enough group of players enjoy for the server and community to not only exist, but to grow. You cannot grow on a rotten core, BestRP and other servers from before 2014 have proven as much. And so, I do not see any harm in pointing out the positive. The alternative is to hold a cudgule over everyone's head, but this would do nothing but promote sycophancy, as the price of admitting to being wrong would be too great to tolerate, and as such, you are simply never wrong. And finally, on a less serious note. When Jackboot initially asked me to compile a list of people who've contributed to the server/community, I originally linked him this. I now realize that I should have instead linked him a list of every single ckey that has visited our server. The point being that everyone who's participated in this community has contributed to it in some form or another. Whether it be simply by playing, or by joining staff and contributing more time and effort to helping this community develop. And all of this is worthy of a thank you.

Check the whitelist applications section of this forum.

High-school popularity contests suck because high-schoolers take them to heart. One would hope that this community is, on average, mature enough to not take these matters to heart. But, I guess we can all be disappointed in one way or another, then.

Psure you can ditch the spreadsheet and just look at the secret weights for this output. There should be nothing else weighing them in code, if you presume that all of them can run.

Well, you have at least 1 other ckey, if not 2, under the same ban. What's up with that?

The problem with Mendell is the same as with the station. It's static and will require a major refresh after nominally 4 years. Except it's somewhat harder to move characters when you've got people living there, vs having a station -- a clearly temporary residence. Another issue you lads should try to unwrangle. Why would I pick a role with responsibilities and duties, if I could just pick civilian/inhabitant/whatever? The presupposition here is that we expand upon the available feature set that these roles have access to. At the moment, one of the main discouraging factors from playing visitor is that your access to doing cool shit and interaction with others is REALLY limited.

Setup of the SM does not take a significant amount of time. It requires almost no maintenance. So there's nothing about it which "binds" engineers, ergo, there's nothing to "free" the engineers from, sans 15 minutes or less of round start setup. Which is inconsequential. Second, the powerdraw of the station doesn't really depend on the size of the crew. Most of it is static. Unless you start actively shutting down departments, but hey, then you're spending the initial 15 minutes shutting down departments vs setting up the engine. And if you choose to do that, and happen to be in a transition round, you have to set up the engine later anyways. Ergo, there's nothing to win by NOT setting up the engine.

If a species is meant to be androgynous upon inspection, then the code can be altered to reflect this. This is already the case with Diona, and if the Skrell lore dev wishes, can be expanded to Skrell. In species with commonly clear sexual dimorphism, such as humans, Unathi, etcetera, gendered pronouns per mechanics would remain, as I do not see a need to expand this to all species if we can already alter it per individual species per necessity.

Okay so, we did a final review of evidence, discussed some implications, and came to a verdict. First, the evidence. There were 5 points of evidence to consider. First were the PDA messages, which almost every single staff member that I asked an opinion from considered more incriminating than Bear makes out. Second piece was the bloody crime-scene itself, which Bear reportedly did not make an effort of to clean up. Third is the fact that I have 2 observers reporting that Bear stowed a bloody RIG/voidsuit in his character's locker, still bloodied and set to Tajaran mode. Fourth piece is the fact that Bear's character still had the bloody murder weapon on him upon arrival in CC, or at the very least, made minimal effort to dispose of it. And the final piece is the body itself, which wasn't crushed or otherwise disposed of. While true, it's really bad luck with how the tale of the body went, and an effort was clearly made on this front. To address some comments about the processing of said evidence, and the rules of The Game. It is true that very minimal amounts of evidence above was processed by IC means. However, the murder was conducted in the closing 15 - 20 minutes of the round. Which, in the context of canon murders, is probably the most unfair time to pull one off in, since it gimps the station's investigative forces immensely and puts the offender at an advantage. In an effort to keep The Game more fair, the administration reviews the evidence instead. Had a proper IC investigation been done in round, and had Bear's character managed to somehow talk off, hide, or otherwise distort the evidence while the investigation was in progress, our view on it may be different. But this did not happen. So, with all of this in mind, the staff believe that there is a lot of evidence pointing towards Yahir and not anyone else, really. The added extra of murder in SS13 is that you have a very closed list of suspects to run down, and likely, out of the present crew, Yahir would stick out like a sore thumb. So the verdict is likely going to be a guilty one, after some time spent on investigating and in court. There are likely some freedoms you can take with this matter, ranging from the character committing suicide to playing with how long the investigation and court hearings take, running the hell away, etcetera. But the final verdict would be that he's likely to be found guilty and is eliminated from play up until that point, and after that point. There was also a compromised developed over the weekend between Resi, Read, and Bear, which outlined the possibility of Yahir posting bail. However, literally every single leader of staff that I consulted on this matter was against this, from Mofo to Lancer to Head Admins. For two reasons, largely. First, it gets us in a bit of a quagmire, by allowing a murderer on station and among crew. Which is a spot that the administration is very keen to keep restrictions on, for obvious reasons: it's a very tough role to pull off and can end in horrible cringe. What's worse is that the murder in question wasn't exactly clean. Scuttlebutt is gonna run, and the amount of circumstantial evidence (note that circumstantial evidence is typically enough to convict, even for murders) is massive. Had it been a more thoroughly conducted affair, our opinion on this matter would have been different. This is to say: we do not believe the murder, as conducted, is clean enough to merit the character "surviving".

This hints at a more glaring underlying issue. Our role setup does not scale. At all. To be quite honest, I'd love to see the amount of roles scale up and down depending on current station size. This would solve the issue of over-stacking, and also help direct players towards picking roles that are generally needed.