After reading the Engineering design document for 4.5, my main concern is simple: a design doc should remove ambiguity, answer key questions, and clearly explain how things work in actual gameplay. 1: Engineering risks being low-agency terminal babysitting Pilot flies and sees space, gunners fight and see space, engineer stares at a panel and plays a minigame. That may suit niche roleplay, but as a pillar feature it sounds low-agency and boring for most people, for now. Right now it often feels like "having an engineer" prevents nerfs rather than providing meaningful advantages, so the incentive loop is weak. Proposal: Make engineering useful and rewarding out of combat. Make it decision-driven (priorities, tradeoffs, reroutes), not mostly staring at a screen. Make it fun before making it mandatory. Treat a big part of engineering as "pre-flight checks" and preventive maintenance that grants tangible benefits (reliability and control, not power creep). Example: enable a limp-home mode after damage (minimum thrust, minimum shields, QT spools but slower), and small efficiency gains tied to time invested and consumables. Give a positive reason to bring an engineer. 2: Subsystems and life support feel mismatched to current reality Why care about ship life support in a game where we are almost always in space suits that already provide it (+ OxyPen is ez)? Does CIG expect players to walk ships in civilian clothing and sprint to lockers to suit up during combat? That is not current reality. Plausible future cases exist (helmet damage, environmental gear swaps, scanners/data running priorities, undersuits no longer replenishing O2), but the doc must define this clearly. Also, many ships do not support fast gear switching: no suit locker, limited clothing storage, hab space that is functionally useless for crews (beds but limited crew use). That pushes the meta back to "always suit". Proposal: Publish the intended equipment/O2/subsystem model that makes life support meaningful, or reduce this system until the rest of gameplay supports it. If life support is meant to matter, suit O2 cannot be effectively unlimited. Limited suit O2 (with suit roles) plus higher O2 burn under stress could make "turning off life support" a temporary tactical choice, not a permanent bypass. If civilian clothing is intended, ships need suit lockers, outfit profiles, and a real reason not to stay suited forever (fatigue/comfort). 3: Gold Standard is not enough for Engineering. We need a Platinum Standard baseline for every ship Engineering, fires, life support, wear, repairs and multi-crew usability all assume ships have the physical space and infrastructure to support them. Many ships are not even fully "Gold Standard", and even ships with interiors often lack fundamentals like suit lockers, storage for clothing/spares, and clear service access to physicalized components. This creates inconsistent gameplay (some can "repair from cockpit", others require long traversal) and encourages backpack cheese because ships are not equipped for the intended loops. Proposal: Define a Platinum Standard checklist that every ship must reach (including small ships): * Physicalized components for all ships, with service access that matches intended repair gameplay. * Component placement that supports survivability (separation and redundancy, not everything clustered). * Suit locker + basic clothing storage + meaningful internal storage so "helmet off" can exist. * Dedicated stowage for engineering essentials and ship-mounted safety gear (extinguishers) to reduce backpack cheese. If full physicalization is impossible for bikes/very small vehicles, use an integrated "all-in-one" physical module (power+shields+cooling) with clear failure states and repair/replace gameplay. 4: The fuse system is redundant micromanagement We already have failures, damage control, and now fires. Adding fuses looks like micromanagement on top, not solving an existing problem; removing fuses would likely make engineering better. If fuses break, everyone carries a backpack full of fuses; if supply/carry is restricted, players will stockpile and circumvent anyway. Fuse interactions have also been unreliable (CZ: dropping, failing to register, inconsistent behavior). Proposal: Scrap fuses or heavily simplify them and prioritize reliability first. If fuses are needed broadly for power gating, keep the concept but avoid making ship combat depend on repetitive, failure-prone micromanagement. 5: Replace "power plant down = instant boom" with disablement, not auto-destruction THIS IS MY MAIN CONCERN AND IT WOULD MAKE EVERYTHING CLICK Current behavior where ships can effectively auto-explode when the power plant goes down contradicts the stated goal that engineering should keep ships alive longer. It creates two hard-death paths (enemy hard-death and self-delete on disable) and deletes follow-on gameplay: defend cargo, resist boarding, attempt recovery, call for help. It also kills the sandbox handshake between ship combat and FPS/negotiation: disablement should create tension and choice, not a hospital screen. Proposal: Replace "power plant down = instant boom" with a disabled, vulnerable state; reserve explosions for true internal detonation (overload/catastrophic failure/self-destruct) or sufficiently powerful external hits (missiles/torps). If the goal is TTD over TTK, this single change enables engineering, boarding, recovery, and deterrence gameplay. 6: Armor and penetration still do not extend TTK in practice For years the answer to big-ship survivability was "wait for armor". Armor did not fix it; it feels like another health bar. A more legible model would be closer to Fallout 1/2 DR/DT. With penetration, components are a primary kill path and TTK can feel just as fast or faster because critical components are easy to hit and components are often clustered. Proposal: Rebalance armor/penetration/critical cascades so TTK gives time for repairs and decisions. Armor needs clearer thresholds: low-tier weapons should be near-useless against high-tier armor (the "snowball vs house" problem), so internals are not consistently vulnerable to light fire. 7: Multi-crew repair loop vs ship layout and combat reality CIG already ran a multi-crew test years ago and shut it down because ships died before the loop mattered. That risk remains. This tries to emulate Sea of Thieves damage control but overcomplicates it: SoT works because ships are simple/readable. Star Citizen ships are large interiors; engineers may traverse long distances only to arrive too late. Many multicrew ships also only have crew slots/escape pods for one dedicated engineer while everyone else is flying or in turrets; pulling gunners to repair leaves arcs undefended and can nullify repairs. Ship baselines matter: traversal, storage, and component access decide whether engineering is playable under stress. Proposal: Reduce traversal burden and improve localization so engineers can act fast. Define a minimum viable crew model matching ship capacity: baseline 3 players (pilot, gunner, engineer). Add a "gunnery" station that commands AI turrets (targets, priorities, modes, reload). Add engineering visibility where it matters (MobiGlas and or a pilot MFD). 8: Wear, rare components, insurance, and player psychology Wear pushes players to use "good enough" gear and hoard the best, so why grind CZ high-tier components if they will break and force repeat loops? Core questions are unanswered: is wear necessary, how does insurance handle worn items (fresh vs same wear), does it incentivize fraud, will it discourage using favorite ships? Negative progression is also a retention risk, especially for new players whose rewards cannot cover repairs. We also need timescale clarity (hours, days, weeks?), including multi-day mothership loops parked in space. Proposal: If wear stays, publish concrete numbers (timescales, costs, risk) and define insurance clearly so rare gear is rational to use. Also consider service intervals and readiness (maintenance matters) rather than rapid decay, and ensure ship inventory/storage is not an economic trap during claiming. 9: Fire can be trivialized, and staffing realities remain unsolved Fire looks easy to bypass (multiple extinguishers, venting, doors open), and bugs (invisible fires) would amplify frustration. Manpower is still the elephant: most players want to pilot their own ships, so staffing multi-crew outside orgs will remain rare without social tools and a usable reputation system. Large ships were also sold for years alongside expectations of workable NPC crew. Proposal: If fire stays: prevent obvious bypasses and ensure robust behavior, or keep it rare/meaningful, or do not add it as chores. Solve staffing with incentives, social tools, reputation, realistic minimum crews, and a clear NPC crew plan if that is the intended solution. Conclusion: I love this game and I want it to succeed. Sadly, there is not a single element in this document that makes me want to multi-crew more. Engineering needs a gameplay-first rewrite, practical incentives, a consistent ship baseline (Platinum Standard), and loops that survive real player behavior.