Skull132

Counter problem. In doing so you basically lock dead hour down to only being wizard or traitor, with no other alternative. Which is going to most likely be more harmful towards gameplay than the issues currently present.

To be honest, I'm not opposed to this because the presence of shoes as a requirement is already little more than just an annoyance. Specifically removing shoes with the knowledge that they can't cast spells if they're lacking those is meta and if they're stripped they're probably getting their robes removed, which is a much more clear thing. So uh, I think this is inconsequential and can be merged on the grounds that it'll just remove a source of potential annoyance. EDIT: Ninja'd by Arrow, but my opinion still stands.

Merged into deveopment, live in November.

During the 6 days of testing, the server did not crash once. This is a strong indicator of the fact that removal of Z-levels can alleviate the issue. For the initial test, the derelict was removed alongside the roof. For the next week, we are removing just the derelict. This is us now gathering data and attempting to narrow down the issue, really: whether it's just generic Z-levels which caused the issue, or if we're stuck with having to explicitly remove the roof, due to something there.

Solars and other minor things. They'll all be either removed if irrelevant, or moved (probably) down.

In an attempt to narrow down the crashing, or to see what helps and what doesn't, we are going to be removing the very top Z-level. This should alleviate the amount of memory the game uses, first and foremost. The added benefit should be that ZAS will get a bit snappier, since it has less turfs to process. Note: by "the very top Z-level", we mean the roof. The thing which is above arrivals. The experiment will be ran for a week at most, starting tomorrow, 02OCT2018. We apologize for the inconvenience. UPDATE, 07OCT2018: During the 6 days of testing, the server did not crash once. This is a strong indicator of the fact that removal of Z-levels can alleviate the issue. For the initial test, the derelict was removed alongside the roof. For the next week, we are removing just the derelict. This is us now gathering data and attempting to narrow down the issue, really: whether it's just generic Z-levels which caused the issue, or if we're stuck with having to explicitly remove the roof, due to something there.

My main concern with this is. Are we slowly drifting towards a stats management game with this? A concept shared by the Sims series, most notably. What I would like to ask besides that, is there actual gameplay value within this mechanic? Because a mechanic that exists just to be monitored, arguably, has little gameplay worth unless the aim of the game is to monitor those stats. IMO space station is about focusing on matters that are external: the environment and the people around you. Drawing the focus too much on having to monitor your own stats would be somewhat counter intuitive to what we have been doing for the past half a decade.

Well, if you look at the mechanics list. A lot of these work as standalone mechanics. We'd primarily lose out on the persistence mechanics. The antag, construction, terrain generators can all remain even if we go back to a static deal.

1: Arrow's currently working on it. Too early to tell, though, so stay tuned. 2: Z-levels will more than likely be a thing. How many vertical and how many side-ways ones we'll have is to be determined. Though technically, with the current plans for terrain generation, we can just pick an arbitrary combination as long as we remain at roughly the same number of Zs we have now. 3: Antagonism specifics are a major question atm. The idea of antag base building was discussed, but not decision has yet been made. The features in question aren't currently slated for the first round of work. 4: Most likely yes. There is no present reason to strip or even modify them.

Loadsa questions. I condensed them a bit. 1: The splitting up into a ship and colony isn't set in stone. We're painfully aware of the current issue with the map being too large, and are intent on avoiding that. It might be that the ship, or whatever mother base, will simply be a way station you occasionally interact with or go to. 2: The reset was a part of the initial write-up. Which included and entire super-loop of gameplay around colonizing multiple worlds, with a player controlled mother ship. However. This is too audacious of an initial implementation goal, and will strike the problems I already outlined in point 1. As such, it is partly a remnant of that idea. However, it would also allow us to, while maintaining consistency and lore, to more regularly change mechanics and to explore new things, both in terms of gameplay a lore. The latter reasons is now largely why it's there. The duration of 1 month is up for discussion and review. 3: The persistence of antagonist actions is currently being decided. There's a certain charm to it, in that, it would allow you to do even minor sabotage with actual consequences way down the line. But we also definitely see that it's a potential cause for grief, annoyance/fatigue, etcetera to the playerbase. And we will definitely keep that in mind in whatever decision we make. 4: As for removing the focus away from the antags. I would argue that we are not. The most likely outcome is that antagonists will remain as they are. An alternative is that they get augmented with the persistence hit. They're also slated to become more varied. With us no longer representing a hidden science station, we can do shit like implemented player refugees, vox traders/voyagers, whatever else as "antagonist". And it would bring more variety to the game. 5: Building speed is to be determined by the construction mechanics overhaul, that Moondancer is heading. Expect more details on that soon:tm:. 6: Can't really say at the moment!

Realistically, we're not removing anything that'd undermine the other departments. There will still be antags for security; there will still be injured folks for medical; science can benefit from this change, as we can more easily and in a more regular fashion introduce new excotic things. We are definitely going to have an "initial base" that other departments can use just fine. And once construction reaches a certain point, life should be able to go on as normal anyways. Also yes and no. Tbh a good few us aren't even too much up to speed on what Persistence does exactly, or how. Even if our feature list ends up being similar, we will almost certainly provide a different gameplay experience and environment. This is how we became larger than Bay for a good 2 - 3 years, after all.

I got to agree with you on that. It seems to raise the bar on who is around though, and how harsh the problem makers are dealt with. Because shit doesn't reset, you're effectively fucking everyone over. Security and gameplay experience are a major consideration, I assure you. The persistent mechanic will definitely have back-ups and easy roll-back, to deal with grief, shitty players, etcetera. As also noted, we're making construction mechanics produce a more uniform result. Though we're still making sure that the players have enough engagement to be gotten out of the system. Also, the exact level of how much is to be saved is to be determined over the next few weeks, and will definitely be adjust as the need arises. We might just respawn the super structure, for example. Or get a bit more in depth.

Would you be able to elaborate further as to why?

Well, the current mechanics will still persist for a good long while. Like at least 9 months. Also, rounds will still exist. Because we need them for purely technical reasons. So that 10 different things thing will still be around, as you can swap characters, do different things, etcetera.

INFORMATION IN THIS THREAD IS OUTDATED. Go here for new information. First, allow me to preface this with our reasoning behind all of what you're about to read. To effectively answer the question of, " " The basic formula of SS13, as it exists on our server, has existed for over a decade now. Aurora itself is half a decade old, and has been running the same general flow for all of it. So one of the purposes of this project is to effectively step away from that formula and to try something new, while maintaining the general goals Aurora has: to provide an engaging roleplay experience within the framework of SS13. The other reason for this project is tied roughly to that last note. Over the past three or so years, SS13 has evolved from a 2d farting simulator to, effectively, become a framework for games. A lot of variety servers have popped up, and keep popping up. So, it's not a bad idea to consider doing something unique of our own, is my thought. Further, allow me to elaborate where we are right now. And to give you an idea of the pace this project is meant to have. The project itself is relatively large in terms of the back-end infrastructure it requires. At present, we have decided upon and set in stone what final systems are going to be present in the initial release of this project. Along with key capabilities of said systems. However, anything beyond that is to be determined by individual development groups, as they establish roadmaps for those sub projects. Further, any lore, any specific details, etcetera, is currently largely irrelevant and undecided upon. The core systems must be in place first, and in doing so, we will slowly flesh out the final product as we go. That should be sufficient background information and understanding, I hope. So allow me to reveal what the actual project and its end goals are. So essentially, we are looking to generate a more dynamic, evolving environment for gameplay. With the environment itself refreshing semi-regularly, allowing us to more easily introduce new quirks and to do things which would otherwise break the setting or environment or something as static as the current station. It'll also allow us to perhaps stray towards and explore a few potentially more extreme scenarios, which we've had to stay away from with the station. And in general, we expect it to produce an interesting twist on the old 2d farting simulator. To reach this goal, here's a list of mechanics currently slated for being a requirement upon initial release, along with a short description: Construction overhaul - since construction is going to be a large part of the deal, it needs to be looked over and made more consistent and perhaps more in-depth. Could consider things like integrating circuitry into mechanics, to allow people to unleash their factorio nerd. Saving/loading, with rollback. Needs to keep back-ups, have an admin interface, etcetera. (Maybe add ability to selectively roll back selected map parts) Persistent economy and supply chain. The crew needs to be able to manage its funds so it could order things and resources from outside. Allow the HoP to change the number of open job-slots Allow them to mark certain jobs as “Priority” Starting colony. The starting colony is a must and the colony itself should be a focus of the round. Ergo, drop the ship and minimize the station. The starting colony itself should contain a minimal functioning setup of each department. The colony should be pieced together from random/procedural chunks, minus the starting colony. Along with the surrounding Z-levels. Power needs review. PACMAN is a good starter energy source, but the reactors need review and updating. Antagonists need review. Consider implementing them into the round as random events. Let the players vote on the “intensity” of a round. A few FAQs which have come up as we've discussed this amongst staff: What's the lore here? - Also currently WIP. With many potential scenarios to unfold. Will I have to make a new character? Or a new character every month? - No. We will look into making the transition smooth. And no to the second one as well, imagine the group of people as a group of explorers or path finders. Who go to a new planet, set up things, and then move on. WhEn'S dA ReLeAsE? (What's the plan?) - Currently we're assembling development teams and producing roadmaps for the first batch of features. Specifically, the saving back-end, construction overhaul, economy, and map generation are currently being worked on. Then we'll do those mechanics, and then we'll repeat the process for the rest. So uh, this is a bit of a ways out. Expect a comfortable time frame of 9 - 12 months before release anyways. What will happen to the lore? - It'll be as it is now. We'll just move to exploring a different aspect of it. Also, lore details are still waaay far out. Will we still be NT? - NT will definitely play a role in the new setting, but there's currently discussion about introducing other factions as well. For more variety and potential for internal strife. so uh. ye. what think.

For reference. Minimal access is set to false already. The option is as good as deprecated on our server.

Ye I'll just add my vote of "-1, please let us not do this ever." This would introduce a whole level of taboo that we do not want to even consider dealing with, first and foremost. It would also introduce a really fucking weird roleplay dynamic, and potentially create a situation where we have to actively weed out legitimately harmful people. So, no. Absolutely not up for dealing with this.

Hello! A short background spiel: over the past some months now, my activity has been at a relatively low level, in comparison to the past. And to fill this void, Arrow has been taking up a lot of initiative in organizing development both internally, and managing policy and relations externally. So, this weekend, we have decided to officially recognize this continued effort and promote Arrow to the role of Head Developer! This means that he has the same authority (including administrative authority if need be) and permissions as I do. In lieu of this promotion, I will be staying as well. So, much like the role of Head Administrator, the role of Head Developer will now be shared by two people. This minimizes the bus factor and gives us both some breathing room to take care of life and other things in a fashion where the community will still keep running just fine. So, to a healthy Aurora and to Arrow, for a well earned promotion!

That's a relatively simple point to answer! If no change is outlined, then the already existing restrictions and liberties apply. This is to say, that these alert level notifications affect only how security can carry and use weaponry. All other components adhere to whatever regulation they adhere to already, unchanged. Which is sort of wise, IMO: no one but security should have the necessity to brandish weapons outside of instances of imminent danger. Now, this might be a point for considering what those other regulations are. And how weapons carrying is regulated by CorpRegs and Station Directives. But if those clearly mandate a certain arrangement, then that arrangement is to be followed, by non-security staff, regardless of alert level.

Just to point out a few things. First, this here: This is patently false. All fixes that affect gameplay or are visible, including this one, are required to include with them a changelog. This changelog is clearly visible every time you log into the game, and even highlighted at two different places to grab your attention (greeting window and the button itself). Herein comes the crux of the matter: much like developers are required to log their changes, the playerbase is required to consult the changelog for new gameplay tweaks. The changelog is the central system that the developers use to notify the playerbase of any change that is visible to the player, and done via updating the code. From there, the player is free to trawl around github or the suggestions/projects forums looking for specifics, or to consult a dev. As for the courtesy of the "copy paste post". No, this is not a courtesy, it is courtesy for you to follow the links attached to certain feedback and project posts in an effort to immerse yourself in the two discussions that have taken place. It is courtesy for us to put those links up and to ensure that every gameplay altering item ends up clearly logged in the changelog. As Fowl very astutely pointed out in his original post, this is a two way road. As far as comparisons go, even among SS13 communities, we have one of the more publicly integrated development processes. Taking it any further would not benefit much, and would demand more effort than it could potentially be worth.

A lot has already been said. So I am going to simply reinforce some of the points. First, note that the dungeons PR was effectively gutted to a framework PR as a result of considerations over the matter. Even the changelog says as much: "Implements a framework for random dungeons." Useful code is, well, useful. (And note that we are not obligated to even log framework and code structure changes, but Burger decided to do so anyways.) Granted, Alberyk did later on implement his own dungeons, which are now live, but I've yet to see a full feedback topic about that: Alberyk's PR is August update, your thread stops before the June update. There's a few other PRs that were gutted or heavily reworked based on our general gameplay direction and community feedback, but uh, I forget them. Well, if you want to go ages back, then hunger memes as well. As for lore. When it comes to lore related changes, the only thing the development staff takes responsibility for is preserving the general balance of gameplay and quality of code. While I understand that this sounds like a ring-around-the-rosie type of point to make, it's worth making to maintain the cooperation between departments. How lore comes up with their changes, presents them, and reviews them is up to them. So you might want to direct this criticism at [mention]Senpai Jackboot[/mention]. The zoda is subject to post-release tweaking and review. This has already partly taken place, with Paradox possibly working on further further improvements for next release. This is literally how the game goes: the effect of certain PRs is impossible to gauge until they hit the floor. And once they do hit the floor, tweaks and changes are made. I will leave without comment the mentions of PRs still under review. Since we are always running a backlog of PRs to review, we cannot possibly say our opinions on every PR the moment they land. Ultimately, though, I would like to note that most cases of negative feedback on a feature are recognize at some point down the line and fixed. Whether it's before, or after, is arbitrary. As already noted, the effect of every PR cannot be predicted an even if you can say, "I knew this would end badly!" there are cases where we would still like to try. Some of those cases end with the prediction being false, folks getting used to the new mechanics, and life carrying on as normal. Other times, we simply revert it. That's how life goes.

I don't really understand why or how powergaming entered the debate here. The rules are purely IC, roleplay driven. As already pointed out by folks here, an unsecured or openly carried (such as a rifle affixed to the chest piece) weapon generates discomfort and distress. A holster, while yes, visible, is degrees different from someone having a weapon haphazardly looped through their belt. There's also the matter that holsters are usually secured against involuntary access (also an IC consideration). It is literally horrible weapon safety to have a weapon looped through your belt as a Captain. Your proposition would not address the following points: Weapons affixed to chest (carbines and ions are non-lethal). "Lethal arms are forbidden" is not currently a thing, and making it a thing would be bad. For example a carp situation. "Restricted" is horribly vague and unenforceable as a result. "Lethals allowed" is also horribly vague and unenforceable. And for the sake of completeness, here are the current alert level notifications: Green: All threats to the station have passed. Security may not have weapons visible, privacy laws are once again fully enforced. Blue: The station has received reliable information about possible hostile activity on the station. Security staff may have weapons visible, random searches are permitted. Red: There is an immediate serious threat to the station. Security may have weapons unholstered at all times. Random searches are allowed and advised. Notice how it concretely and clearly regulates two parameters: Weapon visibility, whether or not, for example, a rifle can be carried on the back or affixed to the chest; and weapon brandishing. I was going to complain about the lack of concrete solution proposed by this post in the morning, but then I saw your concrete solution, and now I'm inclined to say that it suffers from tunnel vision.

Ban lifted. Don't disappoint us.

The carry rules have nothing to do with laws. It's internal policy. A weapon on code green should be secured in a holster as to not create alarm or distress in staff. Note that the policy also has an effect on how openly you can brandish the weapon: on code green, it should only be brandished when it is immediately necessary; on code red, you can openly patrol with the weapon in hand. So it has a way greater effect outside of the dilemma of, "Can I wear it on the belt or not."

Applicant didn't have time, and elected to withdraw their application. Locking and archiving.