# Engine (project)

let's start off with a: **if you are going to debate this, please do so with a gameplay reason.**
changes for **solely** the sake of realism **will** be done **if and only if** it does not impact the goals project. we are creating a game here, we do not care about realism other than when it doesn't cost us to do so.
- this means that we are fine with engine redesigns for the sake of realism if and only if it accomplishes around the same or better gameplay complexity, effect, and design.

## methodology

- split power distribution; electricity is a backup, main power is moved by plasma conduits
- 2-3 engines
- main engine (new one) primarily outputs supercharged fusion plasma; is **required** to power (some) ship systems
- backup engine (fission, hopefully reworked too) primarily outputs electricity to charge reserve SMES
- research fusion reactor R-UST for materials production primarily
- solars exist, but are only able to power 2-3 departments at half power. they're pretty bad.
- electricity: duh
- plasma: powers ship systems & can be converted to electricity
- main engine: variable maintenance, variable poewr
- backup engine: low to medium maintenance, low to medium power
- R-UST: not for primary power production; high maintenance, because **it's not meant for power productoin**

## mapping

**it would be extremely beneficial to have the three engines away from each other.**

you don't want one going off hitting the others.
that would be really bad.

you *do* want a line between the backup and the primary engine, however, for jump-start purposes.

## preliminaries

- movable SMES units; slow you down a bit while moving
- movable /power machinery in general
- refactor area power & machiner power usage; needs to be fast & efficient for this system!
- a way to turn machinery off (?)
- good /machinery API for 1. power usage, 2. switching areas, 3. "active" power using for x time, 4. burst power usages, 5. bursting power usage over x time
- add machinery process/tick timing brackets
- **make gyrotrons cheaper but not able to make 1500 damage beams**; emitters are unreliable, gyrotrons are *reliable and fire faster*;
- change gyrotron firing cycle
- all explosions must use new automata wave explosions; old explosions are unusable for our purposes.
- refactor multitool buffers for linking

## wiring

### hugbox version

entire ship is still connected by main grid with substations, breakers, etc.

substations get disconnected plasma converters

mobile SMES discharge slots in substations for emergencies

plasma conduits connect the engine to major ship systems, but not to departments/etc by default

### hell version

entire ship is not connected by default except for by **plasma conduits**
there's wires going to various locations and substations but they're not completely finished roundstart

backup power, e.g. solars, R-UST, etc, have close-by connections to these but aren't fully connected either; they internally carry multiple rolling SMES units

substations still exist
- they still have a discharge slot for a rolling SMES; they still connect the whole department
- they're still connected to the plasma mains with the converters
- breakers still exist for if someone connects it up to the half-built mains.

## smes

- values tweaked accordingly
- new movable smes
- **printable coils**
- generalize it; new "capacitor"-like storage for ship systems. make those printable too.

## apcs

- 5kj buffer; allow for batteryless operation
- by default, start with shittier batteries

## powernet

- power load balancing? might be impossible for the time being to do fast
- partial power outages? o_o

## normalization

- HELLO, BAROTRAUMA! fluff stuff like lights are power draining but not as much as before; running a fab, operating a body scanner, etc, is more consuming by far than lights.

### fluff-tier
- lights: 15W bulbs, 45W floor lights, 75W tubes ; they also get a small internal buffer, and goes into emergency dim-red-light mode when power goes out.
- drain goes down by half during night mode.
- fire alarms and air alarms take 100-250W each (maybe) ; air alarms take more while heating/cooling the room (up to 5 kw)

### low-tier
- airlocks: 10W idle, 0.25-1KW while opening (so not much given short timeframe)
- holopads: 50W idle, 0.25-0.5KW while projecting
- vendors: 10W idle, 50-100W while operating

### medium-tier
- body scanners: 2-5KW while scanning
- sleepers: same cost as dispensers to synthesize chemicals potentially; 1-10KW for stasis
- atmospherics machinery - not going to elaborate

### high-tier
- clone/resleeving pods: 30KW operation at base speeds
- lathe: x joules per **unit work**. faster lathes don't just work faster, they draw more power; lathes *will* get efficiency upgrades though, but expect 20-50KW base and 50-150KW tops when in operation at medium-high upgrade, and potentially higher at super-tier upgrades
- chemistry dispensers: 10-25KW while synthesizing chemicals ; depends on machine & chem, bar ones are for example, going to be extremely cheap.
- rechargers: self-explanatory, amount based on upgrade & battery
- single-wall shields: nigh-indestructible, 10-15KW per tile.

### extremes
- ship shields, primary FTL, primary propulsion cannot be powered by electricity
- normal bay shields (bubble, hull) may take 1-25MW
- gas thrusters may take 100-750KW each during operation, based on efficiency, gas, etc
- ship weaponry/sensors/other systems require a large amount of power while not idle, especially during scan, up to megawatt+ range.

## solars

- solars use day/night cycle on planet
- solars use closest-star-angle + cheap raycast obstruction check in space; todo: make overmaps have stars and have it be relevant for how far away you are (? hard to do nicely on euclidean maps rather than polar)
- 1-2KW **peak** per solar
- 1-2KW is worth a lot more on new power than old power.

## plasma

electro-plasma system (EPS) pipes shunt plasma around the ship

- acts like atmospherics, but without gases, just two variables on the entire network:
- density - amount of plasma
- heat - energy density of plasma
- producers/consumes are gradual to simulate a roughly flowing network without actually flowing
- EPS pipes are relatively thin, and easily constructible with metal + some wire
- make it lathe-only later
- EPS pipes are **tough**.
- breaches cause anything from some sparks, to a small fire, to full on detonations based on how charged the network is
- care must be ensured to stop the entire ship from chain reacting
- converting from plasma to electricity is not 100% efficient
- but you'll have to do that anyways, Too Bad
- converting from electricity to plasma is so inefficient only the research division / anyone fucking around really has reason to do it.
- seriously, don't try to back-power the FTL with solars.
- pipes act like power cables and **do not autojoin**.
- sorry, mappers; atleast you don't have to deal with diagonals with this.

## primary drive

expected size: **decently big**

i should probably emphasize that this is open to modifications since this is just another idea built off all of the above

### initial stuff

- ship-wide cooling loops are epic but i don't know if we can do this performantly without negatively impacting everyone potentially
- core is meant to be able to be ejected (potentially stolen) and retrieved without incident
- this is like, under optimal conditions. ejecting a core that's critical is different from just jettisoning it and putting it back
- plasma network is a lossy capacitor, not a battery. it loses power over time, as canonically it *takes* its own power to contain the plasma, and the more energy you have contained inside, the more energy it siphons to maintain containment
- you **physically turn the engine up** when you need more power, e.g. during evasive ship maneuvers that sacrifice power for efficiency. fun!

### plasma network

- producers, consumers, capacitors, one-way transfer valves, limiter valves
- usually you wouldn't want capacitors at all since the network has natural capacitance and capacitors are still lossy (even if a bit less so)
- draw is averaged
- we don't necessarily want to punish overcharging as much as having super high power itself
- though we can have machines that draw have an upper limit, and maybe vent a bit of heat / cause unpleasant effects if overheated
- or better, just making running everything at high powers a bit inefficient and quite a bit dangerous
- if we did punish for having high power itself (or really, at all) we'd have to be strategic where we put plasma lines so it seems bad but it doesn't actually just start killing everyone
- it'd also give a reason to put plasma lines *away* from frequently travelled areas, so in maints/substations
- rapid unplanned disassemblies (so shit breaking)
- ranging in effects from:
- a nasty shock and some heat (enough to warm a small room to 50-60C) at low energies
- a *lot* of heat
- small explosions
- large explosions that tear open the conduits around the line for violent decompositions
- network has a throttling system for this, so you can't have a chain reaction
- overloads
- plasma machinery breaking/being overloaded, like reactor fluxes, can travel down the network like a "packet" and cause all sorts of nasty effects like
- flashes
- radiation
- small time emps
- machinery hit by the packet doing more powerful versions of this
- maybe emergency devices that shunt a portion of energy to prevent overloads

### core

5x5 object. we are going to need sprites.

- positioned above a big mass driver
- supporting machinery is attached to it
- contains the fusion reaction and serves as an intrinsic buffer of energy, radiation, and *mishaps*
- probably placed very close to the main sublight engine
- we might even want a direct line for this purpose
- this shit is
- **heavy**: only able to be pushed slowly by mechs, or multiple people. this is nullified if it's entirely on space tiles - in that case, you can drag it slowly solo. **theft of the engine is very possible.**
- **climbable**: i'll code in ~~/datum/element/climbable~~ climbing at /obj level because we're not deranged enough to use elements for this shit
- **highly valuable**: adminspawn only initially, we'll add a way to build it later (unless mazian vetos me by just coding in a way to do so lol)

### supporting machinery

supporting machinery attach to the core by being adjacent

they can be controlled via the control plane and linked consoles

#### plasma tap

- removes plasma from the core
- can inject plasma into the core but this is, obviously, usually not worth it
- lol jumpstarting another ship?
- configurable rate

#### fuel injector

- takes fuel
- injects it at a configured rate
- shrimple as

#### control plane

- provides an interface for control
- control consoles need this basically - link the ids together
- in the Future we might wanna look into making it use network cables instead but for now don't worry about it that's a Silicons Insanity Project
- provides power to the core
- if any core functions require power this is where it's input from.
- this takes power from a wire. so yes, losing engine power bad
- on the bright side, cutting the apc doesn't just fuck the engine now lol
- **all supporting machinery receive power from this.** the engine therefore technically does not need an APC

#### pipenet adapter

**Entirely optional device.**

- pumps gas into thin 'shell' around core
- gas heated by system
- gas is not heated to the actual core temperature, more like 1/5000 of it.
- core usually operates at millions or tens of millions degrees, we don't want gas *that* hot!
- at 1/5000, 50 mil degree is around 10,000 degree gas. This is already **extreme.**
- more than likely we'll use a non-linear heat transfer system to avoid being able to just pump out free superheated gas. Anything above 10,000K as a *constant stream* is very bad for atmos balancing.
- in the future, gas reactions may occur from the radioactivity hitting the gas
- for now, gas will provide a small amount of radiation shielding - diminishing when superheated.
- give a reason to use this at all

#### focus

- concentrates emitter/gyrotron pulses
- provides energy to the core, but helps make it unstable.

### fuel

we have a few options here

#### solid / reagent fuel

- fuels are stored in containers
- containers are stored in injectors and, well, injected
- if/when we get plumbing we can use that for the reagents

#### gaseous fuel

- fuels are stored in canisters
- fuels can be piped into injectors
- fuels can also be put into the pipenet adapter but this is Potentially A Very Bad Idea

#### both

- both. we start off by coding solid / reagent fuels, then add in translations for it to become gas / become reagent from gas
- we should optimally make solid a thing first, this is minimal effort for minimum viable product

### startup, mechanics, reactions, output

this is somewhat but not really inspired by R-UST

reactor has stats of:

- spin: the kinetic velocity of the contained fusion plasma
- compression: how tightly the matter ring is compressed in the core
- instability: how (dis)orderly the plasma is, from a perfect ring to pretty much going all over the place
- temperature: duh
- volume: this is just the total amount of material in the core, including the fuel itself

i'm done ranting so this will mostly be revealed in PR but tl;dr:

- spin: higher = contains more fuel easily, lower = less catastrophic instability events;
- too high = too high rate of fusion + ironically instability, not the stat, but as in your power output. shit might go haywire faster if instabliity accrues.
- too low = can't contain the mass well enough = more instability
- instability:
- causes instabliity events which reduces it
- can cause core damage/whatever if it accrues too much, and if there's nowhere for it to go it'll gradually get worse and worse
- fuel / volume:
- fuel doesn't fuse all at once, depends on containment + spin
- too much fuel = runaway reactions are more likely
- too little fuel = duh your reactor burns out?
- fuel + unnamed byproducts as plasma = olume; interactions with spin/compression
- temperature:
- contributes to energy, which is what instability is calculated by
- not really a tuning mechanic other than for energy, you tune fuel not temperature
- compression:
- fusion rate
- too high cancels spin unnecessarily, too low causes instability

idk this'll need a lot of tuning to be newbie-friendly.

### accidents

"sometimes, you just lose"

#### instability

for (unnamed fake physics reasons), the main way the reactor keeps the mixture contained and stable is its inbuilt electromagnetics.
the fusion fuel mixture is kept spinning; this further reduces instability.

instability results in venting incidents that increase in severity and rate as it gets worse.

it's mitigated by

- not having too much fuel / mass in the core
- having the core be cooler
- inputting more electromagnetic energy to an extent

#### venting

when unstable, energy can be vented in different ways:

- lightning bolts (arc flashes)
- overcharge packets being sent through the plasma network
- cutting it off from the network is bad because it'll just vent the packet into the room
- heating the area a bit
- big, but weak emps
- through unidentified Scientific Bullshit Reasons, highly unstable fusion cores can release burst instability into the ship's propulsion/drives, as well as surrounding ones. this makes thrusters less efficient, disrupts shields, and is highly visible on sensors (and is very bad for sensors that are too close).

#### meltdown

if instability gets too bad, the engine's spin entirely destabilizes

- all core energy is ejected into the surrounding area:
- large explosive shock wave
- massive, decaying multideck emp pulse
- everything remotely nearby is flung away at high speeds, magboots or not

### ejecting

- core is next to a set of shutters
- we have a massive driver that can shoot it into space
- you **cannot easily** order a new core. lose it, and it's admin intervention
- eventually when it goes off level it'll turn into an overmap entity, and you can send a shuttle out to grab it later.
- eventually we may add a way to assemble a new core because we *do* like "we can rebuild it" mentality
- if machinery is not safely detached, you basically just rip machinery apart and it might even cause back-flow overloads or bad network behaviors.
- the core is **heavy**. ejecting it without any power at all is difficult.

#### activity

when we fully finish the overmaps update, the ejected core will be a full overmap entity as opposed to just sitting somewhere on the level.

- it's continuously simulated
- if venting wins, it gradually, understandably, cools
- if the reactions wins, it still detonates. this hits nearby ships and causes aforementioned issues with thrusters, shields, and EMPs them.

## fission

- HELLO, BAROTRAUMA CAMPAIGN DIFFICULTY PACK!

no *overly major* rework ideas until we get steam pipes & steampunk machinery

expected size: while you can technically contain it in a 1x1, i highly recommend it being a standard 7x7 room, with an additional 50 tiles of space for processing, etc

fuel should be stored in a small room semi-separately.

- refactor the code to not be a joke
- rebalance it to put out 1-2MW at medium power
- redo how the explosion works
- less explosive, more meltdown
- redo how rods work
- rods activate each other
- control rods are now innate; reactor just has them, they don't wear out
- rods **can get hot** and **are more radioactive as they deplete**
- besure to store rods away from each other and separate them - carriers are radiation proof
- rods **can be activated by passing radiation waves** - don't leave them out!!
- rods can **explode** if heated to a sufficient temperature, potentially embedding radiation shrapnel in walls
- rods are **long lived**. it's not going to require constant replacement.
- rods take time to actuate. try not to explode.
- reactor components like neutron reflectors (?)

## rust

rust ""demoted"" to scientific fusion reactor

expected size: direct containment 7x7, with an additional 50 or so tiles of space for cramped, but very usable operation of gyrotrons, injection, processing, extraction, control, etc

- some reactions make energy
- some reactions use energy
- reactions require different materials, amounts of energy, catalysts, have different radioactivities, etc,
- field captures reagents from either accelerated particles from injectors or any gaseous & valid reagents in the air being ionized into the field
- field requires **constant gyrotron fire**, potentially with different rate/normalcy requirements to keep stability
- field ruptures are bad, but not nearly as bad as now
- field **rapidly equalizes temperatures with air.**
- want to do research? make a vacuum so it can actually heat up.
- want to make power? you aren't going to get to high temperatures while there's a lot of air still being heated.
- add back magnetic traps
- outputs reagents, including output reagents, as **superheated plasma**
- oh, sorry, did I say plasma conduits only stored temperature & density? I lied!
- plasma collation unit
- condenses plasma with fused reagents into materials
- i hope you have a radiation suit and like the sweet blue glow of a radioactive death aura (:

## some spitballed ideas

- radiator: atmospherics device; throws out a bit of gas input into it to cool it to target value. uses power, but there is a net gain in exchange for losing the air into the surroundings

---

Knightfall5:
Core: ejectable matter-antimatter machine that jumpstarts the fusion process to instantly sustainable levels when you are ready to start the reactor. Fusion plasma contained in electromagnetic fields, the device making it has to be kept cooled down to function. Over a certain temperature they'll begin to degrade, causing fusion plasma to escape and damage the core. If it gets too damaged the stored antimatter would cause a large explosion.

Fuel: Would be fueled by machines that are fed fusion materials and can be adjusted to then pump this into the fusion plasma at certain rates depending on how much energy you want to produce. Different reactions produce more power at higher temperatures and need a minimum temperature to begin reacting at all. Starting reactions would be deuterium-deuterium, deuterium-He3, and deuterium-tritium like the RUST uses now. Mid-tier ones could move on to using materials like lithium and boron, while the end-game would be proton-proton fusion like what occurs in the core of a star.

Cooling: Electromagnetic fields carry metal dust into space to cool off, and then bring it back into the ship in a loop. Yes, I have been playing a bit too much Terra Invicta lately and am stealing this idea from them. Better parts equals better electromagnetic fields that can hold more resources, and more exotic materials radiate heat better. Losing power would result in a steady loss of resources over time as it drifts off into space out of range.

Mechanics: The hotter the reaction gets the more waste heat you need to deal with, but the more/hotter plasma you'll generate for the EPS network, and the more efficient the reactions you can use become, which then creates more heat you need to deal with. Once you achieve proton-proton fusion you'd be able to sustain it with relatively little resources due to how efficient the reaction is. Maybe integrate the crypto miner into the reactor to turn excess plasma into even more heat for points

Fol:
Sorry but going to textwall for a suggestion. Since we already have R-UST as a well-established tokamak/magnetic confinement fusion engine, I feel like we should have an inertial confinement engine. This is going to be out of order to make (some) sense.
For "powering" it, you'd use lasers (they're already absurdly powerful in-universe anyways). I think mechanics here are pretty blank slate, how much flash-lamp/amplifier/mirrors/etc there needs to be, or the geometry of the engine, but I will point out this would make the main engine require a base amount of power stored to even start running (backup engine?). Would probably be the kind of thing you set up carefully, check well, and then flip on and hopefully don't watch it cut holes into the walls (rather than a slow-burn start of most engines that heat up etc.).
Now if we just did ICF that would be pretty robust and realistic etc but then doesn't meet the criteria (:meowsad:), so my suggestion is to give it a core mcguffin. Instead of shooting a fuel pellet in flight, give it a final lens/reflector/giant holhraum "Core" that the lasers fire into, and into which the fuel also goes, and out of which comes the Supercharged Plasma, and we just don't consider the specific physics and geometry of how you're actually compressing the fuel inside of it.
Obviously this would be the thing you eject and I guess we can assume it holds the fusing gas inside it for some time, so even if the lasers can be cut off instantaneously, it would still be hot and fusing for some as-of-now-indeterminate amount of time. You'd probably also want to focus the cooling on this, though maybe the big person-sized laser equipment should also get cooling, I don't know.
Finally, this could run continuously, since we're ignoring the critical design consideration of ICF and keeping aesthetics, but for the sake of such aesthetics I would argue the lasers be pulsed and the reaction constant. (Like emitter for the SM)
I think in that form, it should hit the goals:
You can have a default easy textbook configuration that's probably already set up and only needs securing the parts and putting the fuel Core and piping fuel into to run.
Expandable since in my mind you'd have some kind of puzzle or mechanic with the different laser stages/machines to either make it more energy efficient to run, or safer, or more powerful, etc?
Dangerous, in both a, should take some thought to change the setup and keep it able to be run safely (see: stray lasers, or just explode too much fuel at once on startup, or too little and it can't sustain it at all and just wastes your laser power, etc), and also should be dangerous in-operation if operated carelessly (core melts, etc).
Variable fuel level/power level. Almost inherent to using a thing that takes power to start, there would be a minimum power to run, but there's probably a window of energies you could run it at, with that window probably getting taller and more rewarding if (to go back to #2) expanded.
It needs the core mcguffin to become an ejectable concept, but, it is.
Last requirement also met as you just crush the fuel into a fusion plasma, there needs be no electricity generated.

Murphy:

!(https://media.discordapp.net/attachments/1071527583352627315/1071527785723613244/20221223_220610.png?width=1135&height=1513)

Mazian:

i want it to be extensible and flexible so people can fuck with it, but also make it simple and basically run itself
so engineers can baby it if they want for more power/preformance, but people who wanna do other stuff can fuck off

so the engine should be:
-easy to run, but also tweakable
-dangerous when damaged or messed with, but very powerful in the right hands
-probably the sole concern of engineering when things are going really, really, really badly.

so, i am thinking the engine has an integrity that's affected by the state of the plasma network to some degree
the plasma network at a certain point will begin to consume power to maintain itself if you're pushing it beyond certain limits
and the engine will take damage (maybe negatable through upgrades?) if you're running it too hard and something on the plasma network happens, like an emp, a conduit fails, etc
but it should be durable, and able to recover from a fuckup to some degree

so initial stages of fuckup would be like
minor power fluxuations, random EMPs focused on parts of the plasma network, a computer complaining on the engineering radio about stability issues
moving to 'the reactor is now taking damage',
the reactor has an automatic purge feature which can dump the entirety of the plasma network, at the cost of knocking the entire ship offline for a prolonged period of time
because ejecting the engine is like, ICly, a shipyard-level repair, so you want to avoid that at all costs; but the automatic core dump only works if the reactor is damaged and there's enough plasma to power [macguffin magnetic coils or something], but the dump also has a chance to fail because of damage (maybe add a manual process that's INSANELY DANGEROUS so if the automatic fails, someone can be a hero and dump the core)
anyway, ejecting the core is a last resort for good reasons, and dumping it is bad, but not unrecoverable, and an engineer's tool to handle 'we have fucked up' is going to be trying to minimize the reactor's output without shutting it down entirely (which, an unplanned shutdown would be very bad and maybe cause similar issues to a core dump) until the plasma network is stabilized

and the above would normally be an automatic process that tries to match output with demand

consider: ship-wide cooling loop, plasma 2 energy converters require cooling which goes to a big radiator, without it they'll begin to break down and cause issues with the plasma network

lolman360:

### mainengine concept: the annihilator

fluff tldr: (barely) contained antimatter chemistry. very fun! atmos optional.

### key bits
has primary parameters that the core loop revolves around.
1. power stored. this is how much energy is in the engine at that moment.
* this is probably going to just be called 'heat' later on since that's what plasma conduits care about. power is the working title so that there's less confusion
* plasma conduits are going to be distribution and short-term storage, a la substations (but with lower capacity, probably)
* the engine itself will serve as both generator and primary power storage, but again- it won't store very much (in comparison to current smeses and their 3MWH+ capacity)
* gives some breathing room/ability to respond to fluctuations

2. power generated per tick. how much energy is added to the storage
3. stat 1 (homogenity) controls how fast the reaction goes. higher = more power production and fuel consumption. (main reason for inclusion is to make incredibly epic max power max fuel consuption setups somewhat viable to do even with low consumption)
4. stat 2 (flux) how Changy everything is. higher flux increases the amount of power that can be output from reactor storage each tick (as a %age) and grants an efficiency bonus (same fuel use, more p/t). increasing flux causes Bad Things to start happening, tbd. reaching maximum flux allows you to take 100% of the stored energy in a single tick!! (reactor explodes!). decreases slowly over time, will never increase unless specific dopants are added or something else happens
* this, alongside lattice and power, are going to be the main stats that engine revolves around. homogenity's going to be mostly independent from them for good reason
5. lattice structure. this changes the overall function of the reactor and allows for wacky setups. examples include regular (no change), amorphous (decreased efficiency at base, flux now has a much higher effect on efficiency and no longer passively decreases over time), crystalline (homogenity is pegged at 0, its effect is now governed by energy stored) and so on. allow for really interesting changes and completely different strategies by changing the major relationships.

**actual structure / access:**

engine is a 3x3 (or bigger) surrounded by some machinery that can be swapped around. fuel injectors, dopant injectors, plasma taps, gas injectors/extractors, heat exchangers etc.

having stuff to move around/replace is good. need to dump heat? swap in/activate a bunch of heat exchangers

central control console will let you do everything if powered, but if there's none you have to get in and use the manual overrides on the equipment (i.e Turn Valves And Stuff)

### core ejection
core can be ejected. this basically stops you from generating power until you replace it.

tentatively: an ejected core will likely be (an overmap object? something) that explodes after some time (if unstable. you can put stable cores back into the engine, or steal them or whatever. you can also steal and stabilize unstable cores :D)

new cores are buildable, but they'll be shitty (locked to a 'downrated' lattice structure which caps flux, homogenity and other factors as well as reducing power output)

### fuel and dopants
fuel needs to be added to the reactor. it just burns it away and produces power.
tentatively: different types of fuel, each with an efficiency or power bonus inside a specific core power or flux range? at most 3-6, no more. consumption rate is based on homogenity
tentatively 2: custom fuels? engineering gets a big fuel producer, fed with supermatter, mining materials and possibly chemicals to get fuels with new exciting qualities.

dopants: change reactor stats. consumed slowly but must be manually added. injection rate, like fuel, can be adjusted. consumption rate is either: always constant OR: based on a stat (e.g higher flux = lower consumption, higher homogenity = higher consumption, power stored at 50% = lowest consumption etc. generally going to be simple -ish formulas)

actual values (how much dopants change stats etc) and gameplay loop stuff (what types of dopants/structures/fuels exist etc) is something we're going to have to trial and error to see what's good

#### extremely out there: engine scripting language
we're just slathering on as many layers as i can at this point because i would Really like a lot of depth

basically /vg/station's atmos computer, but for the engine. automate fuel/dopant/gas injection based on engine parameters, turn on/off engine-related machinery (for stuff like core heat exchangers especially)

probably a simple check/response thing to avoid being too OTT:
check parameter
(maybe) check second parameter
(maybe) do a logic based on the 2 params (and or xor nand(?) etc)
do thing if check fails/passes/etc

### tldr:
complex, meaty engine with lots of parameters and stuff to mess around with. will probably require a good bit of investment to get right.