# Cyborgs
## Primer
- We'd like to move away from classic SS13 re: cyborgs
- As of now: Cyborgs are marginally powerful roundstart, utterly useless by roundend compared to a properly geared human. Unfun!
- Cyborgs are impossible to properly rebalance to not be a bag of hard counters vs overpowered gear due to security cyborg's existence
- Answer: Fully modularize cyborgs
- This will contain a lot of technical drafts, as this is also meant to basically show someone how to do things.
- Oh and we're going to fully refactor cyborgs in the process because 10 years of technical debt is not something we like here!
## TODO:
- how are we going to handle module selection?
- do we really want to take the choice of chassis selection away from the cyborg player's direct, immediate hands? drama? worth?
- UI - upgrades might have a lot of UI in the future
- maintenance panel needs thought, similar to rigsuits
- ui updates? we don't want to resend all data, all the time
- optimal: allow someone to tweak ui settings of components if they have access to internals?
- Combat: How do we balance not having hardstuns anymore?
- the realization hit that cyborgs having all tools for a role archetype makes them mildly op. not doing that, makes them kinda unfun. how are we solving this?
- intrinsics/upgrades are kinda mixed...
## Modular Robots
Every cyborg will consist of a chassis, and installed components.
Chassis are now printed out from the robotics fabricator as an empty chassis.
The chassis is constructed with steps akin to mecha construction.
Components are slotted in.
An intelligence core can be slotted in after the chassis is complete.
### Balancing
- Even without any components, or power, cyborgs should be able to make **some** sort of visual/audible feedback, so depowered cyborgs aren't completely stuck in black-screen hell
- Even without any components, or power, cyborgs should be able to have **some** kind of input from around themselves, for the same reason.
- Cyborgs **may** need to get the full four-intent system for humanoid chassis support.
## Chassis
// todo: rewrite
A cyborg's chassis determines what can be put in it.
A cyborg cannot swap chassis; To do that, you need to fully transfer things over from an existing chassis, including the intelligence core. The old chassis can be fully dismantled once the intelligence core is removed.
Chassis determines the base balancing for a cyborg - current cyborgs would be the "neutral" ones (and slightly buffed), more bulky, treaded ones could have more health, slower movement, and more complexity, while lighter ones like drones could be fast, but fragile.
Humanoid chassis would allow hand usage at the cost of being vulnerable to things like disarms and shoves.
Each chassis has stats of
- base health
- base movement types (mostly ground, some can have treaded/flight)
- base movement speed
- any base abilities
- Hands would be allowed on humanoid chassis
- Heavily limited for the most part, no combat usage, specific inventory restrictions depending on module?
- Combat abilities like being disarmable, having access to melee combat
BELOW 3 NEED THOUGHT; bitfield might/might not be enough, we do not know yet.
- allowed modules (bitfield)
- allowed integral components (bitfield)
- allowed upgrades (bitfield)
- Backplane stats:
- Weight support - amount of weight (chassis has some static weight as fluff, in code it's just "self weight" and "support weight") to support before movement is penalized
- Size - amount of size to allow for installing upgrades and items
- Complexity - Fluffed as "IO slots" - amount of complexity to allow for installing upgrades and items
- Base Power - modified by integral components, this is amount of power draw that is allowed. More on that later.
- Base Movement - speed, and modality
- Base health - modified by integral components
## Components
Some things that were previously modules will instead be components. Modules work on inventory system and it's all in all horrific.
This is technically powercreep.
Sue me, we can find a way to make silicon players cry later if we need to, because there's literally no excuse for shit QOL.
```
base class:
/obj/item/robot_component
probably will need hooks for:
- attachment
- detachment
- ui_data
- ui_static_data
- how to push ui data when needed? we want to be "lazy" and only push data when it changes!
- /obj/item/robot_component/proc/push_ui_data_to_host()?
probably will need base variables for:
- brute damage
- burn damage
probably will need, on the chassis/mob itself, procs for:
- can attach
- handling attachment of integral modules (will need either list or else-if istype chain)
- handling attachment
- handling detachment
```
We want to abstract components into two types:
- Integral: Not item-deploying components. Can't be duplicated, can fit into specific slots (occupying them, like if you made a shield slot that can fit either a personal or a bubble shield, but not both)
- the shield was just an example sorry :/
- Modules: Item-deploy components. "Provides" an item to the chassis which is then accessible with the usual chassis hardpoints.
### Integral
`/obj/item/robot_component/internal/integral`
Integral modules consist of:
- Armor - determines base protections
- damage is routed to this first, to an extent, more on that later
- Actuator - determines base mobility
- floating drone-types would probably require hover/repulsor-type actuators (?)
- Radio - determines network connectivity
- Remove the binary communication unit, it's utterly stupid. Binary channel stays but we're going to rework it someday(tm) anyways.
- Optics - gives vision, is how the AI connects
- Meson/thermal packages would be part of this.
- Sensor Suite - Base level of detection for various things, internal and external (integrated air sensor etc etc)
- Power Controller - Distributes power, provides emergency burst power, capacitor system, etc
- Maybe?? We want to abstract procs because this is somewhat hard to implement and can be done later.
### Upgrades
`/obj/item/robot_component/internal/upgrade`
Upgrade components are "one off" components that cannot be duplicated (they count as their own component class) and can provide various things like
- ion thrusters
- magnetic stabilizers (magboots)
- energy shielding
- bubble shielding
- various scanners
- etc
### Hardware
`/obj/item/robot_component/hardware`
Modules are the primary "item providing" components. They should exhibit **minimal** internal configuration UI if at all possible (UI has serious overhead; rigsuits will have a hard time doing this, and cyborgs will have an even worse time!)
They'll generally come in logical kits, as well as supporting "conflicts", e.g.
- Engineering intrinsic module for a full, upgraded toolset probably means you can't install a measly built-in crowbar; ruins the point
- Specific modules can blacklist certain hardware types and whatnot
- We don't want stuff like stun weaponry on most
- THIS REQUIRES THOUGHT; Bitfields allow only 24 types. We don't want to use expensive typecaches. Maybe bitlists? Etc etc.
## Modules
`/datum/robot_module`
Modules determine how a chassis is rendered (chassis should optimally be greyscaled, though since we can't resprite everything at once probably, we'll have to snowflake a way to make it work with hardcoded states for now).
Modules you can be is determined by chassis. Some chassis types won't support all modules.
Modules will:
- Provide a base set of powerful, role-specific hardware like RCDs + tools for engiborgs, surgical sets for medics, etc.
- Determine if you're locked out of certain component/upgrade choices (probably rare, as we're focusing on balance-via-item for modules here)
- Potentially touch backplane/chassis stats, but *hopefully not*; The entire point of chassis is to abstract this, so, if modules touch them (e.g. sec having more x less y) it should optimally be well abstracted and not be any super major differences.
- Include some base non-robot-component slot stuff
- service cyborg should probably have universal translation by default
- each type probably should have their department type by default
- This is what someone's base job is. While not technically enforced by rules, this choice should heavily influence what the code guides them to do, whether by advantages for their task or penalties for others'. We want a good bit of customization, but we don't want a module that's literally a jack of all trades.
- More on that later (hello, standard cyborg.)
### Considerations
- Resetting a module probably has to toss out all upgrades/whatnot. There should probably be a better system for this, because it's not particularly fun to have to re-insert **everything** manually.
- Same for chassis; depends on if chassis changes should be easy or hard.
## Backplane
This is, fluff-wise, called its backplane, but in reality, is probably just variables on its chassis type.
- Weight: Components that are powerful or situational may add weight. Weight can slow a cyborg down or outright halt it in extreme cases where its actuator can't support it, or might do things like make flying harder.
- Power: While not a "can you slot this in" mechanic, components may draw power when used/triggered/etc/whatever'd. Now, cyborgs will actually have a power management system. The backplane can provide x amount of power at a time; any more will fail or result in things running out of power.
- Slots: The bsaic measure of "how much extra can you pack"; this balances how much functions you can pack into one cyborg.
TBD; power will already be a mechanic on many things like RIGs and augments, we might not want to be too repetitive.
## Roundstart/Latejoin Cyborg
Roundstart/latejoining cyborgs, regardless of what we choose for chassis/module selections, will have a set of presets to choose from, that transform them into a given chassis + module archetype, along with an expanded set of automatically inserted gear by default.
This is because sitting around waiting for someone to upgrade you so you can play the game is kind of unfun, so we're only okay with making people miserable if they die/need a chassis replacement because they got gibbed or something, rather than punishing everyone who otherwise could play the game already.
## Defense/Combat
**Section heavily TBD.**
Hardstuns Suck!
Therefore;
EMPs:
- EMPs should disrupt modules and potentially cause outages/disruptions
- EMPs should drain power, but not so badly that it completely shorts people out instantly.
Power loss:
- Losing all power still will let you see (flickering display) + hear + talk (NO RADIO) + move (slowly). All modules are more or less disabled.
Component loss:
- We want to encourage being able to disable someone but not make it very easy to be stuck staring at a black screen.
- Losing camera nearly kills vision, but not entirely.
- Losing comms still kills your comms, duh.
- Losing armor is bad, more on that later.
- Losing actuator makes you unable to resist out of grabs/pulls/whatever. It should probably also actually stop you in place, but this is negotiable. Kinda.
- Losing power controller more or less is all of the above combined. Ouch?
- Losing sensor suite shorts out your sensors. Duh?
Module damage:
- Modules generally take damage from outer to in
- Not sure how we'll do this, but, deployed hardware should probably have an easier time being broken or even destroyed.
- Intrinsic module hardware can never be destroyed, only broken.
- Armor does better at shielding internal hardware until it's destroyed.
- More later, etc etc.
Hardware:
- Most hardware can be damaged or disabled through impacts
- Most non weaponized hardware shouldn't have high hit force, or be too powerful at combat at all. Most should probably be 10-15, with 15 being the rare module-only stuff
- Wanna fight? Do it indirectly, not by running at someone and clicking them horizontal.
Flashes:
- For now, I'm going to say flashs should act as a heavy disrupt + blind effect, potentially making attacking near impossible for a small duration of time.
- Flashes will remain for the **security**, and any other combat module until we decide what to do with it.
Disarming/Pushing:
- Disarming/pushing some chassis types will be viable
- Human chassis can outright be pushed down briefly and support disarms because.. uh, it has hands and that's kind of powerful??
Speed:
- Non combat cyborgs should have higher speed, potentially to *near* normal runspeed
- Combat cyborgs should be standardized to 2-2.5 (baystation 'jog' speed) by default. In return, we're going to draw on Shirumic's idea and make them tougher and better at combat. This totally won't be a horrible mistake!
- Add movement intent/speed settings >:)
- **Let non treaded/floating/flying chassis slip >:)**
General:
- Cyborgs should be hard to entirely destroy, but not be a 150 HP soaking thing that can keep hitting you (and your fleshy, baymed-inflicted body) until it runs out of the 150 HP. That's awful.
- Discourage combat; non combat modules should have very unwieldly tools for combat that either don't do a lot of damage or are hard to use. They're powerful role assistants, **not combat machines** (unless you play security but frankly eat your flash hardstun until we can balance 'able to hardstun others easily but can't be hardstunned themselves' tip we **can't**).
## Panel
**WARNING WARNING: UI SYSTEM NOT WELL DESIGNED. We need to be able to support tweaking modules BEFORE the cyborg is constructed!**
Cyborgs will have an unified TGUI panel to control their components and view things like sensor output.
Every component will have a ui_key to facilitate this, and have their ui data's sent as necessary (I can handle this when the time comes ~silicons)
Use ui_data(), ui_static_data(), ui_act() on the components to provide/request UI data/actions.
UI data will be **manually pushed, unless otherwise specified specifically.** Infact, to mitigate UI load, cyborgs will actually maintain a list of UIs that need constant updates. Otherwise, only manually sending data will work.
### Maintenance
- While a chassis is open, there should be some manner of modifying intrinsic values like which AI to link to, etc, before the intelligence is put in and the chassis is activated.
- More on that later, UI is going to be obnoxious.
## Misc
- Add encryption key slots to allow for accessing external channels.
- Add translation chips that allow for interpreting some channels. (Don't do this until we rework language, for now omni translator upgrades are fine.)
- Inventory bloat: Cyborgs have a lot of items. More might be a bad idea.
- Things like switchtool replacing 7 tools would be useful, etc.
- Basic packages should focus on switchtool-like objects to make it easier to inventory manage
- QOL - switching interface needs to be **fast** and **efficient.**
- how are we going to reconcile hands with stuff like grippers?
- flashlights? make intrinsic, but part of optics module or just a literal moduleless (but upgradeable with upgrades) for lighting system?
## BONUS: INVENTORY
probably need, much like synthesizers, managed inventory system to store specific kinds of items that modules can then access for things like medical/service borgs.
## BONUS: SYNTHESIZERS
probably rework material synthesizers to very high power draw intrinsics (material supplier/matter storage upgrades?)
- metal, glass for engineering (duh)
- cloth for medical for splints/healing
- tiny plastic synth for secborgs for cuffs
don't know where i'm going with this it's probably dumb i hate cyborg design i can feel my brain going numb
## Quick, Basic Outline For Potential Ideas
### Chassis
ngl writing this makes me realize chassis selection might be a bit lacking/awful
should make it easier to swap chassis or rethink this a bit, as the meta choices would probably be humanoid, standard/dogborg, and drone :/
- humanoid
- has hands
- slightly lower speed
- responds to target zone damage in exchange for *having hands*
- low weight compensation, but high slots
- floaty drone
- floats (DOES NOT FLY BY DEFAULT)
- runspeed
- more fragile
- medium slots
- spider
- treaded v2
- maintenance drone
- obviously only for maintenance drones
- doesn't float
- runspeed
- ventcrwals
- more fragile
- can't customize (don't interact with roboticists lol) but has a lot of everything
- standard
- normal cyborg experience-ish
- medium in everything, moderate slots
- dogborgs
- standard v2
- treaded
- slower
- slip immune
- tougher
- high slots
- roombas
- fast
- fragile
- low slots
### Modules
- all
- flash
- for those who aren't engineering, crowbar
- flashlight, as part of their intrinsics/optics (?)
- tape rolls for their departments
- dogborgs
- no more nose analyzer, that's literally rolled into your sensor suite
- cosmetic boop module. no combat function.
- jaws module may stay. nerf it to 5 and 10 damage. it isn't a balance issue
- cosmetic tongues + cleaning may stay, i'm not that hateful
- medical
- full surgical suite
- advanced, upgradeable health analyzer + human scanner multitool (how to implement upgrading innate hardware?)
- rollerbed rack
- advanced wound-tender (basically brute + burn kit), uses a specialized synthesized resource
- splints (same resource as above)
- gripper for non humanoids
- beaker/bottle/pill storage units
- ayo :D
- beaker/reagent multitool for dropper, syringe, weak sprayer (YES, SPRAYER), hypospray
- chemical synthesizer (sorry we aren't over magical chemicals yet) for bicaridine/kelotane/dexalin/dylovene/tricordrazine/inaprovaline/spaceacillin/parcetamol
- stabilizer module (ACTS LIKE CPR)
- refrigerated organ storage
- defib
- nerve pain inhibitor item from bay for surgery (?)
- inbuilt extinguisher
- engineering
- upgraded RCD with ability to fabricate simple circuits for things like alarms
- material synths for metal/glass/plastic/**water**
- ability to use synths as: metal sheets, glass sheets, plastic sheets, metal rods, floor tiles, reinforced glass sheets, cable coil
- 2x toolspeed switchtool with all tools
- inbuilt magpulse
- engineering gripper for engineering objects for non-humanoids
- upgraded sensor suite by default
- meson optics by default
- higher power flashlight
- geiger counter as part of sensor suite
- t-ray scanner as part of sensor suite
- high powered + capacity extinguisher
- inbuilt long ranged inducer
- inbuilt cell charger/siphon system
- low power plasma cutter
- floor painter
- RPD
- holotape
- light replacer
- more fire + pressure resistant
- security
- cuff synthesizer/whatever
- dual mode taser/disabler
- stunbaton
- forensics analyzer
- inbuilt voice recorder upgrade
- FUNNY MOMENT IDEA
- humanoid version has none of these, but storage slots for weapons + ability to use grab combat (but is able to be tipped and have its weapons wrestled out)
- probably don't actually do this we hate secborgs lol
- service (janitor rolled into this, it was a joke module.)
- inbuilt floor buffer upgrade for non drones
- mop (uses water synthesizer)
- UV light soap
- RSF (rapid service fabricator: paper, all kinds of glasses/mugs, plates/bowls, plastic forks/knoves/straws/whatever, anything else we can think about)
- hydroponics multitool (including for harvesting)
- sensor suite for hydro-trays + soil (examine to view)
- drink + beaker rack for cooking (?)
- 3 shakers (won't result in suicide bombs, i promise)
- food rack
- plant rack
- manipulation arm for cooking if not humanoid
- kitchen multitool
- light replacer
- inbuilt translator upgrade
- paperwork multitool
- research
- inbuilt gripper for science items
- nanopaste fabrication (OH NO)
- inbuilt laser deconstructive analyzer (sorry no more vore-deconstruction-only.)
- 0.75x toolspeed weak toolset
- xenoarch multitool
- excavation drill + weak plasma cutter
- RPED
- defib for synths
- literally anything else needed to do all synth maintenance
- xenobio multitool for slime baton + taser
- sensor suite can scan decon levels + slime stats on examine
- inbuilt cell charge/siphon system
- inbuilt extinguisher
- construction gripper for material sheets (no material synthesis/built in materials)
- salvage
- weak plasma cutter
- ore scanner
- gripper to set up drills with/etc
- pickaxe/drill
- shovel
- vertical bore
- weak 0.5 toolspeed toolset
- crate rack + hauler
- paperwork multitool
- storage modules + whatnot for materials and many item types
- RPD locked to disposals + logistics pipes
- magpulse
- more fire + pressure resistant
- ore bag
- ore box holder
- weak phoron bore (illegal upgrade, probably)
- KA (upgrade, probably)
- KC (upgrade, probably)
- resonator (upgrade, probably)
- standard
- basic toolset (0.5 toolspeed)
- extinguisher
- ????????????? LOL THIS MODULE NEVER MADE SENSE
- should we just make it unlocked (other than job-specific high power gear like RCDs) and make it a non-roundstart "create your own module" thing???
- probably not??
- combat (locked/ERT)
- personal shield upgrade / bubble shield upgrade
- laser projector
- stun arm
- i don't know lol i hate combat borgs
- maintenance drone
- all basic engineering tools
- no RCD
- all basic engineering materials
- port the cute TG model instead of the big ones or make it a choice between each (small & fast/ventcrwal or big & slow/has RCD + powerful gear)
- rethink why we have this because giving a lot of fun tools and telling someone to not touch other players is kind of stupid
- probably port all the weird stuff like strays/broken down drones/etc
### Intrinsics
- actuator: no swaps for now, movespeed op
- optics: choice between normal, meson-capable
- maybe a night-vision one that is weak to light (think the night vision aura but reversed when you're in light)
- can't really buff this, vision op
- sensor suite: probably should be upgraded via upgrades, see upgrades
- armor: heavier variants for a steep slot nerf + slowdown, lighter variants for a steep slot buff + mild speedup
- special shielding types?
- comms: maybe a long range one (not sure how that'd work) that would have high power/whatever cost?
- idk, telecomms needs refactored lol
- power controller
- overclocked, low efficiency
- nerfed, high efficiency
- ones with a "burst" capacitor so you can briefly go past normal limits?
### Upgrades
- generators
- solar
- phoron
- fuel
- language translation module
- size alteration module
- **No. More. VTEC.**
- Sorry. If people get upset, maybe we'll add an actuator upgrade. Seriously, no more VTEC. It's cancer, always has been, and always will be.
- health scanner, research scanner, etc, close + long range versions, slime scanner, etc, sensor suite filters for the above, etc etc whatever.
- magnetic traction module
- ion thruster module
- self repair upgrade
- **only compatible with non combat modules.**
- sorry ;)
- flashlight upgrades
- infrared vision? limited nvg? probably not, not thermals
- ~~sonar~~ lol do we really want intrinsic undetectable wallhack feature no this should be an item instead to replace material scanners
- speaking of which: you'll notice material scanner isn't mentioned. Yes, they're gone. Mining won't need them anymore and I'm enforcing my arbitrary requirements of "WALLHACKING IS ANTI FUN". Sonar is the replacement for limitless wallhacks.
- miniature synthesizers for certain materials like thread/fiber for medical sets
### Hardware
- inducer
- cell siphon/whatnot
- toolsets
- weak
- strong
- holo
- ones that only have basic tools
- light plasma cutters
- light drills
- light medical wound-tending toolsets
- crappier than mediborgs'
- crate mount hardpoints
- i don't even know dude everything seems module specific, we can make module hardware an addon but at that point why do we have modules
## EMAGGED MODULES/UPGRADES (FUN SECTION)
- emag hardcoded modules are dumb
- use normal hardware system;
- hacked cyborgs lose *most* of their restrictions of what can be slotted into them
- to buff non-roboticist antagonism i suppose they can keep their module specific emag module
- dogborgs lose their omni hardstun-tongue, sorry. maybe make it a robotics illegal module
- make all illegal modules like stunprods accessible by an emag borg queueing it or something idk i'm sleepy
## Non-maintainer notes section
Feel free to put ideas down here as ### YOURNAME - Idea title.
### Yeayea130 - Reworked Borg CC
Hardstuns are lame. everyone knows. borgs- when redone. shouldn't have to have them. ideally. or at bare minimum have very few ways to be hard CC'd.
Instead. making EMPS do things like
Easy : Apply confusion, apply vision overlay/accuracy penalty to everything.
More complicated : Actionspeed penalty. scramble equipped module order. screenflip temporarily to disorientate. Deactivate components that must be manually reactivated, aside from essential components such as Power Cell
Potentially bad idea : Apply Ion Law. Modify exsisting law.
Instead of their usual hardstun. may be ideal.
Flashes should blind and confuse. and then a disarm must be used to actually stun the borg?
(Please don't add Borgtipping. it basically invalidates borgs in other servers that have it. [Or. make specific module packs immune to it. ala security. to encourage more difference between them.])
### Yeayea130 - Borg Health direction Idea
Borg health is currently armor plating taking all damage before it's broken. (Aside from EMP's which pierce.) then you have 110 hitpoints left. but can get sniped in important components entirely due to RNG. resulting in you dying before that.
Any methods to mitigate this would be ideal- alternatively. being able to cripple other systems to bring essential components back online at a minimal level (after some time, to allow hard damage to disable borgs temporarily if you get lucky and don't want to totally destroy it) so that they can regain the ability to move.
### Yeayea130 - Borg Upgrades
Please. port some of the upgrades from main. Why don't we have borg self-repair upgrades. we should just make a bunch more upgrades. I can list some ideas here, and upgrades should be removable. so that they can be mix-and-matched to see what one wants best with the space limits that should be implemented with a surplus of upgrades.
1. Self Repair [self-explanitory. siphon charge level to repair systems. limit to non-armor components?]
2. Borg Inducer [This should be added to the engineering modules. but it being a possible upgrade instead could be useful for all borgs. allowing them to siphon their charge level to power an area temporarily.]
3. Alternative Armor Plating [Gain resistances and weaknesses? only doable if one reworks borg damage. I think. Alternatively. different armor plating types. Light armor which increases speed and actionspeed while making more room for other upgraddes but has drastically less hitpoints, heavy armor that reduces movespeed. actionspeed and weapon cooling but has much more health or defense overall. Could be unique for chassis type?]
4. Chassis-specific Ventcrawl [There should be a borg chassis or two that can ventcrawl. maybe only with an upgrade or not.]
5. Solar Charging Pack [Allows a borg to activate a solar-panel package. allowing them to draw power from a star and charge their cell. requires them to be stationary and disable all nonessential systems.]
6. APC Link Pack [Use some upgrade space to gain the ability to charge directly from an APC]
7. Power Siphon Pack [Requires Illegal tech? gain the ability to charge your cell off any live wiring. tapping directly into the network.]
### Yeayea130 - Science Borg Rework?
Science module should potentially start with less overall tools but should be able to use the deconstructive analyzer? allow them to upgrade themselves to slowly get more and more science tools until they're an actual research powerhouse. They have to build onto themselves to keep working. leaning in with the theme of RnD and Robotics. and them being able to upgrade themselves. they should be capable of basic research and robotics proccedure otherwise.