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.

+1 We like this one.

I didn't really understand how Aides couldn't already be flavored as bodyguards, personally. I like your contributions greenjoe, this one personally just doesn't quite jive with me for reasons that have already been stated (and that happens, so please don't sweat it too much!)

Prob(clamp((rand(75, 100) - ba) / 2, 0, 100)) every five minutes or so whether you get a message like "your brain feel fuzzy :)", lol

...I really like this fwiw

Currently WIP

Uniform vendors tbh. Clothes vending machines would keep all uniform pieces available (Id love them to vend stuff like department jackets, WINTER COATS, etc) and you can strip out all extraneous dept clothing from all lockers on the ship. (Plus... we have sprites for 3 varieties of vending machine for every single dept to choose from on-hand that match our style.)

This is currently test-merged. There's an insane number of structures, objects, machines, and items in this game, and it'll take me forever to trawl all the code of every single one personally. Therefore, I would be very grateful to the community for any help filling in more in-game documentation, by posting items or objects that could use additional Mechanics or Antagonist hints! (I am not currently adding many assembly/disassembly hints except to the most commonly built/broken objects- there's another rework behind this one to make that programmatic.) For mechanics hints, I am looking for objects which have special interactions (alt-, ctrl-, click-drag, etc.) which are not already listed, or which have functions or interactions with other objects that are useful/non-obvious. For antagonism hints, I am looking for objects which have unique mechanical antagonist interactions, or which can be effectively exploited by antagonists (for example, airlock crush and electrification wires). Please use the below format for any suggested tips: Object Name Mechanics - [Suggested mechanics hint 1.] - [Suggested mechanics hint 2.] Antagonism - [Suggested antagonist hint 1.] - [Suggested antagonist hint 2.] Feedback [Blah blah blah.]

Two more quick screengrab of current working version- critique for readability/clarity, problem of information overload. Initial examine Extended

So I've been playing on Aurora like three months, and this is a place with some seriously opaque mechanics, and it often demands I wiki dive or even code dive to figure out how to do something or if I even CAN do something. While people are very supportive of each other when it comes to helping with mechanics (since it seems like Everyone Suffers), ideally you should be able to examine an object and receive all the information you need about how to interact with it in any common capacity. While many objects do have some 'show additional information' text, it is not implemented consistently. There are several different types of information that would be very useful to have when examining objects, which I have broken down by function below: [Name] [Damage/Condition]* [Description] [Extended Description]** [Mechanics]** (how do i X) [Assembly/Disassembly]** (what tools to use) [Upgrades]** (science has a point?) [Antagonist Interactions]** (if the user is an antagonist/observer) [General Status/Feedback] * - If the object is damaged. ** - If the user clicks the '[Show in Chat]' button. This is currently a WIP. There is a PR for this where implementation feedback can be provided, but this forum thread is intended for UI feedback and how it looks/feels presents. I have laid some groundwork for this update already, and [Show in Chat] already gives you better information on many objects, but the following are some screenshots from both live in-game and my WIP branch for your consideration. Please disregard minor style differences between screenshots, they were taken at different times and stages.

Ckey/BYOND Username: batra Discord Name: batcountry Position Being Applied For: coder Past Experiences/Knowledge: Many years development for a major Neverwinter Nights persistent world as a 'core' staff member. This included coding, mapping, spriting, modeling, texturing, lore-writing, and advising on long-term planning and design. Also, being another spaghetti-filled volunteer-built server on a 20+ year old game, lots of untangling old baked-in weirdness in the code and engine. Examples of Past Work: All the Neverwinter Nights repos I've contributed to are private unfortunately, but here's some Aurora stuff: https://github.com/Aurorastation/Aurora.3/pull/20892 https://github.com/Aurorastation/Aurora.3/pull/20880 https://github.com/Aurorastation/Aurora.3/pull/20831 https://github.com/Aurorastation/Aurora.3/pull/20813 Additional Comments: As can be inferred above, I am very much a 'jack-of-all-trades' type developer- while I worked with plenty of excellent people who were far more skilled in any given domain, I tended to advise on the integrations between different roles/products of those roles. Being new to SS13 (barely over 3 months as of this application), I've had quite a bit of difficulty dealing with the engine and interface, and am as interested (if not moreso) in organizing, streamlining, and QoL improvements as I am in new features.