# Surgery Refactor - Context Buttons & Nodes
<span style="color:red"> **[INPUT WANTED]**</span>
You should be able to comment on this document by highlighting blocks of text or replying to existing comment chains - please do!
## 1.0 Abstract
To perform surgery under the intents system players click on people whilst holding surgical instruments with their intent, targeted location, choice of instrument and patient state determining the outcome. The code behind this system relies largely on else-if chains split across each of the different surgical tools: while this structure is completely suitable for a certain level of complexity, successive feature developments have lent it an interconnectedness which makes it difficult to add new content to.
Through implementation of context buttons, players perform surgery by clicking buttons that appear around them whilst performing surgery. Surgery steps are re-implemented as a nodal network: the code behind this system is easier to read, maintain and add new features to.
## 2.0 Goals
1. Make surgery code maintainable and readable, facilitating the development of future surgery content.
- Linked to subgoals A, C, D, E
2. Implement context buttons as the main way to perform surgery.
- Tools, intents and target locations can be included as optional conditions or checks, but not as a core part of the implementation.
- Linked to subgoals B, F
Aspirational sub-goals ("nice-to-haves") are listed in section 7.0.
## 3.0 Non-Goals
1. Make major changes to current balance; major balance changes can be handled in future PRs.
2. Add new features (other than context buttons); expansion of medical content can be handled in future PRs.
## 4.0 Content
### 4.1 Frontend (player-facing)
Players initiate surgery by clicking a suitable patient (operating table, prone on bed etc.) with one of the four core surgical tools: scalpel, spoon, saw or scissors. For practical reasons pry, cautery and suture surgery will not open up the menu.
Initiating surgery brings up an initial context menu, showing different body areas available for surgery (head, torso, arms, etc.). Available body areas may differ based on the condition of the patient (missing limbs, mutant race, etc.). This initial context menu can be navigated with anything in hand.
Clicking on a body area brings up the first surgery context menu. A number of icons are displayed of possible surgical actions that can be taken. These may have conditions to select succesfully: tool in hand, intent, targeted location, trait, reagent-present, etc. Some buttons may not be visible if certain conditions are not fulfilled. Selecting a surgical action will begin an action bar: the action will succeed if it fills, but it may fail due to unmet conditions, failure probability, interruption etc.
On a successful surgical action taken a tangible result occurs (animation, damage, blood, etc.) and successive contextual menus open up. In this way players navigate surgery menus until the surgery is complete or interrupted.
On a failed surgical action taken, a tangible result may occur (animation, damage, blood, etc.) and the context menu may stay open or a new context menu may open up. Depending on the context, surgery may be resumable from the menu, a previous menu or completely reset.
### 4.2 Backend (coder-facing)
Surgery steps are defined in nodes. For each node it is clearly defined:
- Possible transitions (next surgery step).
- Conditions required to make those transitions (tools, intent, targeting, bespoke).
- Icons and descriptions used for the relevant context menu.
- Tangible results from succeeding or failing the surgery.
Nodes are modular: adding a new surgery node to the network should require altering adjacent nodes only (unless desired for whatever reason).
The overall network needs to remain as understandable as possible even after significant feature bloat.
Some form of saving surgery state will be required.
### 4.3 GoonSurgery State Diagram
Initial architecture - <a href="https://viewer.diagrams.net/?tags=%7B%7D&highlight=0000ff&edit=_blank&layers=1&nav=1&title=FSM%20Diagram#Uhttps%3A%2F%2Fraw.githubusercontent.com%2FMetricDuck%2Fgoonstation%2Frefactor-surgerycontext%2Fcode%2Fmodules%2Fmedical%2FFSM%2520Diagram">Link</a>
## 5.0 Alternatives
- Tie surgery to holding a hemostat in one hand (same implementation as deconstructor) or an improvised alternative (belt/cable tourniquet?).
- Grey out unavailable buttons as opposed to hiding them.
- Pros: Maintains relative positions of buttons (consider a security officer performing headspider removal alongside the medical training example in 7.0).
- Cons: Feature bloat could crowd context menu
- Implement only structural code changes: leave context buttons for a potential future PR.
## 6.0 Potential Changes
- If players have a need to perform rapid surgery, special cases exactly replicating certain procedures with intents eg: combat debraining (1-cl-e-cl-e-cl-e-cl), headspider removal, appendicitis, implants could be added.
- Could allow context buttons AND direct clicking in some cases? [not all cases - Goal 2].
- If a large file defining each node individually is similarly impenetrable as the else-if chains, an alternate means of generating the network should be considered. Instead of defining each node, define the steps (a/b/c/d/e) for each surgery and auto-generate the network during initialisation.
- Pros: May make individual surgery paths more readable. May make it easier to contribute surgeries in separate files (modularity).
- Cons: May be harder to predict/understand network generated. Higher chance of redundancy between nodes. What to do in case of conflicts (ie: two icons specified for the same button) - would it overrite or would it split the network? Unless steps are fully genericised, we still need some definition at the nodal level. <sub>also christ knows how to implement this lol</sub>
- If context buttons and the full existing functionality are too uninutuitive together, intents and/or location targeting conditions could be scrapped entirely.
- If the context buttons provide too much information to the player (ie: surgery becomes a quick time event, press x to remove heart), 'red herring' surgery steps could be added.
- If too many surgery nodes are "uninteresting", resulting in context menus with only one button, the network could be simplified by keeping the buttons in the last interesting node.
- If the combination of context buttons and action bars obscures the players screen too much, the context buttons could be hid whilst the action bar is up or action bars could simply not be used.
## 7.0 Future content
Major balance changes and features are out of scope.
However, given that the purpose of these changes are to facilitate future development by others, some aspirational goals are presented below (highlighted in blue) with example ideas listed alongside (not necessarily GOOD ideas):
- <span style="color:blue">**A. Support balance tweaks.**</span> Support different base probabilities on different steps, as well as bespoke adjustment conditions for each base probability and bespoke failure consequences.
- <span style="color:blue">**B. Support interface screw on context buttons.**</span> Support conditional manipulation of icon states and context button layout. EG:
- If player lacks medical training, descriptions and icons could be obscured.
- If player is inebriated, buttons could move or swap.
- If player is on hallucinogenics, icons could be changed.
- <span style="color:blue">**C. Support mutant race development.**</span> May a require refactor of mutant race code to actually be feasible. EG:
- Tail surgery & bespoke organ configurations.
- Different surgical procedures and outcomes.
- <span style="color:blue">**D. Support circular network structures.**</span> EG:
- Exploratory surgery via looping through context menus.
- Implants and shrapnel could require a biopsy to locate and extract.
- <span style="color:blue">**E. Support development of new and more complex surgical procedures.**</span> EG:
- Some surgery could have multiple routes to complete depending on available equipment and training.
- Some steps could open minigames in TGUI windows.
- <span style="color:blue">**F. Support hidden/secret surgical procedures.**</span> Conditions on the context buttons showing up.
- <span style="color:blue">**G. Support weird stuff by doing all of the above.**</span> EG:
- Mimes performing a surgery with mimed instruments?
- Giving a grumpy skeleton a funny bone transplant?
- Living organs heckling you as you root around someone's innards, because they were drinking anima?