kyres1

I don't know, it's two articles in. It seems unfair to judge it so fast from this kind of perspective I do intend to capitalize on the things the scarcity was meant to give us. Making it scarce made our setting(s) more important as they generally revolved around the acquisition of phoron. It was and still is the easiest justification with the most possibilities for what our setting is. By capitalizing on it we lose nothing and just gain an even more grounded angle to direct the story, since like above, a direction helps things write themselves. This means that lingering questions like Elyra's capacity to withhold galactic phoron reserves, the Aurora II's presence in lore, and what Orchard Moon really is, are things I want to answer myself. "Insufferable to a character" is literal. The question is whether or not it changes anything for things to be "morally grey" or mixed-in with grim aspects as a matter of balance. I responded by clarifying that this sort of stuff just makes things boring. Dominian nobles exemplify this by being a type of character that has a good position in life and some substantial clout by most metrics. This is as opposed to say, an Eridanian dreg, who is obviously not going to have a fun time being alive in this universe. Both are popular angles and very free-form, but neither are grey whatsoever. The question of morality, or quality of life for that matter, is not even regarded, hence the response. I always get lost in having to elaborate on this specific point. I would definitely say it is a tired point of contention in 2023. I do absolutely want a planet freeze. I wanted a planet freeze four years ago. Myself and Mofo even enforced one for some time. This is not a secret of mine. However, this is one of those cases where things are just too far gone to retract so suddenly. Because of that, I really need to emphasize that I need to re-integrate with the team and talk at length before slowing or halting anything. To clarify the specific questions here; I am a fan of Konyang as it exemplifies an origin that is intricate, highly developed, and reaches into plenty of character concepts by virtue of being so important to such a large part of our server; being synthetics, machines and IPCs etc. It capitalizes on this with a definitive culture, a myriad of inspirations, and being among the longest (if not the longest) planet page on the wiki. I do not find many other planets (I can count the others on one hand) that have gone to lengths to integrate with lore enough to justify having as much content as this planet has. Not to mention, huge efforts have been made for years to involve and work with Konyang as a centerpiece of a species team; similarly to Adhomai, it's inadvertently stacked wide as a bastion for species development. There is however a difference between stacking tall and stacking wide in this context. Effectively, Konyang's content would be meaningless were it confined to Konyang and affected nothing beyond its page. To follow on that though, I don't think every planet should be like Konyang or Adhomai. The amount of these can only be small because special factors make these locations important and worthwhile. This is a matter of fact, because at the end of the day, these are not in a vacuum. They are in a living universe we strive to develop every day. The universe can't consist of fifty novel-length planetary origins of varying importance; some priority has to be set in terms of what players should care about, or players won't feel the need to care about anything at all. To overly simplify this, a multitude of reasons leads anyone to the basic conclusion that we do not need thousands of unique excerpts of individual origins. To this day I still don't hear any argument to the contrary. The above is only a tiny portion of a lengthy rant I could go on against the efficacy of fluff, anyway. I want Biesel to keep being our setting's heart. It lets us project the power of the corporations more easily and fall back to a familiar government entity when we need it. It also remains at extreme odds with Sol historically, and the butting of their heads is a major point in our story. It goes up, or it doesn't budge. That's my feeling. For the next question, I would sooner step on a lego than rework/retcon anything about Biesel. For the SCC/Republic lore being intertwined, yes this is kind of a given. I don't think they're as intertwined as they could be in WRITING, but historically the Republic is a foremost playground/ideal of the corporate throne. If Eridani is everything bad about the corporations exemplified, Biesel is the opposite. It always has been, and there's a reason it's not painted as some decrepit backwater. Capitalizing more and more on the imposing presence of the Conglomerate and the Republic is important in giving the players agency and a feeling of freedom on the Horizon. If not for freedom and participation with exploration, we moved to the ship for nothing.

In case it was misread, what I said before was my intention as well. I want Sol to keep itself active, at least in its immediately relevant affairs (like the wildlands) but share its spotlight with other factions that are relatively unseen by comparison. It's been a very, very very long time since a species arc that wasn't Human or Tajaran took the "spotlight." The most recent I can possibly imagine is Warbling and just before, the SLF arc. Otherwise, four of our playable species are mostly nonpresent in terms of things that draw the server's focus, such as event arcs. To say the least, putting one of our core and most apparent factions on any backburner for something that historically doesn't happen is shooting us in the foot. Do I think species devs can contribute otherwise? Yes. KOTW was hugely powered with the help of species devs chipping in on all fronts. I however would not bank something so essential for less likely things like species-centric arcs to take the forefront. To beat a horse that has been dead and still beaten for probably close to half a decade now, I think origins are incredibly, incredibly, incredibly saturated. Even discounting some obvious numbers like the sheer volume of planet pages, we're already spreading a very critically character-starved setting with a peculiar focus on expanding this even more. To this day I'm probably not going to get an answer as to why things are added - instead simply because a writer wanted it. That logic should not need explanation as to why it is harmful moving forward. I don't think I ever plot to support the "fluffing" of things again, personally. I however don't intend to even think about enforcing this without major sit-downs and talking with a lot of people first. It can't be avoided, honestly. A huge draw to Sol is familiarity and simplicity. Playing an Earth Solarian military veteran is, in every way, just Biesel but simpler. Swaths of lore need not exist and a huge portion can simply be swept aside with a character's mere disdain towards other nationalities or species. To boot, being inflammatory ICly and "causing conflict" is often something that is seen as hip to pursue, for better or worse. So, like before, a strident effort to really combat "John Sol" is a waste of time and probably harmful to anyone who works towards it. Not immediately. There is still an utterly gargantuan amount of writing in the San Colette arc that I probably need to familiarize myself with before I scrutinize things. Corporate lore and fitting us proper for Konyang is something far more pertinent right now anyway.

Yes, and no. I think that going for a morally grey angle can be interesting, but oftentimes in storytelling not everything can be so mysterious when it comes to people's agendas. Essentially, whenever we run an espionage arc, the spy is answering to a big bad boss, right? Well, that big bad boss can't just act in a completely dubious and unpredictable way - the writers, host, and person playing the character needs to know how both of these characters act. The dilemma of morality between the characters, from our perspective, doesn't exist at that level. What is seen is their actions and reactions to their surroundings, and they organically react to the surrounding stimuli. Like a character in a roleplaying context would! Factions should be no different. I think agenda, action and reaction should be considered at every echelon of writing these things. It makes it a far more complex, but easier to consume story for everyone. It's more complex because people can interpret separately while ultimately within the boundaries of seeing how or what a faction entails. The hatred of synthetics in the context of Dominia is something that characterizes far more than just "I hate robots." It tells you a lot of inherent story beats of a character just by reading it. For example, you can assume they're raised skeptic of more than simply robots; they might be fiercely traditional and adopt more nuance from a space-feudal society like it. This singular gimmick can evolve into a lot more than whatever a ton of pre-written involvement could. To simplify all that, remember a very key point; the lore is the rules. That means the more rules there are, the less fun things get. Obviously. Because you can't change the rules, right? It only makes sense that, the more specific things get, the narrower your creative options become. So, tl;dr, no I think writing absolutes as behavior or involvement for any faction should be minimized, not expanded upon. Cause/effect events (visible ingame or otherwise) that transpire are much better at illustrating the intermingling of factions than any mountain of written knowledge ever could.

You aren't entirely off the mark, but I am a very firm believer that this is not intentional on part of the writers. I find myself critical of the handling of Sol at points, but I think any of the centralization of player focus is generated purely by factors out of the writer's control. As it stands, I think that one way or the other, Sol should be doing something. This has been the case since KOTW concluded and human writers have been plenty hard at work ensuring this. An unintended byproduct of tending to Sol is that Sol receives attention, much like any other faction at any given point when it gets developed; however, Sol has since day one been a very big "carry-over" from the development of Bay. While our Sol is extremely unique and different, the immediate attachment that migrating players feel towards it is very apparent. On top of this, Sol in general is an appealing background for a variety of simplistic backstories, both for antagonists and characters alike. Mix all that together with the ability to play army man, and you have a very simple reason that we continue to see an overwhelming saturation of Solarian content for better or worse. None of these factors are, as I said before, in the ballpark of the Human team's responsibility. Unless they dismantle the concept of the Sol Alliance from the ground-up, not much can be changed about an imperialistic Earth-leaning super-empire without betraying those themes to begin with. To say the least, I hate going back on old work, and I would doubly hate to deconstruct that monolithic appeal Sol has. All that leads to me saying this; Sol is as core to our setting as Biesel is. If it was left stagnant, there'd be even more confusion and upset. I think, however, it is possible to affect Sol without actively making it a centerpiece. To that extent, my best idea is to do literally anything else with the universe outside of it; especially the region we're in and scheduled to arrive in. After that, I guess things become simpler. The "cartoon villain" aspect is something I basically gave up fighting as an argument a while ago. I do not think building the Solarian Restoration Front as zealous nationalistic fascists with a penchant for xenophobia was at all a good angle to pursue. The implications of this, among the extreme decision-making of other higher stellar powers (such as Elyra barring phoron from the galaxy), are things I plan to work on in stride as a result. I really don't care about "leveling" this, and here's why. From the perspective of a player, one is not more or less enticed to read the lore of a faction or story because it is simply more miserable ICly. I'd argue that, given our disproportionate amount of Dominian nobles and super-rich upper-class, it's actually a downside to make something completely insufferable to a character. This isn't to say things can entice the character to leave and pursue employment on the Horizon as a result; but this is no longer the Aurora. The bar of entry is no longer simply "I was a criminal and escaped my former life," but a tad more specific and upstanding. From the perspective of a writer, and speaking from personal experience having dealt with it for years, stacking up the good-bad points of a faction and trying to hit a competitive score against others is like signing up to write NationStates fanfiction. There is, at that point, no more "lore writer." It's not lore anymore. It's a fan fiction. I wholeheartedly do not think things must compete with one another in terms of OOC appeal and vice versa as a result. That said, all of that can be solved with the magic wand of "giving things direction." Once you wave it, people stop acting in a vacuum and ways to move forward (see : writing lore) become obvious. Making something more or less dreary to even out the galactic karma rating is only indicative of a direction just not existing to begin with. I hope all this answers the questions fully. It's easy for me to run on about these subjects, so let me know if I missed anything.

Ckey/BYOND Username: kyres1 Discord Name: noodle_buster Position Being Applied For: Deputy Loremaster Past Experiences/Knowledge: A very long tenure as deputy loremaster, synthdev, synth deputy, and spriter. I've been staff consistently since 2017. Examples of Past Work: Hard to estimate what would be relevant here. For the position, I would say my biggest reference would be coordinating/hosting KING OF THE WORLD start to finish, being responsible for proposing the current setting (NBT), and solidifying a lot of very important themes in our setting. I also restructured a lot of the new player experience by changing the main pages for the wiki and writing a lot of the starting guides, as well as the assets for them ground-up. Additional Comments: I have no intention to lessen my spriter obligations. Right now, my obligations are slim, and while the projects I aim to tackle are really vast, only 2 of them have my mandatory participation. Those being the development of Konyang dev-side and an obligation for another dev's WIP project. Otherwise, I am in a much more available place than I was when I was initially deputy LM. It might be an immediate question to ask; "But Kyres, didn't you just resign from deputy LM?" in which I would say, it's been over a year. I resigned knowing I wouldn't be able to contribute for a very long period of time, something I think every staff member should do if they opt to go inactive for extended periods. As I had expected, I was unable to do much for the following months - I would've been slot sitting, so I left as soon as I saw my inability to contribute would become a problem soon. Furthermore, I love the work. I love it so much in fact that I have spent the overwhelming majority of my free time since 2017 contributing and enjoying the work as a player and staff. I'll never say never to these positions as they open, and I am confident that very few people of my experience in the community are left to take these roles. It's less that I feel obligated to apply, and more that I feel gratified to just be making things better. As a wise man here once said, this place is a project that never gets finished - and that's the best part. 1. Do you have any experience managing a Team? The duties of a Deputy Loremaster often revolve around being a Project Lead, not necessarily just writing. 2. In a brief summary, explain the direction you'd wish to see the Lore Team take in regards to Aurora Lore. 3. If you were selected, what do you believe should be changed about how the Lore Team operates?

I latejoined so my character didn't have any context as to what the antagonists were. So, my character, upon learning they were magical time travelers, lied and said she had drinks to deliver to the conference room to take a look. They ended up being a bunch of fully armed Solarians, hence her walking out immediately. My involvement basically begins and ends there. After that I sat around doing other things and eventually left the round just before it ended.

This is a beginner contributor and code-illiterate guide to adding map content to Aurora. This mainly focuses on overmap sites and ships, but lots can cross over between other ways to contribute. To start off, no coding experience is required to use git as our server's contributors can. Virtually anybody regardless of software literacy can contribute as a result. This guide will cover how to set up the most basic method of using a Git client, how to keep it updated easily, what you need to map, and how to make a pull request to submit it all. Before you do anything at a level like this, first get your tools together. These tools are not all mandatory but will make life magnitudes easier for you. Fork - A git client that is free and simple. This guide uses this client, but many others are like it. Many others also cost extortionate amounts of money, so this is a good pick. Microsoft VSC (visual studio code) - Another method of editing the code you will need to adjust to make things work. This has an inbuilt debugging feature that speeds up your work massively. It also lets you search the entire code instantly which will become utterly invaluable when you need to look at something else for reference. You should download a Dreammaker extension for this once you get the opportunity, it’ll help you get accustomed to things faster. StrongDMM - The only mapping editor you should be using. If you edit maps using dream make instead, expect your work to be slow and for easily-avoided problems to appear. Explaining the Process for Dummies Once you have everything together, the rest of the set-up is a mostly one time process. After this guide, updating your code is reduced to a single button press, and keeping track of things is simple. The next steps will explain how to get there. To make things understandable, "repo" implies repository, or a specific folder or collection that you update in parts. So, the "Aurora repo" would be our primary public code that contains the game's data. Your work process as a contributor, even at most higher levels of coding, is basically entirely merging your own changes with the "master" branch, AKA the branch the server runs the game on. To do this, you basically make changes on your LOCAL repo (your PC or workstation), send those changes to your "remote" (an Aurora repo cloned to your account on Github), and you can then easily compare the changes; after which you can open a PR to submit your changes for review. Getting started First thing's first, make a Github account to push your changes under. After that, you'll need to make your own "workspace" where you can send your changes to Github before trying to merge it with the main code. This is the "remote" as said above. To get your remote, you need to clone the Aurora code into your own copy. Hitting “Fork” in the top right of the repository will clone it under your account, which is where all changes you make will be pushed to when you commit local changes to the remote. Downloading and installing the code The next important step is to get this new workspace on your PC. Like said above, you’ll clone your repository now; to do this, open Fork (the Git program you’re using) and press the “clone” button at the top left. Copy and paste the URL of your new fork on Github into the relevant field when cloning to download your custom fork to your PC. This will probably take a while. When your client is ready to go completely, things will look like this: Once things are like the above, and you check out (AKA select) the “master” branch, proceed to the next page. Using Fork - important basics To start almost any project you’ll begin here, you want to start with two essentials; For one, update your “master” branch so you don’t end up with avoidable conflicts immediately. Doing this is, in this context, accomplished by “fast-forwarding” your master branch to the latest version. Always fast-forward once you see a “X commits behind” symbolized like below next to your “master” branch. Simply right-click on the master branch as it appears in your branch list, and press “fast-forward to aurora/master.” You don’t need to update your remote (on Github)’s “master” branch; just the one on your PC works fine. Once that’s done, nothing else should be present where the “X commits behind” was. You must (absolutely mandatory) make a separate branch for every PR you intend to make if you’re a casual non-coding contributor. You really don’t want to screw with your master branch in any way unless someone with more sense tells you to; this’ll irreparably make your PRs break, and you’ll end up having to reinstall and repeat most of the steps here, not to mention re-doing all of your ruined work. So, to begin your first project, do exactly that. Right click the “master” branch on your list, and press “New Branch.” These things can be deleted or remade as needed, but once you delete a branch, it’s not possible to get it back. These can be named whatever you want to remember them. When you check out your branch, the git magic begins. Every change you make within the local folders you opened with Fork will be tracked in Fork itself. Every edit to any files that aren’t manually ignored will be reflected under this tab in your Fork program; You can test this by doing anything to the files inside of the code. Delete, drag, drop. It doesn’t matter much; if it changes, it’ll show up as a local change. If you’ve done something locally that you don’t want to keep, you can go to the “Local Changes” area here and discard it care-free. Discarding changes is literal here; that means the changes themselves revert, and you’re not deleting a file (unless the change was adding it to begin with.) The important part here is that you don’t commit changes you can’t revert manually. Reverting changes using git is a more complex process than a simple discard, so once you commit something, it’s committed. Only committed changes can be pushed to your remote, however, and only pushed changes can be made into pull requests on the Aurora public repo. So, for example, you edit a hat to be red. The hat was originally blue, and the code made it so. If you haven’t committed these changes, you can simply right click the changed file here, and discard them; this’ll return the hat to being blue in the code rather than just deleting the file you changed. Liberally use discards to learn using temporary methods! Once that's all done, you can get started on the mapping aspect on the next page. Starting mapping - important basics Before getting to mapping, you’ll need to understand at least vaguely how to copy-paste the code that makes the maps work. Two things will be your best friends in figuring this out; Runtime Station and Visual Studio Code. If you’ve followed the Aurorastation README’s installation guide, you’ll know where the config file is (it’s in the config folder); go to it and change the FORCE_MAP to “runtime”. You’ll want the rest of the installation, like giving yourself host perms too. Otherwise, testing is not going to be possible. Runtime station boots a lot faster than normal maps and lets you forcibly spawn away sites and ships to test faster. Forcing those things to spawn is a slightly different approach which will be tackled in the example mapping section. You can open any .dm (code), .dmi (icon) or .dmm (map) file in the Aurora code to automatically see the folder trees from Dreammaker, provided you followed the installation steps in the README correctly. You will not be opening .dm or .dmm files with Dreammaker in this guide, though! It’s best you get used to using different tools because of that. Icon files are fine to edit in Dreammaker, though If you’re making a new map file entirely, make sure to make it from StrongDMM’s “Create Map” button, and set the format to TGM. This is MANDATORY! Making your testing away site To get the fastest idea of how this all works, you’ll be making an example site with this guide. Begin your work while your branch is selected on Fork by making the sub-folder, with your away site’s name, in the away site folder. The path itself will end up being, Aurora.3\maps\away\away_site\(insert_name_here) From there, if you’re not feeling entirely confident, you can simply copy-paste files in your file explorer over from the “placeholder_site” away site found in the same root folder. After that, follow the naming convention and change those files over to your new away site’s name. This is currently in a WIP pull request you can find here https://github.com/Aurorastation/Aurora.3/pull/16652 To repeat : if you’re making a new map file entirely, make sure to make it from StrongDMM’s “Create Map” button, and set the format to TGM. This is MANDATORY! Mapping functions - things to avoid As far as meta features go for mapping, you want to avoid three of the big mistakes new mappers make. You can not swap apostrophes (‘) for quotes (“) in variables, either in code or in map files. Period. Otherwise, you are going to have to convert the map to a text file, and manually fix it, wherever it is! Where there is space or otherwise empty turfs or areas, you want to use two unique things; “/turf/template_noop” and “/area/template_noop”. In short, it will improve your map’s performance a lot. Once you're done here, the next page will get started with proper mapping. Actually mapping - helpers, pointers A huge part of contribution is to copy what exists to see how it works, and get comfortable with it before you start getting new ideas. Mapping is not exempt from this, so expect to be copy pasting… a lot. A lot, a lot! Especially if you don’t understand certain systems. Some majorly confusing systems will be illustrated below to help people better understand how to actually work with these things. Areas Areas are the features that assign power grids and various monitors to rooms. Areas can be as big or as small as you possibly want. However, there are several major takeaways in mapping areas; Areas don’t change ingame. Without some special, and typically very buggy methods, your mapped-in areas are final unless you change them again with mapping. Atmosphere must be consistent throughout singular areas. Otherwise, your map will fail checks. Space areas (including template_noop) can be sealed or given an atmosphere, but you can’t give them gravity and lots of features get very buggy. If it’s space, expect it to stay in space. Some nifty features of areas; Areas can have optionally simulated power and lighting. Atmosphere is not controlled by the area, contrarily. All turrets in an area will be controlled via any turret controllers you place in the area. This means you can’t have turret controllers outside of their designated area. You can get around this by making separate areas for the turrets and their control panel. All atmosphere monitoring systems tie “alerts” to entire areas; so if you trigger an air alarm in an area, every single alarm in that area will go off, and every emergency shutter will drop. You should add unique areas to code for away sites following the format that most away sites offer. Power Power is rather self explanatory. This is governed by two things; areas and cabling. Cables are two-way conduits, so however you link them, as long as power is being made from one source, it’s going wherever else it’s connected. Areas allow for wireless features like wall machines and lightbulbs to receive power from APCs, which on the other hand require cables directly linked to work. Since it’s so simple, all you need to know is to link generation equipment like solars/RTGs/reactors to SMES, which link to APCs. SMES store more charge than APCs and automagically distribute it as needed to the APCs connected to it. Here’s a visual guide for how a minimum reactor setup works. Atmospherics Atmospherics is slightly more complicated, so if you’re unfamiliar with the system, avoid overcomplicating things. Simplifying it, you inhale air (O2, N2) and exhale CO2. So, to make a livable atmospheric system at a minimum, you’ll need to fill it with air and take out the CO2. Every functioning away site where possible should adhere to this system, if it’s not a derelict, natural formation or otherwise hindered from having an atmosphere. The only difference between the above system and the Horizon’s atmospherics is that the Horizon can exclusively extract certain gasses or pump those gasses into vents. It also has a lot more gas variety it can store. This is all unnecessary for this guide, so please consult the guide below for a full description of what’s necessary. And there you have it - a less-than-comprehensive look at away site mapping. This is probably not done, but right now the only essential thing missing is the PR for the placeholder site being merged. Ping me on discord if there's any discrepancies!

I need to look at this later in more detail

What the title says. We've finally gotten to the point where I feel medical and round-by-round things have stabilized consistently enough to warrant major gameplay changes like this, so I think now's a good as time as any to see how the players would handle being given a more believable and highly cruel system of firefights. Some things to preface this : The PR being up does not guarantee this will get merged or even test merged - this is not my decision whatsoever The PR is proposed as a TEST and be test merged in ways we can hopefully plan to monitor or glean feedback better later, if it's even considered With that said, this thread is here for a few reasons; to get feedback for the values I'm proposing, to focus feedback on the idea to me, and to test the waters to see how reactions on this generally go. These values in of themselves are also absurd by ingame damage standards; most singular shots, if hitting something critical, are going to be fatal without heavy armor to absorb or soften the blow. This means that, if the PR itself has remotely accurate numbers, things may be a little weird as far as damage goes; after all, I'm not a coder. All of this also operates on the best faith assumption possible. The obvious intent behind a test merge should also not ignore the fact that people might just abuse these damage modifications and we'll see utterly ridiculous levels of ganking - that's not optimistic, but it's definitely a possibility, further reinforcing that this really should be taken as a simple idea and nothing more. https://github.com/Aurorastation/Aurora.3/pull/16653

The current holodeck has no cameras inside so I didn't think about it, even though it wouldn't work code-wise. I'll see about adding those to the holodeck sides now since those allow for camera room. The windows aren't shocked. It is basically like locking an office door, which isn't in any scenario a fortress. Just break the window if there's problems inside. This replaces the lounge and entire recreational area, which had appeal as well due to the fact that you could roleplay in a relatively closed-off space while still being in-round. This combines the best of both worlds by making that completely optional through window tinting and door locks. I sort of agree. The current design, however, is because the alternative is very open and empty looking - hence adding the small vendor to extend the hallway slightly.

@Dreamix Thank you for the visuals, they seriously helped. I opted to keep the double-holodeck scheme for the simple idea that the holodecks would be best repurposed as both an optionally private, and an otherwise public area. So the two decks working in tandem for two different purposes is helpful for this. Here's the changes to the current mockup; 1. @Dreamix @ReadThisNamePlz Dimensions aren't changed of the actual holofloor, but the "viewing area" is DEFINITELY more spacious. 2. Maintenance is now a consistent loop virtually around the whole inhabited deck, without needing engineering access or shortcuts through trafficked areas. 3. To make room for the adjustments, the shield room is now directly attached to maintenance and the engineering breakroom. This keeps it readily accessible to engineers, and, provided crew have a reason to break in, it's even simpler now (just a welding tool is needed). 4. @Dreamix @La Villa Strangiato The self destruct is now attached to the maintenance behind the CIC itself. 5. @Dreamix @La Villa Strangiato @GeneralCamo The CIC is now adjacent to the crew armory. 6. About 1-2 tiles of space have been knocked off the crew armory to fit this, but the armory itself was really big. There's still plenty of room to stuff a lot of disgruntled employees into. 7. @Carver some vending machines returned vaguely to their previous positioning. This is the layout; (I'm aware of visual artifacts in the self destruct chamber and CIC! There's also a missing railing on a catwalk next to the ladder. Those issues will be fixed before I push) Without lighting; With lighting:

There are visible maintenance entries and, for the southern holodeck (which is meant to be more public, with more windows too) there is a giant 4-door shutter opening. Bridge access also has access to the shutters externally. Are these intentionally overlooked? If they are, why tho They can walk up the stairs 3 tiles from their front door or, if an FR is in question, maintenance is a 2 tile walk. If the proposed issue is people being in danger and being inaccessible, this is a non-issue. It's on the ship, there is no logic behind making even our most public space easy for wounded to be recovered. A holodeck and recreational area is a direct roleplay tool that is utilized expressly for occasions that don't require extraordinary circumstances. Like the ship exploding, or active combat needing command in a bunker. Those two things aren't inclusive for the rest of the crew, not even in passing; because one is a literal bunker and the other is a bomb. It is just a point to pass, or ignore, in 98% of rounds, for 98% of people. So I would pretty sternly argue that having these things so close to a trafficked area will contribute greatly to people passing by, and enjoying roleplay together. The alternative is having these things so distant that you have no reason to pass them in idle work or any activity for that matter. You need an invested goal to visit it; be it to interact with another person/people, or to invite them yourself. The odds of you wandering into the pool area right now and generating anything substantial (as in, fun or, failing that, interactive at the least) is zero because of that. All that said, the CIC and self destruct are two really unimportant areas. Their layout and location is almost entirely irrelevant to their purpose. The holodeck and the areas now crammed into the holodeck, however, kind of rely entirely on their location to be trafficked, like the reasoning above

Please read the full PR description and its replies here before replying https://github.com/Aurorastation/Aurora.3/pull/16103

Personally, having played both enough to get comfortable, I can certainly say both XO and OM are boring roles. The split of authority made by the two between service and cargo/ops ended up giving them far less to do with far less people to interact with, while simultaneously providing no alterations to gameplay - not positive, nor negative. That said, if QM returned (in the event that, somehow, the XO is overloaded enough to delegate) it could easily warrant merging OM into XO. Then, XO would be set apart, controlling most low-priority functions and service personnel on the ship, making it more fun and more reasonable to label as our second-in-command.

The purpose of the "worst case" statement here was to say that we have less problems to solve, hypothetically. As in, the expectation is to still have problems on our plate if we even drop a metaphorical nuke on the whole department. It leaves the actual impact of these things more clear on the rest of the server, which I painted out as requiring even more content for every department to do constantly to even make up for the debilitating aspects setup has on the problem-rounds in question. At its core, yes, I played engineering for years. Engineering players matter and I didn't say the contrary, but I did say that we're definitely trading the entire rest of the server's detriment for their enjoyment. That in of itself is not really an outrageous claim to make given the circumstance, to me. Fair. I agree with these points entirely. Didn't know this either; this definitely remedies that concern, if a little clunky seeing the common radio channel. ---- Prefacing this by saying I don't want to be rude whatsoever, but - While it makes me feel like I'm speaking in a different language, I am going to super duper simplify the things that are, to me, being misinterpreted here from these two posts; Yes, I think Engineering's enjoyable features need to stay until we have a proper replacement. It is really silly and honestly cruel to say that a starved player group should starve more without assuring them we can replace what was taken. This was not the written intent of the suggestion. It is not said here or brought in by me that these features are tedious, underwhelming, busywork, time wasters, etcetera. My opinion on the actual gameplay given to Engineering is that I literally have no room to talk, I haven't consistently played an engineer in two entire years. It might be easy to misinterpret this given the substance of the linked threads, which I did not bother re-reading and added them for the purposes further explained in the OP's heading spoiler. To fully establish what was said before that post was made and again in the above, the intention is to replace, not remove. This is actually so elaborated upon by now that I am just going to point out the OP doesn't mention a total removal of the features mentioned at all. Even more, it is literally sugar coated intentionally by altering the original system to remain completely intact; but when the proper staff or actual usage for those systems, they become vital as they are now. Things like needing to move the ship - or even just setting up the reactors for no intended use, which isn't even mentioned as being suddenly inaccessible here.

I agree wholeheartedly. I think, because of this, we should tackle the issue only when the effort is assuredly being put forth to replace it. Which is super important to reiterate as a motivator of this thread. I added clarity to that below. To new readers, please god read this; The quote here, was pointed out to me as being horribly easy to misinterpret. To be perfectly clear about what my intent with this post is, I mean to imply that this suggestion does not focus on Engineering's particular gameplay being altered in any significant manner. This, especially with the content of the first post, aims to give us a solution preferable to engineering's players. So, while the issue is clearly seen here, the solutions proposed are not as simple as removing our set-up entirely, but making certain department elements - only some of which are vital to game play - temporarily a non-issue for manifests that are utterly incapable of remedying the issue to begin with. It goes without saying that Engineering hasn't had consistent, or even major content or playstyle alterations since we even added a supermatter crystal. And, that's such a long time that most of the potential viewers of this thread would not even be here to remember it. Relying on removing the features in place for a "maybe" is not being proposed (much less considered by development overall, to my knowledge). I apologize if none of this was made apparent at first. I made a lot of threads today, so words are getting jumbled and mispronounced as a result. If there's further confusion about the intent of the suggestion not being made immediately clear in the first post, let me know and I'll try to elaborate on it; all of it should be in line with the paragraph written before this otherwise.

Edit : read the post that I made after this! It clarifies some easily misinterpreted wording used here. I should add that this suggestion is less about making Engineering more fun as a point and more about allowing every other department to have fun without being hindered by the lack of engineering entirely. It's way easier to alter this than it is to somehow balance out the sheer amount of lost hours and ruined rounds for other departments that exist anyway. Instead, we're even more pressured to add ceaseless content to the other departments to make up for most of the day being unplayable, which is what we'd need to do to counteract this. So, giving content to engineering that isn't so pivotal to the round even being playable for everyone else is much easier. Even in the absolute worst case that assumes Engineering has absolutely nothing to do ever again, we're left with way less problems to solve than currently presented. The thing is that without the necessary departments and crew to react to these events, some of the events plainly don't trigger already. The unavoidable circumstances that still occur like moving fauna or less specialized events become way less painful and boring when people who have the tools and allowed skills to deal with them are around. For third parties and docking codes, this is just a proposed alternative to docking codes. It has also been a very long time since spontaneous intrusive ghost-role boarding became an issue. Seeing as we lack any features whatsoever preventing it as far as I'm aware, the usage of shields or a specialized system that blocks those problems would work just fine and save us some pressure if we use this proposal's existing changes to work off of. An unmentioned issue I should've also described was the ability for ghost roles to exist with no command or helm crew to even acknowledge their presence. Ultimately this leaves the Horizon dead in the water and impossible to speak with, while the ghost roles are left not even really knowing those staff have become unavailable by either leaving the round, or departing on the ship for expeditions (which is a frequent occurrence for the entire helm to do). Being impervious to an extent from these situations until people can even roleplay with them would allow for people, like bridge crew, to actually leave the ship without a complete back-up roster staying behind plus command.

I forgot those exist hold on I'll try to get this moved over. Developer moment

These additions relate to emergency departments in the context of off-ship expeditions and away dispatches of any sort. It doesn't mean to imply we should make these more or less available to every department inside the ship, which is easy to misunderstand here. This suggestion is to simply add temporary measures, like gauze in your emergency box, to soften the impact of game-ending frequent things such as lung-popping and severe bleeding where they can be saved. For away team medical purposes Very basic recovery and fatality-prolonging methods in medical equipment that don't rely on completely rejuvenating the wounded is a very, very good idea to further make exploring things less blatantly suicidal when we lack a loaded medical department or EMT on every away team. Those are; For away team security purposes Expedition shotguns suck for their intended purpose, which is killing any hostile wildlife or low-threat obstacles teams might face. They are, contrarily, extremely useful for instantly killing player characters due to their high volume of laser fire. Since they have literally three-four clicks worth of ammunition each, and expend all their high-damage shots in this time, and can't be reloaded without a powered stationary charger, they do more harm than good as our now secondary (to machetes) protective tool. Since away-site firing pins already strain believability, it sounds fine to replace these things with literally mechanically inaccessible, but more capable firearms and defensive tools that would only become available when the shuttles depart from the Horizon. Locking those behind really obtuse or specific methods, like having the shuttle undock to access them in the first place, would immediately curb a lot of risk in letting players have access to good gear so readily. It would make the effort and intention separable for those looking at it as literal powergaming, because un-docking and re-docking a shuttle to unlock good gear when two armories are available is precisely that. Without being pedantic about specifically balancing it, just give them whatever ends up being agreeable that isn't just the current gear. If it can reload and have supplies prepared for it, it's plenty beneficial. If less blatantly weaponized things like protective and environmental gear can be accomplished, even better. For literally every other emergency department Any other emergency circumstance right now is well oriented around the allocation of people and materials to given points. Mostly engineering, which is literally a matter of moving materials/tools and fixing problems. They already have these expectations in place when joining expeditions that require those materials and expertise from them, so there's really no changes towards them, or anybody else who is especially important to bring on away missions.

The intention wasn't to call out chat rp, whoops. I meant to say the alternatives are presented better here, instead of chat RP being practically all you can accomplish. For the new players and the leaving-behind of crew, yeah, that's a fair point. I think that we also may benefit from having more people inclined to join at round-start either way, and having more ways to keep in touch or frequent travel to and from the Horizon when in range is absolutely a must. Which, was part of another suggestion I was writing literally while replying to this, so that might be relevant too (especially because I'll happily work on the listed changes, as well) For engineering having gameplay, they don't really have gameplay as it is to begin with. It could be argued that the busywork and tedium is all they've had for as long as we've even had a supermatter reactor. Which, is a really long time. I can see your point when taking that into account, because removing content from an already content-barren department is a very silly idea. The change is beneficial, in the end, but we would need to work on alternative busywork for engineering or actually interesting objectives/gameplay after years of zero content. These alternatives don't seem really difficult either, if we lower the necessity of these departments relegating to emergency tasks. That gives them way more room to actually proactively seek or be given activities in daily game play. Exploration is a tremendous aspect of this option-oriented style already, so I think these opportunities mesh together perfectly.

Chat RP is honestly going to be less desirable when you're capable of doing more things. In this case, we have a lot more we as a whole crew can do, since we're no longer on the Aurora. It can functionally make sense with the takeaways above to have an entire manifest leave the Horizon, which would've been absolutely nonsense on the Aurora.

The fourth reply by me on this thread has major clarification on the intent if possibly misunderstood here Preface for my fellow devs : To everyone else; We tried removing or easing roundstart setup at least twice as a mandatory gameplay requirement from the Aurora. On the Horizon, with even more departments and functions, and even a lot of exploration reliant on it, it's become needlessly destructive and limiting to our gameplay when we can not guarantee our manifests are 100% staffed 24/7. Things becoming this way like exploration are deathly hindering what would otherwise be really common; landing on Adhomai, for example, is something extremely sparse between non-mining and research crew. Not only are we rolling against the odds of Adhomai even spawning, we're juggling its region, its dangers, and the manifest contents, which are overwhelmingly underpopulated for work days especially. It makes lowpop and non-peak hours in general universally suffer. Basically, this all means we should : 1. Make shields set up by default, or optimally some shield present on the Horizon that keeps the ship safe before it actually begins moving (maybe by disabling random events and blocking third party ships from landing without malicious interference?) (I have some fucking crazy sprites that could be used for this, actually). This would allow the Horizon to face dangers once the crew even exist to react to those dangers, and prevents 3am shipwide greimorian infestations, or mass venting and damage preventing joining. 2. Have one, both, or a separately-set-up engine for the purposes of keeping the ship habitable before we begin maneuvering in space. Like above, this could become useless when the ship actually moves, meaning engineering is still needed for long-distance travel, and things like ship combat or hazards become suicide without them. You can also accomplish this by the primary, or a secondary SMES being charged from roundstart, and losing its stored power when that happens too. 3. Have thrusters set-up by default in a proper efficiently mapped way. This part is slightly self-defeating if the Horizon would need engineering anyway to begin moving like above, but it would save engineering's time if they did intend to join expeditions without prolonging their departure. It would also ease the requirement for basic engineers to know atmospherics extensively, and vice versa, though given I don't play engineering recently, feel free to let me know if these are fine as is. Those relatively simple changes would, alongside this post just below, make everyday game play immediately less restrictive for all crew. Go see more of the work we've dumped into exploration! It's worth it. The primordial 2018 thread about this is here, The PRs that related to this on the Aurora are here; https://github.com/Aurorastation/Aurora.3/pull/5462 https://github.com/Aurorastation/Aurora.3/pull/12230

What the title says. Upon looking back at this, I actually have no idea if this is a written regulation or not. Make it so RDs, as command staff, are explicitly permitted to step off the ship to organize expeditions without other command to also serve ship functions. If it's reasonable, make all command permitted to as well, if in the same circumstance of being alone. If all that is still reasonable, allow entire manifests to leave with some takeaways, like needing to set up basics before going. (This would honestly probably need more work in keeping the Horizon from getting disassembled by the environment/ghost roles while empty.) They, or any other command who do this, would still need to go through other command if they're not alone to leave. That isn't regulation either, but it's common courtesy both for the players OOCly and professionalism/coordination ICly. Benefits : In low population rounds, or rounds where we miraculously have no command, we're able to have our command players voluntarily hold expeditions to areas, sometimes occupying the entire manifest who would otherwise be forced to sit around bored. Downsides : Mandatory round start setup forcibly delays or could completely block these circumstances from occurring either way in a lot of cases. All of this could be clarified on an exploration/expedition guide and regulation page, since it's pretty essential moving forward even if this suggestion is declined or changed. You can also give input on tackling round start setup separately here, which ties heavily into this suggestion.

This is definitely a substantial improvement. With all this here, my biggest concern is just the tree. I think the back lounge is definitely a net loss, either way, but it's acceptable given the remap itself seems good otherwise. The tree is going to be a stretch to fit anywhere. I'd honestly just remove it for more floor space in general, because it will definitely be needed. It helps that the upstairs nature showcase exists, as well. Something to consider right now (but isn't a mandatory thought, I should add) is because of this PR, https://github.com/Aurorastation/Aurora.3/pull/15926 even more objects of special interest like ships and debris will be visible outside of the Horizon. Since I think you pulled the bar further northwards, it might benefit to have some form of better view to the left side of the ship to let people see these better, since our current ability to view these are rather limited. A giant help would be simply removing the one-tile overhang that currently exists wherever possible, though some might interfere with the Intrepid's hangar below, so beware.

In practice, this ends up being a case of having destinations to reach and needing to cross the central dining area to arrive at the bar. One way or another, the hallway entering the bar no longer just becomes a hallway, but it's a central dining area where people can and will talk, and these conversations will be seen on both sides. For reference to other readers, a good rule of thumb to always have is that your character can see (and thus hear) up to seven tiles from their tile in any given direction. That means, sitting in a relatively central portion of the dining hall looks like this; The red dot in the middle is where the player is sitting. To put that into perspective, assuming the curtains are closed on the private booths, they are going to be sitting in a room that at most holds twenty-seven seated people (in line of sight of the chair). There's no reason to have this many chairs in visible sight of each other as opposed to the current layout, which uses walls blocking line of sight to explicitly minimize the conversation bleeding as it is. There are obviously more generous examples of this that minimize the volume of seating areas in line of sight, but they all seem to fall pretty well into having double-digits worth of seats in view. This makes the bar, the new dining area, and the kitchen simultaneously all worse places to roleplay in when they already have such immense difficulty squeezing RP out of 5 seated patrons. This also isn't true, and using this logic, expanding the table number above does not fix whatever issue this potentially might have. What this means is "I don't know what this fixes." Paving over work already done and functioning tends to have a motivation in resolving issues; I don't see issues highlighted here at all, and the ones proposed are seemingly acknowledged, but not fixed in this implementation.