Skull132

Loreman told me that there'll be an automated support fleet attached to the vessel. To include a cryosleep ship. So the people will live there. The ship will probably at some point have to dock regardless, yes. Maybe, who knows! This is planned as an enterprise undertaken by multiple large megacorporations. So explaining why some species or culture is around is easy enough, still.

[Authorized for public release.] For those of you who don't remember, this is a follow-up to this: It's been a year and a half. Which is fine. For context, the current Aurora map started concept development in the summer of 2014, to be launched in late 2016 (I think?). And in that process included a loooot of rethinking as time went on. Well, this time is no different! Initially we had the idea for a colony type deal, but two major issues stuck out. The first issue was that, it'd still be a static setting. Which is kind of unfortunate, specially with our propensity for running event chains that would be served by getting out there more often. Another point is that it relied too much of mechanics which didn't exist, and the procurement of which would have been difficult. So do took some stock and revised. So, what did we end up on and why? We decided to start moving on a project which we could effectively start working on without any technical prerequisites. So basically: mappers could git to work immediately. And all of the planned features could be accomplished as the map progressed or even after the initial launch. So basically, the minimum viable product of this new plan is a slightly modified space station that coders can do more shit to in the future, in order to make gameplay more interesting. And what is it that we're working on? An exploration ship. (Hold your "REE WE'RE GONNA BE BAY!" shit for just ein moment.) The general gist off it is, that the NCV Aurora will be a smoll exploration ship accompanied by a few automated ships sponsored by multiple corporations. As noted, the minimum viable product is just a static ship, so it'll be much like the space station at first. But in the future, there will be plans. And actually, some of these plans have been manifesting right now, so there's a very high possibility that we'll launch with a fully "mobile" ship! In comparison to Bay, we're also looking to look more slick. Basically, our ship is to be more of a standard exploration/travel affair, whereas theirs is clearly a military one. If you want a point of comparison, think Andromeda vs Normandy from the Mass Effect series. But now, here's a short-list of features and key points planned (NOTE: these are subject to change, dropping, rework, and delay; SS13 is a game that's constantly being developed, so providing a definitive list is difficult?) Mobile ship mechanics. Ala Bay though we want to encourage more of the crew to get out there. The ship will be capable of landing, so there's a very high possibility of the entire crew being able to hop off to perform various duties, as opposed to having to use a shuttle. Though the exploration shuttle will still remain. No outright exploration department is planned, as we fear this would result in Just Them doing the exploration work, and gimping everyone else. Minimized NT-centrism. So as noted, the ship will be a part of a multi-corporation exploration effort. We will no longer have a situation where NT is the "default" faction for every role. Instead, presently as is planned, each department will have a different "Primary" corporation to play, with one or two others providing more flavour, as they currently do for NT. This will allow more roleplay avenues and create a more varied setting, hopefully. Security, cargo, and command are getting larger changes. Obviously the present command structure is not fit for a ship, so that's gonna be changed. I think at least 1 if not 2 roles are gonna be reworked-lost, with 1-2 new roles emerging from the restructure? Security will also be diddled, though not depsec, we are looking to minimizing their permanent contingent and seeing how well a crew militia can handle things on red alert. And finally, cargo's gonna be rebranded and given a few duties. Is the present plan, anyways. The ship can (probably) land at places! Okay, you know how, right now, we have these really world-changing events that SOMEHOW have to involve that one research station in the fuck-off middle of nowhere? And how it's kinda weird if you start thinking about it? Well, we had ideas where, for a specific event arc, we could permadock the ship at a given planet for the duration of the arc. It would give mappers more stuff to do, allow lore writers to perhaps write more natural event arcs, and provide the players with new settings to explore (possibly also new temporary characters to play as). Better departmental mapping. More specifically: a more open design to departments. Instead of blocking the section with department specific hallways, we're looking to make more areas publicly accessible. With only the specific working spaces being carded off. This should allow for more and better antag shenaniganry, among just also feeling gooder to play in. And now for the final answer. WHEN!? Well, my condition for writing this post was that we actually have some preproduction completed and are moving to putting in tangible work. Matt has been doing code work on this for a bit now, importing (or working on importing) Bay's overmap shenanigans and so forth. We already have dynamic map loading for away missions present as well. But this week, the mapping and design team created the first actual mock-up of the map and I think they're now transitioning to working on a prototype map. Which is, ayy, something tangible. But those specific details will be revealed when the mapping team is more comfortable with how it's all gonna play out, so right now, just take this concept art from Kyres:

Rubbers will solve nothing, lmao. This is one of those debates that resurfaces every now and then, with it sometimes going through. And then we watch the pendulum swing the other way again. Flash ammunition is a reasonable "solution", short of just removing the gun from them. With the only sticking point being whether or not we want to give them a unique caliber, to prevent a very rapid swap to lethals which would permit the detective to front-line.

Remember that the objectives don't necessarily need to track completion. But they do need to be creative.

HOKAY SO. Time to ruin a party a bit. I took about half an hour to write a short Python parser for the logs. And then I applied it to figure out how many antag lads we actually draft from the (completely unwilling) voters. The numbers will truly shock you! So. I took the rounds from 23MAR to 15APR (today). This is about 24 days, which coincides with the time when the PR was merged. In that time: A total of 215 rounds have been played. Out of those, 51 (23.7%) were extended rounds or (for some reason) included no antag drafting. Out of those 215 rounds, 63 rounds (29.3%) required a voter draft. Out of the 164 antag rounds, 38.4% of the rounds require a voter draft. In total, 259 voters were drafted, with an average of 4 drafted antags per round where they were required. So basically. There's about a slightly more than 1 in 3 chance of an antag round requiring a voter draft. Which is actually slightly more than I was expecting, I thought the number would be around 25% or 20%. But still, 38% isn't as high as I would have feared. But it is high enough for claims of degraded quality to have some statistical merit to them! Now for solutions. This is a very easy problem to solve. Apply age restrictions on most types of antags. Currently they're applied to only a few. This would be good, IMO. But brace yourself because 3 months later you're gonna have players complaining that antag objectives don't befit heavy roleplay and whatever the fuck. Technically incorrect. It was done to increase the variety of round types picked. ON THIS NOTE. Let's look at more data! Because I have data to prove that our plan succeeded, and the change has indeed increased the variety of game modes picked. What's more, it has allowed for more group antag modes to get selected. Ultimately, a positive move, in my perspective. The graph is a bit hazy but things to note: The reliance on autotraitor as the "go-to" round type has fallen by more than 5%. Group antag modes (cult, merc, heist, spy-v-spy, revolution) have all seen a non-marginal increase in the relative amount that they're played. Wizard and vampire (another two single antag type modes) have falled by non-marginal amounts. So basically. This goes to show that without forced drafts, our round type selection was heavily biased towards single antags. Which lowered overall gameplay variety, and, in my opinion, would leave larger rounds with quite "Meh" antags. So basically. Removing this change would be bad. Based on the data.

No dice, I'm afraid.

Soundcloud link doesn't work. Anyways, in general, I would love to see more sound effects. Having played/been involved with SS13 since uh, 2010, there is a very stark difference between the sound environment that we have now, and the one that we had even 6 years ago, where the only real "regular" sound effect was the background hum. Sounds add a lot. Also, I would suggest getting familiar with the DM sound API a little. Some modification, like interior-exterior-etc. version can already be done ingame. Obviously you won't have as much control, but depending on the size of the files, this might be better than uploading multiple versions. If the bloat the resource file too much, it gets tedious for players to download. Relevant DM doc: http://www.byond.com/docs/ref/#/sound/var/environment And please do be mindful of the licenses that the sounds you use are issued under. I'd prefer not to add to the list of potential copyright issues our repo's content may or may not have already. Otherwise, welcome, and feel free to tag us on #code_dungeon for help or questions or whatever!

This is an interesting concept and I would enjoy to see this more. Having more readily available means to combat the effectiveness of stuns sounds like a good idea.

If the issue is detectives acting like officers, or in general, being dumb with their weapons. Then consider removing the weapon entirely. Giving them a stun weapon lowers to penalty of using it even further, thus likely making them MORE inclined to use it.

psure @Cnaym already said he would.

\> 34 replies Well, this may have been a mistake. ANYWAYS. The way I'll organize this is I'll gather a list of participants from the list of lads who replied here and set up a doodle for them to vote on the best time. Once that's decided, I may or may not publish this date and time here for the rest of the gang to join. We'll see. Literally doesn't matter. Programming 101 is gonna be the same for the most part. Vars, functions, objects, inheritance, etcetera. Also, not sure about recording these. Would mean I'd need to set up recording, and then upload them, and then hnrg.

This isn't really for that. As I said in the OP, this is gonna be programming 101. Maybe only the final lecture or 2 is gonna be ss13 specific. The rest is basic programming using DM.

Time will be agreed upon between the participants and myself once I have a final list of participants.

I am horrible and do not have written material nor will I generate written material. I'll teach you how to use SOME written material. I might generate some examples or checkpoints of code, buuut that's gonna be it.

Okay so, short backstory. In my university, I've been teaching students since my first year there. The main field that I teach is robotics and embedded programming. PROBLEM: due to the copious amounts of Corona beer that have managed to infest the western world's water supply, university is CLOSED and so the courses I normally teach are on pause. (Can't really teach robotics without hardware hrhr.) So how about a short introductory series of DM coding? Format: About 2 - 4 academic lectures (90 minutes each). Shit to cover: Basics of programming (what's a function, what's a variable, how do I make things go zoom!) Note: THIS IS GOING TO BE THE VERY BASICS. Literally programming 101, the first two to three labs you'd have in uni. So if you already know the basics of general programming, not for you. But if you're foreign to the subject (like any HS graduate who enters uni would be), then this should be exactly for you. Basics of navigating SS13 shit-code. Basics of Git and contributing. Implementing a rainbow trout. The pace will likely be somewhat fast and I'll skip over 90% of the academia that I've thus far skipped over. The end result is that you'll have a fuzzy understanding of wtf programming is and maybe where to continue from in terms of implementing simple things. How's it all gonna happen? Organizational details: Well, Discord has video sharing. So we might as well use this. Willingness to chat on mic would be VERY NICE but I'm fine being the lone speaker as well. Class should be no larger than 10 people. Homework may or may not be assigned. Timezone is going to be comfortably European but still accessible to (East Coast) Americans. Exact time will be agreed upon once I have a finalized list of participants. Largest class size I'm comfortable instructing alone is like. 20 - 25. Though I will exercise my right to discretion as is necessary when selecting participants. If you're interested, leave a reply. If you have questions, leave a reply or hunt me down on Discord. I'm gonna fucking regret this probably! But who knows.

Some thoughts from the multitudes of discussions that have been discussed regarding security within the pits of the development dungeon and higher, amongst the head devs and head admins. First and foremost. Our goal isn't to remove sec. If we actually wanted to do this, we would, well, remove them. Simple enough point, ye? However. As I outlined in the dep sec feedback thread. Sec, as it currently stands, is getting in the way of future plans. So we are planning on reframing and reworking them. Unfortunately, out of the hyperbolic bullshit and screeching that I've heard and read, only a few people (Sue, Jackboot) have managed to see the core issue and phrase it properly. So to rephrase them, and to rephrase myself for the n-th time, there are two points: Sec (and the station at large) are a weeeee bit too powerful. No, I don't mean weapons wise. No, I don't mean equipment wise. I mean in terms of how easily they can assert control over most situations that are represent by the server's common antag types (specifically, single antags). While a full sec time is well balanced to go tango with a competent cult, merc team, or revs; against single antags, it becomes all too easy for them to envelop and hunt them down. This is confounded by the AI and a few other factors, of course. The Setting is a weeeeee bit too hostile to anything that is not clearly NT, and this gets (ab)used a lot. While I can easily cite player culture from 2013-2014 having been good sports about it, relying purely on player culture is a bit of a vain affair. So this, too, will have to be changed. Actually, back in uh. 2017? There was real-talk of making the station a more open trade hub. But for one reason or another, we decided to forego this change. Perhaps a mistake! Notice how addressing both of these two points doesn't require the outright removal of sec. Allow me to also address the why of the two previous points. As in, "Why are those two even a problem?" Well, because, as I explained either in the depsec thread or in security discord (or both, likely), the goal of the development team of this server is to provide varied and enjoyable roleplay experience. The way we do it is through antagonists, typically. (Necessary note: antagonist doesn't necessarily mean "Man with gun", we're slowly working on improving on this as well. Our analysis of OTHER avenues, along with observations of how similar avenues ended up being used on other servers, still determined sec or station side armed forces to be a large hinderance.) So what's the long term game plan? Weeeell. We're a bit up shit's creek with the setting deal. A bit. Redoing Aurora's setting currently seems like a very bad idea, since over the past month or two, we've got a lot of stuff necessary for NBTv2.(3) implemented. So I'd rather allocate whatever's necessary over there. This means that, hopefully as a worst case scenario, we're stuck on the Aurora until the end of the year. But we'll see. But how do we plan to address this with NBTv2.(3)? Well, whatever project ends up being implemented, it will no longer have the cold hard stamp of, "EVERYTHING HERE IS NT!" over it. It'll also have more lax security around it, and will be interfacing a lot more with outside forces-entities. If this can be successfully implemented alongside newer random events, which include docile visitors, we should hopefully see "random civilians" becoming more and more common aboard the station-ship-colony-secret thing. A side-note would be a question along the lines of, "But what IS NBTv2.(3)?!" Well, currently it is not the NBT that was originally rolled out in the thread about the NBT. But, being all too familiar with the 3 years it took for Nümap (Aurora's current map) to finally be made manifest in its present form, I'd rather leave a full description out of this until we actually start working on the map. Otherwise, God knowing, we'll find another reason to rethink our approach, and it'll just be announcement after announcement of, "Hey, we're doing this now instead!" But the general points of what I listed above will be implemented one way or another. Regardless of how we plan to manifest NBT, we've also thought about making the central areas of the station more open (originally Amory's suggestion). Specifically breaking up the clumping of departments, allowing more liberal traffic between areas. Command structure (and departmental allocation) is another target for fuckery, regardless of what NBT ends up being, which would allows us to distribute and manage security resources in a bit of a different manner. But that's all in The Future. What about The Now? First I will say, both the depsec test merge, the feedback from it, and the reactions to the second iteration have proven invaluable in molding the future designs of any NBT. We saw what it solved and what it didn't. Both are important. As for what we do with this now, well, I don't (personally) fully know. Depsec is a compromise in all meanings of the word. Whether that's a good thing, well, we'll find out I suppose.

As I stated. Persisting state across rounds is not ideal. And touching job selection code is eough.

Dupe of With my answer linked as well.

Note regarding anyone crying "BIAS!" towards systems that involve randomness. There is a horrible human fallacy to believe that "random" means "without logical sequences". The only meaningful way to evaluate the presence of a bias in any pseudorandom system is to do so over a very large sample size. And I do mean very large. True randomness (and thus, good pseudorandomness) is very likely to produce sequential output when observed over a small sample size. Also, it is not as easy as you think it is to maintain state across rounds. Modifying the job selection code is also another form of ass. So hnrg. In the job selection code, randomness is introduced in two places. First, the job list is shuffled. So we assign people to jobs at random points. Priority is used here, with high priority picks being picked first. The second point is that the "unassigned" list of players is also shuffled before touching it. So while job selection is, "Go down this list of unassigned players, find the first player who has it set at a given priority, and assign them," which would be a deterministic under specific scenarios, shuffling of the unassigned list removes this. So the whole process is indeed random. What would be interesting to consider, though, would be to remove the priorities. ? Priorities are the most deterministic aspect of this process, and will have a noticeable effect. But this will also remove control from da players.

Okay lads and ladderinos. Let's take a step back and a moment to think about this. First, allow me to establish what it is that we're trying to achieve here and why. A lot of these changes are aimed at outright reducing the amount of effective control the security department is able to exert over the station. This is a necessary since, as has been proven time and time again with events, gameplay additions, etcetera. Any outside entity that is introduced into the round will be put under immediate scrutiny by security, and will effectively be restrained or otherwise controlled by security. While yes, "Realistically" this is fine. From a gameplay development perspective, this is absolutely limiting. We are rendered with the choice of either accepting that, "Yup, sec will keep these guys on a short leash, so anything interesting is gonna get shut out," or making the outside force large enough to be able to outplay sec (which, at present, is at most a 10 man team and that's asking for a lot of trouble). There is something to be said about not making these matters "security centric". However, special events in the past have demonstrated that security has a knack for butting in on matters which should primarily involve science, medical, etcetera. Which sorta makes sense, since security's job is to control whatever is underway on the station. But again, this is troubling from a gameplay perspective. Granted, security isn't the only actor here responsible for the balance upset here, and we have Other Things:tm: planned for the other actors, like the AI. But, this is about security; just don't come running to me with the argument of "BUT WHAT ABOUT X!" as some of you have been doing on Discord. With this said, let us gauge what effect DepSec, as previously tested, had on security. We got security officers with extended access in all departments, still adherent to the Head of Security and thus a part of the cohesive security team. The practical effects of this was the reduction response time for security to departments. Which meant less need for them to adhere to warrants, and an easier time all around getting to places. (This also nullified our maintenance access changes! Which were positively received by a majority crowd.) If we compare this to the goals established above, then it should be clear that we did not move towards the established goals at all. If anything, we simply extended security's reach. So, the foot goes down on the fact that DepSec, as tested, will not be merged. Due to the fact that it does not satisfy the requirements set out for it. The matter of the changes as previously tested not satisfying our goals is backed up by the questionnaire and its output. This is where the proposed tweaks come in. Removal of the departmental officers from the cohesive security department until code blue (at which point the threat the station poses to its opponents should increase anyways) was deemed as the acceptable path to walk down. As already noted multiple times, the most effective way to do this is to make the departmental officers primarily subordinate to their head of staff, and to remove the security radio from them. While yes, as I've stated both on Discord and here, this is a "severe" measure, it is also the one that's most likely to get us to where we want to be. The proposed changes would remove the departmental officers from the easy-to-deploy security response force on code green, and would effectively force them to focus on securing their own department. This reduces security's tactical presence in the round and thus helps us move towards the goals outlined in the beginning. The alternative to these specific alterations is to implement DepSec with severe access restrictions. Basically just give them main departmental hallway access and drop the other changes. However, again, if we look at the "What and why" portion of this post, you'll quickly see that this alternative doesn't really further any of those goals. All it does is give security access to departmental hallways. That is it. While less egregious than the previous test merge, it is still not a solution good enough to accomplish what is required. There exist other ways to skin this cat as well, obviously. And something from this hat is being considered for NBT. However, without completely uplifting Aurora's current command structure, implementing those changes is difficult. The only other alternative solution that I'm currently aware of is to directly nerf the number of security team members that are on the station. Remove 2 officers and 1 cadet, say. This should lower the effectiveness of the security team enough to serve our goals. We are open to further suggestions, but in proposing them, you must keep in the overarching goals. Some of the proposals that I've heard thus far sorely miss the point, and they mainly do so out of ignorance.

We likely won't go for another test merge. Purely because long-haul test merges are assenine in terms of keeping the server up to date during them. As said, the decision is to be re-evaluated following launch, so we'll see. Well, you see. The stats say otherwise. As does enough anecdotal evidence which has reached me and the rest. And if we want to discuss representation of the numbers, this is 10% of the monthly unique player base that has spoken. Which is a pretty good representation as far as our polls go.

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.