zha everything broken

Need to do a little math to figure out what values make sense, but yeah the behavior needs a quick QoL pass. My INITIAL thoughts: 1. Discharge rate and shift start charge should be semi-randomized per-device. You should always be reasonably near to full charge at shift start, and discharge rates should only vary enough to keep devices from dying in sync. 2. Program usage should impact charge, like Maxspells suggests. An engineer keeping their PDA alive on the alarms app in their pocket at all times, or Josie sending ~2-5 chat messages per minute, should both use more power than someone who leaves it idle in their bag the whole round.

Hey FYI regular crowbars Already Fit in the emergency box

I intend to have a dev diary on engineering stuff coming out Soon(tm)! There's still a handful of items I need to do some basic trials on locally, but I'm super stoked about the engi stuff myself. Post-roundstart activities like actual basebuilding.

yeah i have 0 interest developing for ss14, personally.

hell, it's about time. +1

Big +1 from me! Really excellent work from this one, and easy to talk to about it.

This. I would most likely have peaced out after discovering this place. Tails have more Vibes/Connotations, even if they ought not to, than something like an extra set of arms or similar for IPCs. It's like cat ears or what have you.

I really love this! There's an important distinction that need to be made here between an Exploitables Framework and a Consent Framework though, as one is a development concern and the other is a moderation concern. Using the word 'consent' for this changes Exploitables from a roleplay aid into something that also becomes an additional moderation subject. This would require a larger, separate discussion to pursue meaningfully. By logging into the server, a certain level of broad consent is understood (99% of antag rounds involve violence at some level, right?), and it comes down to having a community that has a basic level of mutual respect and trust to ensure everyone can feel comfortable and safe here on an OOC level. Even if someone fills in an entry as 'negative,' while a courteous antag would always do their best to avoid it, antag rounds Can be chaotic and shit happens and Sometimes you Need a human shield and there's only one to hand! If this is to be a consent framework, I believe 'positive' and 'negative' would need to be changed to 'yes' and 'no,' and the admins/moderators will need to step in to discuss and decide among themselves. All of the above is an important distinction to make between an Exploitables Framework and a Consent Framework, but I believe that if that discussion needs to take place, it would need to be its own thread in the future, as the latter would require the former to first be implemented. So, with that all out of the way, and because I'm a developer and not a moderator or admin (thank fuck), here's my thoughts on an exploitables framework implementation. For the best of both worlds: [Type] - [Pos/Neut/Neg] - [Notes (32 character max)] Example: Bribery - Pos - Money, Snowflake, Morta Blackmail - Pos - TCAF Deserter, '55 Torture - Neg - [blank] Kidnapping/Hostage - Neut - [blank] Yes, a 32-character maximum for notes means you won't be able to write up complex narrative hooks, but it's much much easier for antags to digest. Some Types would have Notes be optional (Torture), others would be required (Blackmail). If ya'll compile a comprehensive list of entries worth having for antags to reference, I'd love to implement this some time! So far: Kidnapping Torture Blackmail Extortion Bribery

Kano seems to be some sort of space warlock. +1

Lore Impact (Small/Medium/Large): Small-- impactful to Europan characters but nothing that drastically different. Species: Human Short Description: Exands on Europa's history, hydrology, government, technology, and culture, grounded in hard sci-fi. How will this be reflected on-station?: Europan characters have more to complain about. Does this addition do anything not achieved by what already exists? Noooooope. Do you understand that the project may change over time in ways you may not foresee once it is handed over to the Lore Team? Yuuuuuuup. Long Description: https://docs.google.com/document/d/1rxMrUNrpfQ1MvC-lAWFzNwbZg1vJFAJiI8JqridG5Ps (Three tabs/pages)

"Enviromental Systems Engineer" has the same repetition issue as the other: having "Systems Engineer" on one side of the aisle and "X Systems Engineer" on the other is misleading design. Envirocontroller, Envirocontrol Tech/Engi, Environment Control Tech, Atmodynamics Engineer, whatever you want to call it, just so long as you're not repeating yourself from elsewhere! As far as the engineering field goes IRL, there are as many rules of thumb to subscribe as far as distinguishing between Engs and Techs go as there are technical fields. Broadly speaking, conventional semantics would suggest that engineers design systems and techs operate them. However, there are too many conventions to argue that decidedly one way or another for all cases. Bear in mind that beyond the explicit goal of this change (provide engineering jobs flavorful alternative titles), you still have an implicit goal to uphold (job titles should uniquely and clearly describe the role they pertain to). The logic governing how we do that needs to follow for all possible cases: if we created three alt titles for every single role according to the same rubric as we do here, would a new player (you might laugh, but we exist) be able to look at the manifest and clearly identify what every character does? Because we don't have a RL convention to be forcibly chained to, a very obvious solution exists: make all Engineer alt titles end in "Engineer", and all Atmos Tech end with "Technician." But even that still leaves the issue of one role having implied highet education! And bear in mind too, that the explicit goal doesn't demand we rely on the existing alt title framework. We may want to have something like 'sub-titles' instead, parenthetical blocks appended to a job title that describes specialization (and, perhaps, a character can choose if they have certain skill levels in future.) Considering we don't know where maintainers weigh in on this yet though, you're probably best served not worrying about more title quibbles until they weigh in.

Whatever you change it to, so long as it doesn't have that same semantic repetition between engi/atmos please! Honestly, the big drawback to alt-titles is not being able to, at a glance, quickly identify who sits in which type of seat. Shitty example: every engineer alt-title having 'engineer' at the end, every atmos tech title having 'technician' at the end. Again, shitty example, but people who have never played any engineering at all should, ideally, be able to recognize whether or not someone can help them with the air or with the electricity.

Recommend replacement of Drive Systems Engineer -> 'Propulsion Engineer' due to semantic similarity to 'Systems Engineer', per Github comment?

Just posted a change request on the PR for a technical issue, but my thoughts on actual flavor are less firm so seemed better to drop them here. Re:Cats: To me, 'Reactor Engineer' suggests a more design/architecture role, whereas a technician is more an operator. While that argument can be applied more broadly to the entire role, I'd still lean towards 'reactor tech' over 'reactor eng'. I'm not super fussed by that one, both vibes are fine. Re:Ping: Echoing Popper & Cats in swapping out 'Shipboard Systems Engineer' with something else. As an alt-title its coupled a little too closely to 'Ship Engineer' by my thinking. I really am doing my best to resist going full ham, god i could happily wax poetic about imaginary engineering specialties all day if you let me

Suggested alt titles for Ship Engineer: - Maintenance Engineer - Reactor Technician - Electromechanic I don't think we should have something like 'Electrician'- these alt-titles aren't like Medical jobs, where each one has a distinct role. All these titles ought to sound like people who know the full range of the (engineering or atmospheric) systems for which the role is responsible. They ought to suggest additional expertise, not sole domain.