Jump to content

zha everything broken

Developers
  • Posts

    28
  • Joined

  • Last visited

Linked Accounts

  • Byond CKey
    batra

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

zha everything broken's Achievements

Security Officer

Security Officer (6/37)

  1. 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
  2. Kano seems to be some sort of space warlock. +1
  3. 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)
      • 7
      • Like
  4. "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.
  5. 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.
  6. Recommend replacement of Drive Systems Engineer -> 'Propulsion Engineer' due to semantic similarity to 'Systems Engineer', per Github comment?
  7. 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
  8. 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.
  9. 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!)
  10. 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
  11. Currently WIP
  12. 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.)
  13. 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.]
×
×
  • Create New...