Boggle08

It might be better, having the core be positioned as you have it. There isn't much incentive to interact with the AI normally. If the core is unrecoverable, or if the AI is in active danger of getting struck by other environmental hazards such as ordinance or meteors, it can throw open the doors and get someone to unbolt and move it.

Bless you and Read for those telecommunications changes. I was initially eager to see the devices spaced out, then I noticed it was all parked right next to engineering. Out of curiosity, what's under the AI core? We don't have to worry about people cheesing it by dropping rods from another sublevel, but I could probably take it out by detonating a single-tank halfcap directly underneath the core. Which might be too jank.

Competent and motivated are two extremely powerful things for a project like Aurora. I've seen both from you, even outside of this application, and that makes you very attractive as a candidate. Your ability to work with others is what concerns me: Even at the staff/developmental level, there are a lot of checks on how you can contribute. Both top down, bottom up, and sometimes even horizontally. Plenty of proposed projects have died in community feedback threads. Even in lore, our proposals will frequently get rejected internally; It's important to maintain a level of personal distance with your projects and move on or compromise when your ideas don't work out. How well you work with others is a big weigh on the decision, and your co-workers will not appreciate a long drawn out rhetorical slugging match over every feature you wish to propose/contest. No matter how well you defend your position compared to them. No matter what design paradigm you're using, you're gonna have to work with others, and be told no a lot. How do you plan to navigate that environment?

You were racing a Coeus. Dionae these days moved at a fixed movement speed, though sometimes less depending on the pain they intake. As for the battery thing, you can mitigate drain by staggering out your sprints and fingerbanging the APC's as you run past them. This was a tactic way back when, but it's way more sustainable now that your battery doesn't zero after running half the length of the holodeck going vertically. On the matter of heat, the threshold where you start to get temperature warnings/take damage is somewhere around 850 Kelvin. G2's do not overheat like shells. You can easily have human-tier endurance so long as you pace yourself and throttle your movement when you need to. I know this, because I have done this. As for the broader G2/Dionae comparison, honestly, their problems are different from what I think I see with G2's. The problem for G2's is that the game gives very little feedback/mechanical incentives for you to break off and fearRP with your wounds. Every species in the game can take a high threshold of punishment, it's just that they're going to be standing dead if they push it to the absolute limit. If their body will even allow them to. Dionae actually use a lite version of brainmed, and the fact they can't run away from situations they start, or that they slough off parts of themselves when they take too much damage is well enough to encourage people not to play foolhardy. I don't think adjusting statsticks around is a long term solution, if anything G2's can stay just as durable. They just need more debuffs when they take damage, an equivalent for the need to be stabilized, and more feedback via logs when they're horribly damaged.

This suggestion thread is asking if we should hold command-whitelistees to the same standard as event volunteers. I don't think just instituting another whitelist strip is going to cut it, because command don't know what we plan for events, and they have to make calls in the moment. I think the only way to achieve the level of simulated competency that this thread seems to be asking for is if we were to physically block in the command members to play these events like volunteers, and let them in on what will or might happen. This is a problem. One, because we really don't need anything whitelisted to be more exclusive than it already is. The second reason, and much more important in my view, is that it is going to strip a lot of agency from our player base during events. Going back to the whitelist strip, it won't change anything. An old out of touch command whitelistee is probably about as capable as a guy who just got his recently, and is still getting the hang of it. You're gonna have to tell that guy to sit on the bench if you want ultra competent people in command during event shit; it will be impolite to be new.

They wouldn't get the same priority in the queue as dedicated away mission roles. Unlike those, engineering still has an entire ship to upkeep. The salvage ops I'm thinking about are a low-intensity side activity that is achieved either by collaborating with other departments, or getting something like a CE to organize and authorize them. They will not be expected to fly their own shuttle, and the access restrictions on the intrepid will be the same. It can work both ways. We can have event maps where we expect engineering to use these things. In ones where it's counterproductive, I think it's fair for someone to fly in and world-edit the lockers out while everyone's in the lobby.

Simple as what the title says. Engineering gets special lockers containing equipment that can tear down and salvage derelicts within a reasonable time frame. The primary tool for this is a bulky, bright yellow chainsaw grip deconstructor with an operating end that kinda looks like a mess of grindy weldy drilly tools. The deconstructor needs to be wielded to use, and requires a power cell to operate on top of a welder fuel requirement, which it guzzles a shit ton of; enough to the point where there's an incentive for engineers to use those welder fluid backpacks that no one ever touches. In return, the deconstructor can chew through things like reinforced walls and airlocks in the fraction of the time they would take if one were to manually muddle through the steps. Because of this awesome power, however, these deconstructors come with firing pins similar to the expedition shotguns: they only work in their natural environment of away missions and salvage. In addition to structures, they should be capable of processing machines such as computers, SMES stations, autolathes, et cetera. They can either be set to break everything down into their constituent building components, or mash them up into scrap metal of varying qualities for reprocessing. With this, engineering can pair up with a shuttle pilot and go on dedicated salvage missions, or perform them concurrently with another survey party. In mixed groups where the focus isn't on salvage, the engineer can provide utility by being able to sap through almost anything using their deconstructor. Since they still have obligations to tend to in the ship, they should not be able to fly the shuttle on their own, however.

Yeah, you know, that's a pretty good take. Stabilizing people is a pretty huge deal for anything that uses brainmed. The longer you ignore your wounds, the worse you get until you either run out of blood, oxygen, or go into cascading necrosis. It's one thing being able to straight up ignore pain, it's another being your own stasis bed.

Perhaps as a by-product of the department being so light on activities, people’s reasons for playing are varied and broad. Some like the relative lack of interruptions post configuration, others are more technical, and explore deeper mechanics or subsystem configurations. Some even stick around for the seldom times we take damage, and make it a game to speedrun their way through breaches. One of my reasons for joining this server to begin with was to play atmos in peace, and my reasons for still playing are a combination of all of the above. Attempting to address one appeal, and one appeal only, of playing engineering is going to narrow down what kind of player we want back there, and alienate others. Ideally, we should maximize the number of ways you can play engineering “appropriately.” On the matter of altering or reducing setup times, this is something that should happen. Not today, not before we introduce features to supplant their absence, but it needs to happen. A full engineering staff can assemble the subsystems in 30 minutes(perhaps half if they’re on their A game coordinating). Doing it alone, especially if you’re trying to install optimal configs, or playing a slow species, it can take upwards of 40 minutes or more. Thruster modifications are especially time consuming. These setup times hold engineering and departments that are dependent on them hostage. What’s even worse, however, is that all of our subsystems are a solved game. Us technical players that we are, we have optimized the subsystem configurations that are virtually the best in every single scenario, and leagues better than the wiki default. What is also terrible is that almost all of our subsystems cannot be reconfigured on the fly, which further damages opportunities to experiment, or adjust for circumstances. Experimenting is also bad on time, and again, the rest of the station has needs that only engineering can meet with their time budget. Fixing our setup problem involves fixing our subsystem problems. Step one is making our subsystems easier to modify post start-up, whether that means being able to reset the entire subsystem or easily make modifications safely on the fly. Both engines come to mind on this. As an example, the SM could start the round at a low energy trickle, just enough to maintain homeostasis for a skeleton crew. The main SMES starts bypassed and set to not charge. An emergency power supply garage filled with portagens can serve as means for people to temporarily utilize machinery that would generate brownouts in the system. Ordinarily, this would cuck a joining engineer out of being able to setup, optimize, and experiment with the engine, but if the engineer can hit a reset button(or some mechanically appropriate equivalent), the concern is moot. In regards to the BC’s dependencies at lowpop, I could think of some ways to remedy this: - introduce a refueling station just outside atmos, with a single access restricted phoron tank(not a canister, a tank) for use. The port should feed directly from the Co2 line by default, but it should also have the pumps necessary to accept from mix line. - Give the intrepid its own shielding unit. During deadhour, it can function as a quicker and less time expensive alternative for general overmap exploration. Perhaps even give it more starting propellant. Thruster nacelles are something I have much to say on as well. Right now, they have little functionality, you put the fuel in and it goes. Modifying them for heated pure phoron configurations is practically a necessity at this point, and doing so is both drastic to the infrastructure and very time expensive. A solution to this, in my view, is to design a pipe network in our thruster compartments that is “universal”, incorporating as many design elements as we can to reduce setup times. Need a h/e assembly in the burn chamber? Already there. Want to experiment with other oxidizers, or try to burn H2 for propulsion like the wiki says? You don’t have to lay the pipeline, the pump is right there. I think it might be worth us having auxiliary thrusters that work differently, sort of like how we have an auxiliary reactor to power the ship in the form of the Tesla. Ion thrusters might do the trick. I don’t know shit about fuck how they work IRL, but apparently, they just use electricity to run. We could cram a bunch into the deck 2 wings and have a power intensive alternative to the main nacelles that come online when the main reactors do. What I hope in the long term, however, are more customizable engine and thruster configs. As I’ve said, it’s a solved game. There is no reason to install configurations into the engines or thrusters that don’t maximize power or thrust output, unless it is to save time. On servers that use TGcode, you are capable of synthesizing unique gasses using gas interactions inside of the supermatter, and fusion. Fusion is too wacky for us, but gas synthesis would be a welcome edition to our SM, simply because it would mean we would have reasons to configure the SM for purposes besides power generation. Good examples of what our SM could produce are better thruster propellant, or gas that makes cryo tubes more efficient. Configuring the engine for power generation won’t be the only right way to do things. Same principle can be applied to the shields and thrusters: avoid game design where we are able optimize subsystems to work in all use cases. The endgame of such a design principle being put into place is that engineering will get to customize the horizon every round. How it behaves in the overmap, her power budget, how and where the effort goes into the subsystems. And if they don’t want to do that, the infrastructure of the ship will allow them to rip through what they need to do and get right to the RP. About away mission stuff, I’m just gonna put a concept I’ve been mulling over into a new thread. This post is getting longer than it has any right to be. In summary, we should slowly reduce engineering’s setup obligations as we add more shit for them. I want to chair RP for four hours while putting oxygen into the SM, and the fact I have to hustle so some poor bastard BC can play the game is crimping my style.

I think my department is quite intent on having Dionae remain a selectable option in security, and we haven't had any balance issues or "outbreaks" from them being there.

It is frustrating to see more industrials in security than it is to see them actually do shit in engineering and operations. You know, the jobs they were built for. The G2's specifically might have the slowest walk speed on the station, but because they're able to actually sprint now, it's moot when they can maintain a steady pace that's only slightly slower than Unathi walk speed. It might not be enough to juke the way other playable species can, but it's certainly enough to rush to where the fighting is and get to work. Two years ago, when running for more than 8 tiles as a G2 would send your battery into critical and dump your ass on the floor, we did not have to consider G2's and other industrials for that matter a problem. Now that you can pick up that meatshield and move it somewhere at a reasonable pace, it is. A reasonable fix in my mind would be for us to go back to the way it was several years ago, with G2's being stuck at their dumpy walk speed. I wouldn't mind that, I enjoyed playing like that, but I know that I was really the only one who regularly played like that. I'd rather not give up my ability to do my job faster as an engineer or cargo tech so we can keep forklifts that insist they are combat vehicles in security.

We actually moved at a faster pace several years ago. Antagonists would escalate faster, escape shuttles were called, and rounds could end at or before the 1:30 mark. Malf was mostly to blame for this, but other gamemodes could hustle too. Rounds would be quick, fast, and explosive, and then people would immediately follow them up with an extended as a cleanser. In theory, we don't have to change anything but ourselves. The escape shuttle's been traded with an abandon ship button.

I'm still new, but I've had a great first impression communicating with you and your team. Outside of the elements of lore you wish to prioritize first, Do you have any plan or outline specifically for maintaining the Hegemony? I feel like they're our weakest character background, given that most characters I've seen over the years don't use the Hegemony as a source of identity, and treat it as an antagonistic force or as a foil in their personal conflicts. It works fine in that context, but not if the Hegemony is supposed to be a "baseline" for the species. In addition to the previous question, what are your thoughts of this dichotomy, and if it needs to be addressed?

The fact the little wiki chart disallows them from cavity surgery implicitly bars them from surgical processes. The chart and the fact we permit the steps listed on the wiki(with the exception of borgings) has just led to a lot of confusion over a niche ability that never comes up in-game. It does not help that the surgery tray for them is incomplete, and they work completely outside of medical's organizational structure. Just take them off the chart, and leave an asterisk somewhere that they can install new limbs. That's it.

T-the OOC lore... I like the idea. I think it would certainly be interesting to see a timeline of how our server's lore evolved. From hodunk shit coordinated over skype messenger, to what it is today. I guess the weird thing about it is that it'll inevitably be a narrative about aurora, rather than a 1:1 retelling if it's something on the official wiki. There is a lot of cursed shit and internet drama from in-between when the server started, to where it's at now. How much gets officially documented in that context will depend on how brave we feel.

Doling out interim head roles is something that the captain usually defers to me. Just have it so I run my choices past him for approval, why not? I'll take anything as long as it isn't a drastic contraction in their responsibilities and expectations. The point of this thread and the other one trying to come up with a name for them is really all about trying to nail down what the XO's role aboard the ship really is, and putting that into something we can actually put on the wiki. Making them only and just only the grand poobah of the bridge bunnies isn't something I particularly want. Maybe I'll flip if the overmap game gets more going on for it, or if the bridge has more interactions with the crew besides wanting their dependencies from engineering, and occasionally hosting expeditions that other roles have gotten better at doing.

In fact, the more I think about it, that could essentially be a directive for a second-in-command XO: To keep tabs on departments who have supervisor vacancies. It's already an implicit ability they have, and they're better at doing it than any other command role aside from the captain.

The HoP is in a unique position where it can seamlessly manage the administrative end of any department in a very "hands off" manner. What limits their power currently is that they must respect the lanes of departments who currently have a head. They essentially lost a leg with the OM change, in exchange for a function of the ship that, for the most part, sits in a vacuum from the rest of the field of play. The second-in-command proposal definitely has bugs I want to see worked out before I can be comfortable with it, but it will absolutely murder my interest in the role if it's relegated to nothing more than just the bridge QM. Why even give it command authority if that's the only thing it should concern itself with?

My concern is that the role will be directionless if it's on a full roster whose captain isn't consciously feeding it directives. If their command authority is weak in such a scenario, they're just going to go right back to the subordinate state they're in now. If their command authority is too strong, they might start to contradict what the captain or the rest of command is doing in an attempt to be helpful. Current XO shines on sparse command rosters, especially ones where there isn't any captain to begin with. I'm not necessarily against the idea of a second in command XO, but I feel like their directives need to be outlined in this thread for this suggestion to get anywhere. They can't just have their authority trickle down from the captain like they're a bridge crew, Quartermaster, or Service Manager.

I feel like I should make an addendum: without an expansion of the XO's powers or responsibilities, Giving them a second in command hat will be of superficial utility to captains. They have an entire radio channel that facilitates a cabinet of dedicated specialists he can delegate problems to. Not to mention the AI. They really don't need a middleman, unless we were to take away their headset.

They were in charge of cargo, one step above what was then the Quartermaster. I personally feel like the role had more power back then without lane overstepping, because you could remotely move funds around and work the cargo control function. In the event of a crisis(That couldn't just be mitigated by just calling the fucking ERT's), I could literally summon a box full of guns and weapons, from my office, and create my own crew militia using the armory I ordered.

What would be the extent of their personal autonomy with such an arrangement? I have vague memories that applying quick edits to your ID to work the cargo program or open doors is bad form unless you jump through your own paperwork hoop. The XO is still in it's weird command auxiliary role, and I feel like the people who are for the change need to do more than describe the fact that the captain can turn the XO into his personal, command authorized shitkicker. Specifics should be entertained. haha

I feel like you're onto something. I've played a ton of HoP on the aurora, and a little when we started with the Horizon. The role is suited to be an administrative "fixer" for when there's gaps in the roster. Expectations from the crew of what I'm capable of grow more and more as the command roster gets emptier and emptier. Clarifying what is overstepping versus what is perfectly fine is something the XO generally needs. When you're fulfilling a vacancy versus overstepping into someone's lane is a very circumstantial affair, unfortunately. Automatic crisis deference like that, that's fine in my mind. The role is well suited for it. As long as it's articulated well as an expectation, and the XO has the option to decline.

I'm not sure what your point is. Being second in command carries the implicit notion that you supersede the rest of your peers with respect to command authority. The Captain/XO relationship your describing sounds similar to the dynamic between XO's and their constituent BC's. If there is no difference in the XO's authority prior to this change, why entertain it besides "flavor?"

This entails much more than a simple change. The aformentioned council dynamic is an environment where equals among equals can advise, question, and second guess the captain. There's a mechanism built into this arrangement that(theoretically lol) allows command to overturn decisions as a collective. We'd have to rethink command's internal decision making process and manage an internal chain of command that alters itself every time someone different shows up on the manifest. For the XO role itself, without a captain, this is effectively a captain slot. I outrank everyone if my captain isn't on, so I can go ahead and give myself interim. Doesn't matter if I'm something besides a human or a skrell too. What is allowed to play XO might have to change because of this (and frankly, I'm not partial to drastic change on the matter). Another issue will be the XO's relationship between the rest of command and the Captain. Are they meant to be the captain's closest advisor, or a yes man and enforcer of their command authority? Are they in a position where it is proper for them to second guess and question the captain when in council with the rest of command? I could see the XO destroying the balance of power by being a regulation backed element to strengthen any captain's position, or as a destabilizing element that can rapidly undermine their boss's authority. This is a curious idea to ponder, but it needs to be pondered.