Sneakyranger

Perhaps taking an aggressive stance against the people you expect to be guiding the round and showing initiative, as you say, is as unhelpful and inflammatory as when it is is directed at antag players who fail to meet the bar. It's certainly easy for a post like this to be taken as hostile to the reader, and I certainly took it that way being a command main despite not considering myself to have any of the flaws you describe; a step back was required on my part for a more level-headed reply. I personally think that service signs a contract when signing up for the round that there's a good chance you won't interact with whatever the antag gimmick is beyond feeling its aftershocks, and that's something you know going in if you play a low responsibility role like service. Sure, there are traitors sometimes or events that manage to get everyone involved directly - but these aren't a quality that can be expected all the time not because no one can be bothered to try that hard all the time but because not every scenario that should occur can occur in an environment where every department is notably involved. Division of role responsibility doesn't just go with what you have to do, it's also what you get to do - security is heavily scrutinized because they generally get to do the most. Command in this environment is acting responsibly when faced with these Odyssey problems; ICly, they not only have to worry about what is a sensible response for the situation logically but further whether their corporate masters (who are very, very real in the context of CCIA) will approve of their decisionmaking should it come to it. OOCly, they're not only in a role quite visible to staff and other players who may not always have nice words, they're also sometimes fending off people neglecting their characterization for the desire to get involved in whatever's happening in the round at the expense of everyone else's sense of disbelief. Honestly, I get it. It's a videogame, you want to play the exciting part - I literally do not blame you for that specific instinct at all. At the same time, I don't play engineering expecting to have to shoot the mercs and I wouldn't play security hoping to sit around and do fuck all while someone else shoots the mercs. All of that long-winded paragraph to say that Command's actions are on aggregate a product of their situation and blaming them (with harsh punishment threats no less) is less useful as they were placed in a situation with limited ability to make good decisions. For the command who are genuinely good but doing the sort of thing mentioned in the post, perhaps suggestions should be directed to the storyteller to make events that can more reasonably involve service and even give them carveouts (e.g "set up a field kitchen for follow on responders!"). For the command who are bad and rejecting your attempts to go even when you would be justified IC, I am very confident that that would already be seen as a valid complaint by staff without any further adjustments to policy. Using this post as a proxy for the rest of the thread's point since it expresses overall sentiment: yes, sometimes it is easy to bend softly and get a lot more people involved. I've done it. On the other hand, there are scenarios where the suspension of disbelief - something essential to an RP environment mind you - is completely shattered by sending the janitor to the Klendathu Drop. It's really not as simple as it is made out to be when you conflate the two situations; sometimes you have well-meaning people who can reasonably be sent by a superior who doesn't care that much or simply needs bodies, sometimes the people who want to come are completely disregarding their own characterization to volunteer in the first place and would negatively affect everyone else. If people want evidence of this point, I point to Orchard Moon's boarding volunteers going on a boarding mission to a shuttle they were told was depressurized in capri shorts. Realism seems to be a boogeyman point for some reason, perhaps because of its association with hard-scifi and poking holes in the setting's lore - but you do need to have some realism in the setting, and when you phrase that as "internal consistency" or "maintaining the suspension of disbelief", I think far fewer people would argue. As an aside, while I don't quote this in an attempt to direct it at anyone I have replied to or even levy it as an accusation at anyone in the thread specifically, I do find this a very salient point and it puts in to words a vague sentiment I have had difficulty expressing previously.

A good XO already. Get used to being more firm with regards to time sensitive things and crew (sometimes you just gotta put your foot down to make shit happen) and you'd probably be one of the top XOs in my book if the three or so rounds I had with you today are an indicator of future behavior. I'm a command main, so I'll give you a tip that you can feel free to ignore since technically I am just a random yahoo. Today, I would have kept control of the Intrepid mission at all costs - the delay from switching command over to the OM is what set off everything else, in my view (though you were more involved with it than I was). My two cents. Otherwise, great. Keep trying to keep the crew engaged. +1

I don't log in to the forums often, so I didn't see this ping until I decided to reply anyway. To get it out of the way first: I have always been a proponent of dividing engineering's labor better because I don't want them to be merged - you must be confusing my critique of your ideas in the past for critique of this one; we have butted heads in the past over your desire to merge the jobs, as shown on the easiest example I could find: I generally support the overall idea of division of labor between the jobs because I think a job merge is silly. 6x engineer on the manifest or alt titles that are ultimately meaningless. At least with tech and engineer there is some degree of "i dont have to deal with that" and "i cant do that". Now I'll get in to responding to the OP briefly and then at the end I'll outline what I actually logged in for in big old letters to keep it from being missed by skimmers. 1. Eh, neutral. 2. Like. A lot of people say "atmospherics technicians have less access to things than engineers!", which is true, but pointless because the things that technicians DO have access to are, with the exception of insulated gloves, far better than anything engineers have exclusive access to. Atmosphere control is incredibly valuable; RCON you press once and then never open it again. The RPED is the ultimate answer to any breached area and far surpasses anything an engineer can do with air pumps. By the way, power monitoring basically doesn't even work since A the subgrids have been remapped so many times with people adding things without cleanliness it's hard to tell what is attached to what substation and B you can't even get a full grid reading because for some reason the grids you can see varies depending on what deck you're on. Techs lose nothing and are better placed in their lane by removing their access to these things. 3. Like, generally. The INDRA gas modifications are only ever done by pipe monkeys because pipe monkeys are the only ones who care. On the other side of the coin, you can count the people who give a shit about modifying the supermatter on one hand. The "con" to this one is really non-existent; the supermatter has been kind of left out to dry ever since the phoron crisis made its primary funtime gas prohibitively expensive to use. 4. Neutral. 5. Fine, I guess, but let's not pretend the shields aren't another press-button-and-done lame activity like most of the engineer's exclusive things. The reason I pushed so hard for the INDRA to be engineer exclusive is because everything the engineer has is one and done or extremely lame. Have fun with your vendor virus while technician andy can spend a full round working on the thrusters if he so desires (and is not spoiled by meta monkeys). 6. No. The reason the chief engineer has exclusive access is because the radio logs of every channel are stored in telecommunications; this includes medical which can be relaying private medical information, or security, or whatever. The only way this can be acceptable is if the radio logs are moved somewhere more secure or access restricted; right now, they're neither. Now for big mode. This is the important part. As seen above most of Popper's proposed changes I have no issue with; keep that in mind for what I write below. However, Matt is working on skills right now. I think that this should be kept in mind because, to me, the skill system is the ultimate tidy solution to engineering's problems. I logged in to caution about too many changes to the department before the arrival of this system, because it may be that inefficient solutions are implemented that get underfoot unnecessarily and become redundant once skills arrive.

I echo these from my limited observations. I think a Leviathan-esque general overview and what-not-to-do sealed envelope in the bluespace drive would be sufficient for launch. A comprehensive guide on launch for a new feature is unnecessary and, in my opinion, unwelcome as it would drastically shorten the time before the device becomes as routine and "solved" as the supermatter. On a more practical note, the odds that the wiki maintainer team - eternally swamped and slow as it is (I say this with no malice having been a longtime member of it) - will be able to get a quality guide out in any reasonable timeframe for launch is not impossible but generally unlikely. I'd really rather not either hold up the bluespace drive's full implementation unnecessarily or force the developer to write a guide for it just to add a new engineering feature when engineering is in such an apocalyptic feature drought as it is. On the other hand, I think a general bullet point overview envelope for a "new model bluespace drive" is a very reasonable ask especially for a device with such a large catastrophe if it fails too hard. To prevent any misunderstandings - I certainly believe that a full guide will come at some point and would be useful. I simply do not think it should be comprehensive at all within the first week or so of launch to allow a fair shot for all players to get to toy with it without their more wired-in peers having a chance to spoil the surprise, as it were.

The odyssey test today was the most fun I've had with SS13 in some time, and even the simplest variations on an away site can make the content dynamic enough to remain interesting. The fact that we have canon things to actually do outside of events is also wonderful in a way that I cannot put in to eloquent speech, so here's something more basic: It's very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very very good. Apologies to the Aurora users who still read out loud for having to parse that sentence. Hopefully you have a glass of water nearby, or more likely, monster energy. My notes- not even criticism really - is that today's test was rather long, and it felt like it was closer to the 3 hour mark by the time the round ended. For a good round such as that, it wasn't really an issue - however, expectations may need to be adjusted and communications made if this is expected to be more common. I'm not sure how broad the timeframes are for the varying Odyssey events, but I am guessing that they will tend towards being longer than we are used to. Furthermore if most Odyssey scenarios take place off-ship some rules need to be put in place about Intrepid use - it may honestly be time to take it away from Science and give them something else, as the incident with the Intrepid today (being flown in to meteors at round start by science) was, well, not good. If this has been established elsewhere in the feedback thread, my apologies.

Giving them to bridge crew as optional non-police bodycam-flavored items (e.g just a shoulder cam or something) instead would neatly sidestep the problem of antag balance while giving BCs more opportunity to act as command liaisons for busy command; if nothing else as a command main I know I would find them quite useful since not every round is highpop enough to have a significant command roster. Worth considering, at least, even if there's always the possibility no one else bothers to use it.

I don't play medical and don't like the stairs PR either. I think that hoverbeds are a stupid overdesigned concept in a setting where Elyran anti-gravity tech is supposed to be cutting edge and even without the Elyra example they are out of place if you look at what else on the Horizon employs such an advanced solution for such a mundane problem (little). The PR would be far more tolerable if intent or move mode affected whether or not you spill your crate contents everywhere; I guarantee you that even a pasty nerd such as I can get a lidded crate up a flight of stairs or down without it exploding given enough caution.

While I really don't play security and cannot comment on the balance proposal here, I do want to comment on one thing: I'm going to pick on NoI4 here even though it's a sentiment more widespread since it's a pretty succinct example of the thing I want to talk about. I'd like to throw my lot in with those who have (usually indirectly) mentioned the following thing in this thread: I play engineering because I do not want to directly interact with antags. I really don't have any interest in directly fragbraining (to borrow a little bit of terminology from the quoted post) with the crew armory and would prefer for security to monopolize their direct attention. Am I happy to clean up an antag's ship damage? Yeah. Generally speaking, though, the last thing I ever want to do is interact with an antagonist directly as I pretty much never find their gimmicks more engaging than the alternative of speaking with my department cohort or working on some project I have. Does this opinion deny the existence of people who don't play security but still really want to mess with an antag for whatever reason? No, they exist. I just want to add my stone to the pile on the team of people who really would prefer direct antag interaction to remain the remit of security as, while I acknowledge their necessity as a driver of the gameplay loop and have no hate for those who play them, generally speaking being directly involved in their gimmicks is a net negative to a round for me. All of this is to say that the argument of the security armory being so powerful shutting down the crew's ability to interact with the antag directly is not something that everyone sees as a bad thing. I don't know if the majority or a minority of players think of the issue as I do, but as evidenced from this thread alone there is at least more than one person who feels this way.

I play a lot of engineering. I'm just one guy. I don't want to see this change go through, so I'll voice my thoughts as they are to be taken or left by anyone who may consider implementing this in practice. Machinists should remain in ops. What does every order a chief medical officer give to their department ultimately further? The health of the crew. What does every order a head of security give to to their department ultimately further? The maintenance of order and adherence to SOP. What does every order an operations manager give to their department ultimately further? The provision of supplies to the ship. Were machinists added to engineering, the chief engineer's orders would also concern the provision of supplies to the ship or the health of the synthetic crew (mostly, the former) instead of the maintenance of ship infrastructure. It would also imply that a chief engineer could have specialized as a machinist before their current position, which is weird. Machinists are a misfit job, but the closest places they have to home are research or ops. Research can build their own machines too, and ops distributes supplies. Instead of entirely being out of place, putting them in one of these two only gives them a little bit of non-overlap compared to total. You will have zero reason to communicate with the rest of your department in engineering, as well. I cannot envision nor have I experienced a single time that an engineer would need to call a machinist for anything that should be on a department channel. Engineering has enough disparate fields, imo; dealing with synths should stay strictly in the realm of research and the misfit job.

If they're restricted to rev antags, I get it. Revs get to do noncanon overbearing SCC actions all the time to get the round going, so I don't have any objection there (with the caveat that I intentionally avoid the round type, so I can't speak on if it'd be good) For CCIA, not really interested at all. I played some of the Aurora, but not enough to really get an idea of how it felt day to day; I can tell you however on the other hand that the Horizon does not feel dystopian enough for these things (loyalty implants, borging) to not feel out of place. Just my 2 cents on the matter.

What do you think I'm proposing? Genuine and non-sarcastic answer because if I'm reading your reply correctly this is exactly what I want.

Instead of from date of slot creation, have the timer for a character's name becoming unchangeable start from the first round they are played on, ghost or otherwise. It makes it easier to work on a character concept over a long period of time this way and from my view has no loss of the intended effect from the name lock. Sometimes I revisit character concepts and find that the name I selected at the start was not appropriate for the character I am trying to make. Since the above may be a bit poorly written (it sounds overly complex to me), I will express it in simple terms: Currently: Character slot names become unchangeable after a period of time starting from when the name is input and saved. Proposal: Character slot names become unchangeable after a period of time (roughly a week, how it is now) starting from the first round the character is played.

I'm not really concerned the change itself, so don't take this post as a negative on it as a whole. However, I do feel it's relevant to point out the following because it's described as necessary: Upgrading the SMES is a noob trap that only exists because we teach people to do it in engineering. You don't actually "need" to do it at all. You can have better performance while skipping it. Just set its in and out to max then turn on the breaker bypass and set the RCON, which most people do anyway. You now have a better output capacity and with each department running off its own SMES the small amount of extra battery space provided by the main SMES is negligible, and if it really bothers you you can still just add a few more capacitance coils without taking the eons required to disassemble it. Hopefully that helps people out before this change goes through or if it doesn't go through at all.

This is what the thrusters are. Given that cold phoron works fine and we even lived with the nornal burn chamber method for a while, they are nonvital. Even most thruster upgrades aren't used much. They're for fun. Engineers don't really get to play with them; everything short of staff bwoinking has been set up to ensure that pretty much. Anyway, without saying whether they *should* be merged, it's difficult to debate the topic without taking in to account given the two maintainer posts on the original PR and the fact that atmos tech has been on a knife edge. It's a simple fact that the more shared equipment and duties of the jobs the more likely they are to get merged together (or cause other problems). Are insulated gloves alone really going to cause such problems? No, probably not - but they're still a step in that direction, just a rather small one. Personally, I'm always in support of separating the equipment and jobs more, and was happy to see pipe wrenches go from engineers. As it stands, until the INDRA was added recently, atmos techs were really just engineer plus, and I say this as someone who played atmos tech. You traded Tesla access for thruster access (infinitely more in depth mechanics), an rpd, atmos control access, and a better hardsuit (radiation is less common a threat than big ass fires, and for a while rad protection was buggy anyway). The way I see it, insuls being removed helps dial that back down, though ultimately if they come back I'm not going to weep as they're relatively small in the grand scheme of things and don't matter overmuch. There does come a point where too much equipment can be stripped away in the name of differentiation to where it negatively impacts the role, but having played gloveless tech, I did not feel that was the case. It was only irritating when people expected me to act like an engineer instead of a technician, or during lowpop where all bets are off. This post has a lot of different points worth talking about but several individual quotes is annoying on mobile, so I'm responding to it as a blob. Firstly, physician and surgeon have OOC mod enforcement of job separation which tech/engineer does not have. There is no Engineering Guide Chart on the wiki, and thank god for it. Therefore, role differentiation is entirely based on starting equipment and player behavior. It's a bad comparison. Hell, several staff would probably rather merge them than bother oocly enforcing it. Secondly, equating pipes to wire. This one works a bit better but they're still different. The major thing that separates atmos techs from engis with regards to pipes should be knowledge; the average engi barely cares enough to learn the difference between supply and scrub and anything beyond that is a bonus. This system isn't one hundred percent reliable, but remember we live in a world without skills or OOC enforcement, so it works well enough. Wires, on the other hand, are mastered as soon as one is able to click on a knot instead of a tile. The RPD also makes techs vastly superior at interacting with pipes to a degree that cannot be understated. A shame about you not liking your own PR. I genuinely thought it wasn't a bad idea. Not sure how the buggers got pipe wrenches in the first place. Ultimately, insulated gloves aren't a super huge issue for me, but I think techs are better off without, especially given that the lack of OOC restriction means that if truly necessary their fellow engineers, the chief engineer, the captain, or a well placed emitter can get them what they need. Lowpop is always a wild zone, and so while the argument that they should spawn with them then is valid, I'm not sure whether it should be developed around that.

Putting aside whether this should be implemented, I wish to state the following firmly: Pages under wiki maintainer jurisdiction (i.e not lore) should reflect the game; the game should not reflect the wiki. The idea presented needs to stand on its own without any relation to what the wiki says.

I suggest thinking about the engineering department in a space program sort of way. Engineers are one of the two closest approximations of actual modern astronauts. A NASA mission specialist is a broad category but generally boils down to aurora-type engineering and research, both of which our engineers do. Even putting out of our minds the engineers who do things like tweak propulsion to increase thrust, every single engineer is involved in research to a degree because the Tesla is an experimental engine - probably. It certainly was at some point, but since it has no lore whether it still is is technically up for debate. Naval engineers are also a good way to think about it, given that we are on a ship. Even completely civilian ships have a chief engineer who maintains the ship; it is true that those individuals don't require a doctorate program, but they're also dealing with water instead of space, so given the infinitely more hostile nature of a vacuum an increase in education seems appropriate. I don't particularly want to call out the space mechanic archetype that is so pervasive in engineering because even I think it's a fun archetype to play and interact with. However, it's reasonable to assume that working on a ship like the Horizon would require a lot of experience or a lot of education and the space mechanic archetype often (but not always!) seems to forget that, and I feel like lowering the education requirements would encourage the space mechanic archetype even more than it already does while limiting the astronaut-esque archetype.

When I first wrote my support for Kyres' application, I specified that I reserved the right to change my mind based on further discussion, and now I exercise that. Convenient for me, then, that he withdrew his application and made the decision making process much smoother. From the outset I felt that Trio and Kyres were the two best representatives of the direction I wanted to see lore go in in the future. I posted early to make sure I wouldn't forget even though in retrospect I wish I had given it more time - but enough about that, all of that is setup for the following two points: 1. I've worked with Trio on the wiki team, and his Unathi work seems to have been pretty good now that I've actually bothered to read some of it. I especially liked the recent articles, and he has my support, especially with a desire to expand on megacorporations. 2. Given that Biesel is the exclusive remit of loremasters to my understanding, I was hoping for something a bit different. My opposition to Biesel's lack of development and general status of the new player planet subdivides in to two things: 1. Biesel is a terrible candidate for a new player planet. New player planets should have cultures that are generally isolated from the rest of the spur but are not afraid of it; it should facilitate a new player playing a generally ignorant but well-meaning character who has a justification for knowing little and asking much about aliens and nations. This ideal culture would be rural and, again, relatively isolated; Biesel is the opposite of both of these. A Biesellite never having seen a Tajara before makes no sense given that, to my recollection, prominent public officials - ones likely to appear on video broadcasts if nothing else - have been Tajaran. Pre-rework Vysoka was an excellent place for this (though I hasten to add that I am happy with its post-rework state). 2. In far fewer words, Biesel is the headquarters of the powerful organization we work for and a not-insignificant player on the galactic stage due to its economic backing, on top of being extremely cosmopolitan with a mix of different cultures. I think relegating such a location to the noob planet is less than ideal. Ultimately this isn't really a huge issue for me no matter how it goes, but it's something that I was disappointed with, and I wanted to provide my thoughts on it for your consideration, should you be accepted. I reiterate my support and apologize for the length of this forum post on an SS13 lore developer application; if I had had more time, I would have made it shorter.

I noticed in your original post that you intend to work more on the phoron scarcity. It felt like Orchard Moon was intended to ameliorate the phoron scarcity to a degree so that other things could take the focus - I seem to recall Cael saying as much at one point, but I have no will to go sifting through discord logs to confirm that at the moment. Either way, my question: do you intend to play it up again? Could you elaborate on this? I don't necessarily mean expanding your point - though feel free - it's more that I don't know what you're trying to communicate here and I want to. "Insufferable to a character" is what is confusing me the most, and I'm not sure what it has to do with either the first half of the quoted excerpt or the sentences that precede and follow. Could you talk more about the abundance of origins? I imagine you intend to slow or halt new ones altogether. Does that include expansions to existing areas, or just entirely new content? I'd like the answer to that question, but also for you to speak more generally about it. As for my most pressing question: Where do you want Biesel's lore to go? I like the idea of the Republic, but it seems from my perspective that the main new and exciting things being added to it are planets that it's taking from collapsed Sol. Do you foresee any reworks to existing content (vague nonsolid ideas are fine)? Do you feel that SCC and Republic lore are inherently intertwined? Obviously Biesel is and will always be attached to the SCC in some form and to a lesser extent vice versa, but more in the sense of one having lore developments without the other's involvement. I'm definitely keeping an eye on Cael's current article series and the shakeups that lore's been doing to the Republic/SCC related pages, but I imagine that most of the content hasn't been released yet. Most of these questions are to sate my own curiosity. As it stands, I feel like while I have some stark differences in some areas, after reading all the currently open applications my hopes for the lore's direction most closely aligns with yours. I'm going to reserve the right to change my mind in case further replies from other applicants or in your thread change things, but as of right now you have my vote. You've certainly got the drive and interest to do it, even if you do go a bit overboard or rush in to things at times.

Thou shalt not cook. Anyway, I'm going to refrain from really commenting on the Leviathan's role in shutting or not shutting down ship v ship combat as I haven't been playing so much recently and while I have been present for the majority of ship v ship rounds, it's a narrow majority. Instead, I'm just going to comment on something I do know about - or at least think I do. This hasn't been true in my experience. The above quote might just be a bit of intentional hyperbole, but from what I remember setting the Tesla output to bypass with an average 20 ball setup is enough for a Leviathan shot around 00:40. I'd be interested if anyone were to do some objective tests, even if it were to prove me wrong, as it'd go a long way towards settling the matter. I did read the rest of the post, but while I remain active in the community my finger hasn't been on the pulse of the server like it used to be. For what it's worth, I'd prefer to avoid any retcon.

I felt this went without saying when I read your first post, but to clarify: Engineers having to hack their way in to areas that need repair when no one is available to let them in is so common as to be ubiquitous. None of the access they would lose would compromise their ability to repair atmospherics; it would compromise their ability to increase the department's efficiency in the manner that an atmospherics technician would. As for the second post, the surgeries camo was likely referring to were the surgeon only surgeries, such as limb replacements or most organ repairs. Those can be found on the surgery chart (bleh) on the surgery page which is linked to in your post. Physicians are not allowed to perform those even if necessary - the part of the physician wiki page that you quote refers to the general division of labor of medical. Anyway, medical is really not relevant and I hope that that satisfactorily concludes the thread's diversion in to that topic. The most relevant part of this reply is the first half, and in fact engineers have to hack in to atmospherics under the status quo. The thruster doors being open to all is probably an oversight that was allowed to remain because of how commonly engineers found their way inside the nacelles, but every door before it requires an engineer to hack or otherwise break in. I have heard that there is some circuitous route that allows access to atmospherics unintentionally, but the simple fact that the main doors bar engineers is evidence enough to my point. I would like to add for any other readers that I would honestly also suggest for the blast doors in the thruster nacelles to be atmospheric technician ID locked if the ID locking is pursued; I left this out of the original post because I was aiming for brevity to encourage people to read it and understand it in full, and also because I felt the OP was sufficient to accomplish the goals on its own.

I've seen the suggestion to merge atmospheric technicians and engineers brought out repeatedly over the past several months, and those who partake in those discussions know that I am generally speaking a staunch opponent to the idea. It has been made clear that administration have no interest in alt-titles being permitted as an excuse for one to not do certain parts of a role's job - I understand that the electrician alt title was especially notorious for this issue. Therefore, any merger of atmos tech and engineer then must be, fundamentally, only one job with a thin veneer of difference. As I illustrated in serious discussion, this merger is in my eyes undesirable for several reasons, including the following: A job that is expected to interface with specific mechanics means that the character must be expected to either learn how to interface with those mechanics or already know. Merging atmospherics technician and engineer will mean that engineers will be expected to know how to interface with pipes in an intermediate manner. The alternative is that no one will be expected to know how to interface with pipes in an intermediate manner, and this is unlikely because breaches often cause pipe damage that requires vent placement or scrubber placement, and the benefits of minor upgrades are unlikely to go ignored because the knowledge will not immediately disappear from the playerbase - this will cause some engineers as well as outside observers to begin to expect the upgraded performance. Alt-titles provide no fundamental differentiation in a job's knowledge expectation on Aurora, and therefore are completely pointless beyond personal character flavor. They will not remove the knowledge expectation. They will likely only make it worse. It is unhealthy for a department with as many deep mechanics as engineering to encourage characters who know all of it, both from an OOC and IC standpoint. The OOC irritation has been established in #2 - and with many engineering players' tales of irritating bridge crew - but justifying all that education for a character forces a character to be hypercompetent just because of how, in character, these disciplines are not only unrelated but also extremely complicated. At present, the two jobs allow one to interact primarily only with the mechanics of the department they enjoy. Many engineers loathe pipes. A few rare cryptid players love pipes and find repair work trite. This should be expanded on instead of quashed, as nothing is really lost from doing so. Engineering would be better served by further differentiating its two roles, not by merging them in to what would be in practice super-engineers. The alt-title is all well and good until it's all hands on deck and there is no longer a meaningful differentiation of labor. To carry out this differentiation, I propose the following: An easy method of injecting pure, cold phoron in to the thrusters that is able to be done by engineers with little IC or OOC knowledge. This is already partially in place, but a way to carry it out without engineers having to set foot in atmospherics would be preferable. Locking the atmospheric tank control computers behind atmospheric technician access. For those unfamiliar, these are the computers next to the giant gas tanks that change their pressure output level and are mandatory for distribution upgrades. Editing to wiki articles to encourage players to differentiate their roles better. I can carry this out myself and plan to do so on the soon-to-be-revitalized Guide to Thrusters, and can easily carry it out elsewhere. As an aside to this, atmospheric technicians are generally treated as "engineer but different" because that's how they're played as or seen as by many. I feel like illustrating that this is not to be done is sufficient enough to change the culture without really requiring too much immediate moderation influence. I myself have delegated different tasks to capable techs in the past to great effect, because they already have tools that the engineer does not if they know how to use them. Finally, before submitting this topic, I have three things I want to cover, each in bold and placed at the end so they're more likely to be read: Differentiating the jobs further would not create a situation akin to medical where the department is hamstrung because a role is missing. Engineers already carry on without atmos techs in the status quo - techs just make the department better. A lack of them does not make the current status quo worse. Whatever differentiation is done, it does not need necessarily to be the above proposal. Half of this post is an argument against the merge - I just dislike suggestions that don't offer a way forward with whatever they're suggesting. Finally, if you intend to skim this post, I suggest skimming the proposal and reading the argument against the merge more deeply.

Catsin's been a really productive member of the wiki team, but what I imagine is more relevant for a staff application is that the fellow has always been very receptive to feedback and working as a group. I can't imagine CCIA would be disappointed with having them.

Thanks for offering to pitch in. I don't handle the final acceptance of these applications, but I do have a few simple things I'd like to talk about here: 1. By the gameplay guide articles, do you mean e.g the Guide to Medicine, Xenobiology, etcetera or the job pages proper? 2. We've had a big issue in the past with people going ghost on the wiki maint team. Periods of inactivity are fine - it's a much more lax environment than the other staff sections - but now that I've been made senior janitor maintainer we will expect at least the bare minimum, that being a notification of low activity and a rough timeframe idea. Not to say I foresee it being an issue here, of course, but I did want to let you (and everybody else) know from the very beginning that if your activity starts winding down then that's fine, but you need to tell us. This is the most important thing of the points I have. 3. I don't think it's been posted publicly, but we have an internal document that's much more helpful than the current regulation page. I imagine it's going to become more binding soon, so just a heads up on that. There's nothing too drastically different from my #2 point, though there are a few procedure changes that may or may not make it in (e.g requiring senior wikiman permission to create a brand new page). That's most of what I wanted to talk about to you directly. Other than that, I support the application.

I like what you've got already, but as an addition: if you could make the phoron, hydrogen, and carbon dioxide tank outputs start off instead of on, that would be really helpful and allow us a lot more room to move things around without compromising any default functionality. Right now, phoron, hydrogen, CO2 etc have the console output set to where the vents will automatically fill any line they're connected to to at least 2000kpa, meaning any line that isn't already separated by a valve or something similar will already be full of gas by the time you get to it and therefore way harder to modify. If output started off instead, that would be ideal. Pretty much every engineer that knows how to do anything in atmos control knows to turn output up and on, so it wouldn't make anything harder for newbies either. A 100% benefit, imo. O2 and N2 can stay how they are since those affect the air mix tank as well.

I personally believe that if the roundstart work was removed then there wouldn't be anything ever added to replace it. Promises or implications of future development to iterate on engineering gameplay once what it already has is removed are not the most reliable things in the world - not because of any implication that anyone promising it would be dishonest, but simply from the fact that SS13 development has this kind of story playing out often: a volunteer developer suggests and begins work on a project to overhaul a system or implement a new one, but because they are a volunteer and an individual with their own life and motivation levels, never finishes it. I feel it is far more likely that if engineering lost what it has now, nothing would ever be implemented to replace it unless those implementations are completed and ready to be made from the very beginning or very close to it. The development cycle of SS13 by its nature as a volunteer project is just not reliable enough, in my personal view. I don't really have any investment in the offship issue at all and therefore don't have anything to say about proposed solutions. I will say that docking codes seem more sensible as a solution to prevent unwanted offship docking. I would also like to mention here something that I neglected to mention in my original post, which applies more as a comment to the general readers of this thread than it does as a reply to Kyres. As someone who plays engineering extremely often, there is no room for modification once an engineering system is on. You need to disable it in some way and make it stop working before you can make changes to it, with no exceptions. Thrusters, Tesla (can't actually be turned off or turned back on again without a lot of things that I will not mention here), SM. The shields would count, but you can't change those. Typically, this disable/re-enable process takes a long time, long enough to where the benefit would be pointless before the round ticks over.