Boggle08

This essentially is the primary basis for me making this thread. While I personally believe that safety is an arbitrary concern(outside of niche cases where someone is shocking doors), The use cases and niche versatility of the distributed substation network never get taken advantage of because of the tedium. I am one of those people that stopped setting RCON because of this, and this suggestion, in my mind, is what will get me to start doing it again during peak operation. Setting up the shield network is far more substantial than RCON, but it can be done in seconds compared to the latter. The time and effort spent on a subsystem needs to be proportional to its utility. TL;DR, these changes will make the RCON network more accessible to players interested in the technical aspects of engineering, while trivializing it for those that simply need to check off a box.

Why not merge the pharmacist into this new GTR intermediary role, then? You can achieve a lot of GTR work with just chems, and this new intermediary role will be completely useless without them. It'll also fix the pharmacist's issue of being fucking useless after completing the bay's spread.

I see RCON being done less every time I play, even during peak engineer population. The only utility RCON really has going for it is that ability to have a more flexible and resilient powergrid. Anything to streamline the process of configuring this subsystem, because the juice is not worth the tedious squeeze any more. I’ve had issues with brownouts during peak operations trying to max out the substations like that. I guess it doesn’t matter if you keep the bypasses on and let the substations dump their output directly back into master, but kind of defeats the point in a way. The point of my initial suggestion is to reduce the number of button presses, and therefore time spent on this subsystem. What other case is there to not have preset values in the system? If it’s as pointless as people are insisting, then it’s inconsequential if it gets done.

They’re going to change the RCON values either way, the point is that we agree upon values that won’t cause power issues during peak operation(outside of people trying to charge like, a bunch of fucking guns or hypercells). Having preset values means I can run up and down the list only having to worry about turning everything on. RCON has niche applications that don’t get taken advantage of because of the cancerous setup procedures, and it’s been my experience no one cares about it until a problem that could’ve been fixed by it comes up. Then people loudly bitch.

Does anyone actually like doing this? I don't think we stand to lose much if someone were to give RCON optimal roundstart values. This shit is about as enjoyable as organizing a 60 member crew roster alphabetically based on their ID's DNA hash.

Lanterns are too big to fit in pocket sized slots, and both them and flashlights need batteries in order to run. I wouldn't say this is an improvement on the overall experience, especially given that voidsuit and hardhat helmet lights are right there, being the superior option. The lantern change is especially painful, because that fucks with my miner's loadout economy.

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.