What is this?
Its claude explaining how goob station surgery is different to the vanilla wizardsden system.
TL;DR
Goob's "surgery" isn't a minigame — it's the visible tip of Shitmed, a full body-simulation overhaul (wounds, traumas, pain, consciousness) that replaces how every mob takes damage and dies. Porting it to your vanilla iss14 fork is two very different jobs:
Option A — Full Shitmed: Bring the whole stack (140 C# files + body-overhaul partial classes). Rewrites death/crit/blood and will fight your existing combat, cryo, and stamina features. Weeks of work, broad regression risk. Only worth it if "full Goob medical sim" is the actual goal.
Option B — Surgery on vanilla: Port just the surgery framework (step engine, tools, BUI, operating table) and rewrite the conditions/effects against vanilla damage. Gives you working limb/organ removal-and-reattach, but no bleeding-out drama. Safe, contained, lower payoff. It's a rewrite, not a copy-paste.
Option C — Phased (recommended): Phase 1 = Option B. Phase 2 = add a thin bleed/incision flag on your existing Bloodstream so "open → clamp → close" actually means something (60% of the drama for 5% of the cost). Phase 3 = optionally add the full sim later. Forward-compatible, doesn't destabilize what your fork already built.
Extras (independent of A/B/C, include or skip à la carte): Autodoc machine (skip for v1), xeno/heretic/exoskeleton surgeries (only if you run those antags/species), stasis table (cheap, nice) and abductor tools (only if you run abductors).
Shared by all paths: the asset import (21 RSI packs, 13 audio files, tool prototypes, locale, operating table) is mechanical and low-risk — the easy 20%. The hard 80% is the C# integration.
I asked claude:
I think about porting the Surgery system from goob-station into my iss14 fork. Checkout everything you need to give me an analysis what needs to happen to implement it.
and explain what features are actually inside the surgery system
And he answered:
The thing Goob calls "surgery" is Shitmed — a full medical overhaul originating from CM14/Backmen, not a self-contained "surgery minigame." Surgery is the interface to a much larger body-simulation rewrite. That distinction is the whole story of this port.
Features inside it
The surgical procedure layer (the visible part):
Step-by-step operations performed through a BUI window on an operating table (or floor, slower). You pick a body part on a doll, pick a surgery, and execute ordered steps.
A real tool chain: scalpel → retractor → hemostat/cautery → bone saw/setter/gel → drill → stitches → tweezers. Each tool is a distinct component; the right tool must be held for each step, with tool quality affecting speed/success.
Surgeries defined in YAML as ordered step lists with conditions (18 condition types — is there an open incision? is a bleed present? is the part on a table? is the organ slotted?). The UI only shows steps whose conditions are currently met.
Procedures include: open/close incision, clamp bleeders, sever/reattach limbs, add/remove/affix organs, appendectomy, bone repair, larva removal, scar generation, tissue sampling.
Per-step effects: damage changes, emotes, entity spawns, cavity implantation, wound tending.
The body-simulation layer underneath (the reason it exists):
Wounds — injuries tracked per body part with severity, healing, and destruction, layered on top of vanilla Damageable.
Traumas — bone fractures, organ damage, internal vs. external bleeding.
Pain — pain accumulates from damage/steps, decays over time, feeds into…
Consciousness — a replacement for the simple Alive/Crit/Dead model; pain and organ state drive whether you pass out. Anesthesia matters here.
Custom organ behaviors — heart, liver, eyes, ears, brain (debraining), tail, with vital-organ logic and status-effect organs.
Body-part appearance/marking system — visual limb states, scars, surgical markings.
Extras bundled in Goob: Autodoc (programmable automated-surgery machine with its own multi-window UI), tourniquets, stasis operating table, abductor high-tech tools, heretic flesh-surgery, and xenomorph/exoskeleton procedures.
The core problem for your fork
Your iss14 baseline:
Vanilla Wizden body system, vanilla DamageableComponent, vanilla MobState (Alive/Crit/Dead). No wounds, no trauma, no pain, no consciousness.
You already have non-functional surgery tool entities (surgery.yml with a SurgeryTool tag) — cosmetic placeholders with no logic.
Goob's surgery does not sit cleanly on vanilla. It assumes Shitmed's WoundableComponent, TraumaComponent, ConsciousnessComponent, the _Shitmed/Body part/organ extensions, and SharedBodySystem partial-class overrides are all present. Conditions check for wounds/traumas/bleeds; steps create and clamp them; completion heals them. Strip those out and the surgery steps have nothing to read or write.
So this is not a module you drop in. It's one of two things:
Option A — Full Shitmed port (faithful Goob behavior)
Bring over the whole stack: _Shitmed/Surgery + _Shitmed/Body + _Shitmed/BodyEffects (Wounds, Traumas, Pain, Consciousness), the server/client systems, BUI, 3,700 lines of surgery YAML, wound/trauma prototypes, 21 RSI packs, 13 audio files, locale, and the operating table.
Scope: 140 C# files + the body-overhaul partial classes that modify vanilla SharedBodySystem/MobStateSystem/BloodstreamSystem behavior. This is the hard part — Shitmed doesn't just add files, it changes how every mob takes damage and dies.
Risk: high. It touches death, crit, blood, healing, defib, cryo, medical scanners, species body definitions, and your existing combat/stamina work. Expect conflicts with anything in your fork that reads MobState or damage directly.
Result: the real, full-fidelity surgery experience.
Option B — Surgery-on-vanilla (lean port)
Port only _Shitmed/Surgery + its tools/UI/prototypes, and replace the wound/trauma/pain/consciousness conditions with vanilla equivalents (e.g. incision state as a marker component, "bleeds" as a simple bleed flag on Bloodstream, skip pain/consciousness, gate steps on part presence + tool only).
Scope: much smaller, but it is rewriting, not porting — every condition and effect that references wounds/trauma/consciousness has to be re-expressed against vanilla damage. Roughly the Conditions/, Effects/, and Steps/ folders need rework.
Risk: moderate, contained to the surgery namespace; doesn't destabilize death/damage.
Result: limb/organ removal-and-reattach surgery that works, but without the injury simulation that makes Goob surgery matter. No "you're bleeding out on the table, clamp it."
My recommendation
Given your fork is vanilla Wizden and already carries discrete Goob ports (sprint, self-execution, etc.), Option B is the realistic path unless you specifically want the whole medical overhaul. Full Shitmed (Option A) effectively replaces your medical/death model and will fight your existing combat-stats, cryo-heals-the-dead, and stamina features — that's a multi-week integration with broad regression surface, not a feature port.
A sensible phased approach:
Phase 1 — Port the surgery framework (SharedSurgerySystem, steps, tools, BUI, operating table) and wire it to your existing tool entities, with conditions gated on part/organ presence + tool only. Goal: functional limb/organ manipulation.
Phase 2 — Add a lightweight bleed/incision state on top of vanilla Bloodstream so "open incision / clamp bleeders / close" has real meaning.
Phase 3 (optional) — Only if you want the full sim, layer in Wounds/Trauma/Pain/Consciousness as a deliberate medical overhaul, accepting it reworks death and crit.
A few things to decide before I'd write a concrete file-by-file plan:
How faithful do you want the port to be?
explain to me the three options detailed
Do you want the bundled extras, or just core surgery?
explain to me all options detailed
What should I produce next?
Just this analysis
You picked "explain everything in detail" rather than committing — so let me break down each option fully so you can decide with the full picture. No code, no plan yet.
The three fidelity options, in detail
Option A — Full Shitmed port
What you'd actually be bringing in. Shitmed isn't surgery bolted onto your body system; it is a replacement body system that happens to expose surgery. The port includes four interlocking subsystems:
Wounds (WoundableComponent, WoundComponent, WoundSystem.*) — every body part becomes "woundable." Damage no longer just adds a number to Damageable; it creates discrete wound entities with severity tiers, healing curves, and destruction thresholds. A slash to the arm is now a wound on the arm part, not 10 points of slash on the mob.
Traumas (TraumaComponent, TraumaSystem.Bones/.Organs) — broken bones, organ damage, internal bleeding. Bones can fracture and need setting; organs can be damaged and need repair.
Pain (PainSystem, NerveSystemComponent) — pain accumulates from wounds/traumas and from surgery steps, decays over time.
Consciousness (ConsciousnessComponent, ConsciousnessSystem) — this replaces the vanilla Alive/Critical/Dead MobState flow. Pain, blood loss, and vital-organ state drive a consciousness value that determines blackout and death. Anesthesia matters because an awake patient feels surgical pain and can pass out / take damage.
Why this is the expensive option. Those systems are delivered as partial-class overrides of vanilla systems — SharedBodySystem.Relay.cs, SharedBodySystem.PartAppearance.cs, BodySystem.VitalOrgans.cs, plus changes to how BloodstreamSystem and MobState behave. So adopting it changes the behavior of every mob in the game, not just surgical patients. It ripples into:
Death, crit, and revival — and therefore your cryo-heals-the-dead and defibrillator features.
Combat — your combat-stats history and sprint/stamina work both read damage/mobstate; they'd need re-validation against the new model.
Every species' body prototypes (Goob has 49 body files; humans, and any non-human species you support, all need woundable parts/organs defined or they break).
Medical tools — health analyzers, medkits, brute/burn auto-injectors all assume vanilla damage.
Bottom line on A: it's a fork-defining medical overhaul, not a feature. 140 surgery files plus the body-overhaul layer, weeks of integration, and a broad regression surface across death/combat/medical. You'd do this only if "iss14 has the full Goob medical sim" is itself the goal.
Option B — Surgery on vanilla damage (lean)
The idea. Keep your vanilla body, Damageable, and MobState untouched. Port only the surgery framework — the step engine, the tool components, the BUI window, the operating table — and rewrite the conditions and effects so they no longer reference wounds/trauma/pain/consciousness.
What ports cleanly (mostly mechanical translation):
SharedSurgerySystem + .Start + .Steps — the step-progression engine itself.
The tool layer (ScalpelComponent, RetractorComponent, HemostatComponent, etc. and ISurgeryToolComponent) — these key off held items and tool quality, which you already have.
The BUI: SurgeryWindow, SurgeryStepButton, SurgeryBui, the body-doll part selection.
Part-state markers (IncisionOpenComponent, SkinRetractedComponent, BonesOpenComponent, PartRemovedComponent, etc.) — these are just flag components and port as-is.
Add/Remove/Affix part and organ steps — these use the vanilla body containers, so limb removal and reattachment, organ extraction and insertion all work on your existing body system.
What you must rewrite, not port:
The 18 conditions — anything checking SurgeryBleedsPresentCondition, SurgeryTraumaPresentCondition, SurgeryWoundedCondition has no backing data. You'd reduce surgeries to gating on "is the part/organ present?" + "is the right tool held?" + the marker components.
The effects — SurgeryDamageChangeEffect can map to vanilla Damageable, but SurgeryTendWoundsEffect and the cavity/trauma effects need to be dropped or reduced to flat heals.
The 3,700 lines of surgery YAML must be pruned: every surgery step that references a wound/trauma/pain condition gets simplified or cut.
What you lose: the part that makes Goob surgery dramatic. No bleeding out on the table, no "clamp the bleeders before you lose the patient," no pain/consciousness management, no broken-bone setting with real consequences. Surgery becomes a competent limb/organ swap-and-repair tool — install/remove organs, reattach severed limbs, cosmetic incision steps — but not an injury simulation.
Bottom line on B: contained to the surgery namespace, doesn't touch death/combat, but it's genuinely a rewrite of the condition/effect layer, not a copy-paste. Smaller and safe, lower payoff.
Option C — Phased (my recommendation)
Not a different codebase — it's Option B as phase 1, with a path toward A's flavor without A's risk.
Phase 1 = Option B exactly. Get the framework, tools, BUI, operating table, and part/organ surgeries working on vanilla. This is the foundation either way, and it's independently shippable.
Phase 2 = a thin bleed/incision layer. Add just a bleed flag on top of vanilla BloodstreamComponent (which you already have) so "open incision → clamp bleeders → close" actually means something — an unclamped surgery causes bleeding. This buys back 60% of the drama for 5% of the cost, because Bloodstream already exists in your fork.
Phase 3 = optional full sim. Only if you later decide you want it, layer in Wounds/Trauma/Pain/Consciousness as a deliberate overhaul — knowing it reworks death and crit. Phases 1–2 don't block this; they're forward-compatible.
The reason this is the right default: phase 1 and 2 deliver a working, satisfying surgery feature without destabilizing the systems your fork already invested in (combat stats, cryo, stamina), and you keep the door open to A.
The extras, in detail
These are all independent of the fidelity choice — each is a separate sub-port you can include or skip regardless of A/B/C.
Autodoc machine. A programmable machine that performs surgeries automatically. It's a substantial extra: server AutodocSystem + a multi-window client UI (AutodocWindow, AutodocProgramWindow, AddStepWindow, PickSurgeryWindow) plus a safety-wire action and the autodoc.yml entity. It depends on the surgery framework being in place first, and it's only as capable as the surgeries you ported — under Option B it could only run the simplified procedures. Recommend: skip for v1, add later if wanted.
Xeno / heretic / exoskeleton surgeries. Antag- and species-specific content: xenomorph hybrid surgeries and larva removal (xeno.yml, xeno_steps.yml, xeno_human.yml, 900 lines), heretic flesh-surgery touchspell, and insectoid exoskeleton steps (ExoskeletonIncision/Open/Sawed). These only matter if your fork actually runs those antags/species — porting xeno surgery is pointless without xenos. Recommend: include only the ones whose content you already have.
Stasis table & abductor tools. The stasis operating table (slows metabolism / prevents decay during long operations — from CorvaxGoob) and the high-tech abductor toolset (energy scalpel, searing tool, bone manipulator — abductor antag gear). Both are pure content add-ons: easy to port, but the stasis table's metabolism-slowing leans on the body/metabolism model, and abductor tools are meaningless without the abductor antag. Recommend: stasis table is a nice cheap add; abductor tools only if you run abductors.
Core surgery only. Operating table + standard human tool chain + human surgeries. This is the minimum that's actually fun and the right target for a first cut.
The one thing every path shares
Regardless of A/B/C and extras, the asset import is the same and is low-risk: 21 RSI sprite packs, 13 audio files, the surgery tool prototypes, locale FTL, and the operating table structure all port directly. Your existing surgery.yml tool entities get replaced/extended with the real ones. That's the easy, mechanical 20% — the hard 80% is the C# system integration described above.
If you want, I can next turn any of these into a concrete file-by-file porting plan — just say which fidelity option and which extras, and I'll scope it precisely.