Skull132

The ultimate goal is to ensure that departmental officers serve the departmental head of staff first and foremost; and that the enforcement of warrants and other matters does not fail as epicly as it did during the test merge. We deem that the most effective way we can make this point clear is to separate them from the general security information space. If this ends up being too much, for one reason or another, then we shall alter our approach. But for now, and because the only other alternative currently visible was deemed more counterproductive to the goal of departmental security, we're gonna try this first.

Funnily enough, this was actually discussed! We expect the laws of physics to apply here, though. Specifically ones around entropy, conservation of energy, and human laziness. Good luck!

Well fuck I need to write this shit up a second time because I decided to hit an unknown combination of buttons and Windows's response to that was, "WELL I GUESS YOU DON'T WANT TO SEE THIS WINDOW OR ITS CONTENTS EVER AGAIN THEN! BYE!" I am saying this to vex my frustration, I hope this is clear. So the Player Feedback We got over 100 99 responses on the questionnaire that we released. Which is I think a solid 10+% of our monthly unique player count? Something like that. And hey, that's good! 54.5% of the respondents had played security during the test merge; 32.3% of the respondents had played antag during the test merge. Here's a short rundown of key results: 62.6% of the respondents rated departmental security a 4-5 / 5 in gameplay. 74.7% of the respondents said that departmental security made it easier for security to exercise authority over them and their department. 74.1% of the responding security players said that this had a positive effect on their game play. 50% of the responding antag players reported that this change made their setup period more difficult. 56.3% of the responding antag players reported that this change made it more difficult for them to avoid being captured. In contrast to the above numbers, 72.2% of the responding security players said that these changes did not make spotting antags easier. 42.6% of the responding security players said that these changes did make it easier to spot other criminal or suspicious activity. So, what can we take away from this? Well, the majority of the player base appears to like the change. For one reason or another. So hey, that's good! Sec players also seemed to like the change! But this comes at a cost. The rest of the numbers aren't all that positive, with regards to what we, the leadership and development team, were trying to achieve. To use the touting of a loud mouthed security player on Discord to illustrate the matter, "Hah, you just gave us easier access into departments!" Discussions with other players and members of staff pretty much confirms this, that the largest change here was increasing the effectiveness of the centralized security team, by virtue of giving them more access. Which is, completely and utterly counter to what we were trying to achieve. The Changes & What's Next The player base wants dep sec merged. Alrighty. But this comes with 3 changes that are to be done. The first two are aimed to directly tackle the point we missed above. The idea of departmental security is that they are departmental security. Officers who are subject to the departmental chain of command they are stationed in. So to reinforce this, the following two changes will be done: SOP will be introduced to clearly state the departmental officers as having to listen to the departmental head of staff first and foremost. (At least on green.) Simple enough, will clarify the CoC. There will likely be other edge cases and matters to be tackled by @The lancer and his SOP team as well. Departmental officers will lose security channel access on code green. While I do wholly understand the importance of communication, I do also understand that undermining this point is the most effective way to get at what we want to get at. Removing the departmental officers from security net will make them more reliant on their own departmental chain of command. The alternative to this one, thus far, has been to nerf access of the departmental officers to just departmental hallways. But I believe that to actually run counter to what we're trying to achieve. The final change is to do with basic arithmetic and numbers. 1 cadet slot will be removed. The reasoning is simple: security as a whole gained 1 officer slot in dep sec. Thus, instead of fielding 10 bodies that can be armed as needed, we're now at 11. Removing the cadet puts us back down to 10, and life will be fine again. Is This All? Well, yes and no. SS13 is not a very static nor persistent game. Things will change, and the setup of security will likely change as well, again, in the future. So none of these changes will be Permanent:tm:. And specifically with this, we'll be re-evaluating the new implementation a short while after it's gone live. If shit suffers too much, there's always the :ree:vert button to be pushed. Or changes to be made, comms to be removed, access to be tweaked, etcetera. But on a bit of a longer game picture. Security has an immense role and presence on the station. (This is followed by the AI and a few other things.) And this is limiting, from the perspective of gameplay development. Any obstacle we present to the station, anything remotely foreign or dangerous, security is going to be there, in force, to deal with it. And this is not necessarily a positive thing to work around. So I want to put forth the idea that this will not be the end of us touching security. NBT has a different suite of changes slated for security to undergo, ones that are not even remotely enabled by the current command structure, setting, etcetera. More details on this whenever NBT has actually passed pre-production entered production (otherwise I could be saying the same story over again for 5 times). But, smoll steps at a time.

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.