Sneakyranger

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.