JadeOfMaar

A simplified but more comprehensive concept for a new breed of part failure mechanics. Failure is facilitated by interaction with planet mods or the universe and not (as usual) letting yourself be taken by surprise by an RNG and a countdown machine. Its purpose is to add more tangible gameplay value to planets. This rises from an unrelated discussion on a planet mod's Discord server, of how planetary rings in this KSP could be more tangible and hence, hazardous, and I saw a connection back to my earlier post, linked here: Some folks I discussed with: @WarriorSabe @StarCrusher96 Some folks who may find this evolved concept interesting: @linuxgurugamer (who showed interest in taking a shot at coding the predecessor), @Angel-125 (who owns a mod that contains a whipple shield and interstellar engines: WBI DSEV), @R-T-B @prestja (Kopernicus devs). The component concepts that came up were as follows: Durability How a part fails is decided by the health gauge itself and the saturation and mitigation system. In a nutshell, saturation is how much punishment the part can take before it starts actually failing (this has its own gauge). If saturation is below a certain minimum, no damage is taken. If that minimum is exceeded, health (and if possible, other stats) start falling. The higher the saturation bar is, the faster the positive stats fall. The relevant stats to implement would be crash tolerance, heat tolerance, joint strength. A bonus feature of the impact system is that parts with certain attributes or modules, if hit with seemingly non-lethal force, can still stand to have modules shutdown or status flags raised that can be used by other mods to represent a situation. Example: an exposed crew cabin gets hit: the glass shatters, all its resources empty out, its modules stop working, and a life support mod uses the flag (or more) for a compromised habitat. It will require a kerbal with the relevant trait and skill to "repair" the part and clear the status flag(s). The part could have a flag that requires a scientist, and a flag that requires an engineer. While these flags up, modules can refuse to start, and resources can continue to empty out. Debris Fields Assuming planetary rings and Kopernicus asteroid fields could have tangible micro-meteor debris fields, their threat would take the form of raycasts occurring, with random vectors, speeds and virtual masses, trying to strike the active vessel. The saturation and mitigation system are virtually not present when traveling at leisurely low interplanetary speeds. It's mostly the small and basic matter of building your ship to be extra sturdy (whether by using struts, structural parts with higher crash tolerance, or involving ablative hull plating in your ship designs). These systems begin to become prominent when encountering extremely dense debris fields such as the proto-planetary discs of young stars. The faster you go, the more the impacts tend towards the frontal surfaces of your ship, and saturation of your forward shields become a concern. Visualization: A basic and sufficient visualization for an impact would be sparks (there's an engine flameout plume or 2 for that, for example) at the point of impact. The planet-level collision areas would ideally be setup like resource bands for ISRU or Kopernicus asteroid fields themselves, but instead of customizing resources, you're customizing ranges of micro-meteor speeds, sizes, force, frequency. Corrosion This is heavily detailed in the linked thread above, and concerns any and all planets that were made to be corrosive but cannot be as no mod for this mechanic does exists to date. But to simplify for here, this manifests in the ability to set corrosion parameters for a planet's: Atmosphere (including strength, whether acid or alkaline, and an altitude curve so there can be a safe region and a hazard region); Surface (strength, whether acid or alkaline, whole planet or per biome); Ocean (same params as surface); Exosphere (possibly. I'm not aware of any case of corrosives in vacuum but having it still makes for some creative freedom). The health bar and saturation system are the most prominent here as parts are subject to DPS (damage per second) due to prolonged and heavy exposure. Measures can be taken to reduce the effect of ambient corrosives on individual parts or the whole ship. Hull parts could be tailor made (being fabricated the right way and with the right stuff) or boosted (painted with ablators or potentially toxic anti-corrosives, or insulated by an electromagnetic field) to have great(er) resistance. Visualization: A part that is overwhelmed by corrosion could have indicators in the form of the black-body overlay (but that it starts glowing purple. Seems fitting for a starter. It's like having the poison status in an RPG) and a purple saturation bar. This glow and this bar show how much the part is being punished and is the same as hearing a geiger counter crackling increasingly loudly. If you can get away in time then this bar empties and health stops falling-- you don't die immediately if you let that bar fill up but you know you won't last that long a 2nd time. Heat (Conductivity/Thermal Stress) Everyone knows that if you heat certain substances enough, they physically weaken, and melt, but some can stay strong or become stronger. When the saturation bar (due to heat) stars filling up (let's say, it acts up between 80% and 100% of the part's heat tolerance), joint strength and crash tolerance for parts with low resistance start going down and they become increasingly wet noodle, increasingly easy to break something off if it is impacted or if a high powered engine suddenly fires at full throttle. Health doesn't drain away in this case, however it adds a new dimension to "Deadly Reentry." Heat (Reflectivity) Certain heatshields work by being mirrors and not sweaters or ablators. (See: Icarus ship in the Sunshine movie.) A shield in this case is ideally only useful for reflecting light and heat from a star, and would be appropriate for the likes of Parker's Solar Probe. If appropriate and if KSP allows, this may be as simple as giving the part an emissiveConstant value > 1 so that it's exceptionally radiative, and values for the keys concerning insulation which will lessen the part's ability to exchange heat with other parts. If I have the right image, a mirror heatshield is very slow to absorb heat and very quick to emit or reflect heat. However, it should not allow to be used as a cheaty new form of radiator or reentry-rated heatshield. This may easily be done by giving it a very low dynamic pressure rating (as in deployable antennas). Cryo-Hazard A big one that's been sorely overlooked by Squad. Parts (including kerbals) should have a defined lower temperature limit (skin and internal, not too far from Kerbin's ambient temperature of roughly 290K). If the ambient temperature (especially on splashdown, as in cryogenic seas) is extremely far below these limits, the part will suffer module failure or instantly shatter. Module failures here may possibly be unfixable unlike from debris impact. Parts that have extreme lower limits ideally should not also have good overheat resistance. Thermal gradients become serious business. Visualization: There's no special effect to add here. Relativistic Speed Impact This one only becomes important to vessels using reaction engines to travel interstellar. As your ship reaches speeds measured in fractions of c, you face the debris field mechanic in a different and more aggressive way-- a constant rain of micrometeor impacts, which brings relevance to whipple shields in KSP. The faster you go, the harder you're hit by even the tiniest of objects, and the more frontal surface area you have, the more impacts and DPS you have to face. The more you have to face will add up to saturation from relativistic impact forces. If your frontal surfaces start saturating, their health chips away, so you'll have to watch your cruise speed, buff the shield somehow, or add ablative layers. Whipple shield parts would have the unique property of having resistance to the relativistic virtual masses that fire at it during these speeds. Any other parts, if struck by a single relativistic virtual mass object can be blown off or melted, not being recognized as able to withstand it. Whipple shield parts would be expected to come not only in the form of frontal shields, but a suite of modular pieces like stock structural panels so that you have plenty opportunity to get creative with your armor design. Visualization: The frontal surface of your ship could be peppered by little flares representing explosions of the tiny masses on impact. Some heat could be picked up as a side-effect. This is not necessary at all but only for a hint as to where you're being hit and could be switched off by default. ... Documentation I was asked by @ValiZockt to produce documentation for stats that would be immediately important in the VAB info window or the PAW. So I created it. OneDrive link. I'll add concept writing for configuration options for planets later, but these options near-entirely borrow from how Kopernicus' HazardousBody module works. This module can already assign heat zones to planets via: altitude + latitude + longitude curves, grayscale texture (heat map), biome filters.

@TBenz I don't remember the Minerals numbers being -that- low. That.......is objectively horribly unbalanced.

@eatU4myT Converter ratios are given in units per second so the 20 days supply theory is proper. When you give increasingly precise numbers, the throughput displays will go from "X units per second" to "...per minute -> per hour -> per day." The displays don't go higher than that because weeks and months aren't a thing in stock, and no one is expecting a converter to run slow enough to calculate "units per month/year." "0.0 per day" is the same as when Nertea's reactors say they'll last "A very long time!" Minerals in TAC LS is semi-infinite because along with the Minerals supply, you sometimes get a converter to dehydrate food and recover a powdery substance that's all nutrition and probably no flavor, and you can use it to feed the plants in the greenhouse to reproduce tasty food. I didn't come up with this. That's how it is in the prior existing mods that add this dynamic. When you consider time scales in RSS (where TAC is the LS of choice) this dynamic doesn't seem so OP anymore.

@Big Katz @hemeac Space Dust's configs will work in JNSQ but since the measuring system uses meters from sea level and not fractions/multiples of the body radius, any atmosphere presences that are made need to be precisely measured per planet, and exosphere placements will become misfits (the wrong heights and spans) since the bodies are bigger. And JNSQ's added planets get no support at all since there's no means to magically place resources in every atmosphere with one node or switch. (For the experienced, "GLOBAL_RESOURCE{}" does not apply.) I'm working on support right now, to learn all that I need to touch, and fill out the stock planets. After that comes OPM...and JNSQ since you asked.

@infinite_monkey I only raised the supported KSP version on it this time, so it's expecting KSP 1.10. Open Settings --> Compatible KSP versions and check 1.10 to get to it. There's no new requirement and nothing note-worthy concerning the KSP version.

@TheMultiVitamin Your installed version is old. Make sure your CKAN database isn't old (assuming you using CKAN and you turned off Refresh on startup). I fixed the cause of that problem (that tank type needing SimpleConstruction to be present) quite some time ago.

@Daniel Prates Yeah, they definitely are very different breeds, needing very different care. Reaction wheels in cockpits? I know a few players who go out of their way to strip those out, and I've made configs to help them. Dedicated reaction wheels parts (drone cores and inline SAS) tend to suffice for RW power. In most cases outside of atmosphere you don't need much of it. In the cases of needing to turn very fast/forcefully, like for an emergency condition while landing in vacuum, or resisting flipping out on reentry, always be sure to have plenty RCS fuel and RCS thrust. Meanwhile, too much RW can become a problem (especially for long, noodle-ish spacecraft). In atmosphere it can be argued that you don't want to lean on RW torque (for several good reasons I can think of) and youdl rather have air-breathing RCS (which is actually hard to come by, but OPT is one mod that has them). I tend to keep SAS on. But it's arguably better to have an autopilot mod. Stock SAS is actually pretty miserable. It easily misjudges and overcompensates, and it gets worse and worse if you have engines with slow gimbal response and/or wide gimbal range, and if your aircraft is prone to rolling like your spaceplane with dihedral wings. An autopilot will hold your pitch, roll, heading, cruise altitude, cruise speed, all sorts of cool and precise things like that for long or tedious flights. Typically, an autopilot mod will disable SAS, as SAS's logic will conflict with it. There will always be a need for manual input during the flight of any craft in KSP. But it depends on the player how well he or she can build, and how much he or she enjoys manual controls. In my case, especially, I rarely play, and often tend to just do test-flights of spaceplanes so I'm lazy to install an autopilot and I'm pretty confident with manual controls. On the other hand, Jonny is a kOS user so a lot of what goes on during his flights (which may not involve spaceplanes at all. It's been a while since I've seen his Twitch streams) may be controlled by effectively doing MS-DOS commands. SAS would very likely be enabled between the executions of kOS commands.

@JonnyOThan You have a great point there. In my personal experience, spaceplane cockpits tend to be quite draggy (at least as much as the cabin or longest fuselage piece) and they can easily bring the CoP forward. The nose canards, being anhedral, will try to produce yaw (but actually produce roll) when they shouldn't, in addition to the issue of cockpit drag, which can make the plane much more unstable, but I've already covered that in my answer above.

@Daniel Prates Hmm. I tend to avoid placing angled wings on spaceplanes. I personally don't do well with them. And I think no hypersonic vehicle concept has them except maybe for the tailfins. You will always have some amount of non-zero roll amount thanks to wobbly stock SAS or no autopilot mod, so your lift will never truly be centered on and supported by the lifting body (the spaceplane's fuselage) and in thin atmosphere it's easy for one angled main wing to stall out and cause the plane to start to roll wildly, which is probably what you're experiencing. Whenever I do place angled wings or control surfaces, I always disable yaw because the line gets blurred between yaw and roll. I disable yaw unless I put angled wings the opposite way (some swooping down, anhedral, to match and balance the ones swooping up, dihedral). Angled wings add roll instability which is very welcome for stunt planes, fighter planes and airliners. (For crewed aircraft, especially airliners, it's implicitly forbidden and it's just a very bad idea to use actual yaw. See: Coordinated Flight/Turns where you replace yaw with a procedure that involves roll then pitch). Rotate your plane by its root part in the SPH. The CoL will move based on your AoA. If you rotate far and the CoL goes or stays in from of the CoM, the design needs to change. Where did you get those airbrakes from? I'm intrigued. I also wonder if they even work well granted their size.

Release 1.12.0 DOWNLOAD :: GitHub :: SpaceDock Added cold gas RCS thrusters with 9 RCS modes (including MonoPropellant). Added patch for Hydrolox and Methalox to stock vernier LFO RCS. (Is not an extra.) Added Extras: RR_ColdGasRCSStock.cfg to add all cold gas options to all stock and Restock+ MonoPropellant RCS. RR_NuclearFamily.cfg causes Reducing Agent and Oxidating Agent versions to appear for compatible NTRs. Simply tag such engines that you like. Insutructions in config. Can run stand-alone. Added support for these in WBI Classic Stock. Added support for GEP (Grannus Expansion Pack). Includes experiment blurbs. This may change later-on and upset landed mining vessels, with new templates that may come. Added support for Grounded - Modular Vehicles. Added template: AtmGasIV for use by some Hot Jool type planets. Produced by forum user: @Clamp-o-Tron Added variant select for RR Ocean Scoop. Choose between: white + brown; all white. Added engines: MAPT "Microwave Air Plasma Thruster" built on stock J-20 Juno. SFRJ "SolidFuel Ramjet" built on stock RT-10 Hammer SRB. Renamed engines: water ion and hybrid SRBs. May break craft. Updated Extras: RR_TankswitchForSquad.cfg to not activate when Modular Fuel Tanks installed.

@Daniel Prates Some basic and not-so-basic things to help you out: Ensure that your CoL is very close to your CoM and you have plenty of elevon area. The further from the CoL, the more they're effective. Have your wings high mounted so your CoL is above your CoM. This will add paraglider/parachute behavior to your plane and produce a lot of extra stability when you need it. This is the opposite effect to the waverider-- it wants to fly upside down problem of low-mounted wings. (Sadly, IRL supersonic and hypersonic fluid dynamics would be very hostile to this, therefore, hypersonic craft designs for IRL seem to always be waveriders.) Add extra elevons or large stabilizers and (depending on your spaceplane's intentions) consider disabling their authorities, reserving them for deploying and adding a static deflection force to help you stay stable. Even if you do well with point #1, you may still end up with too much unwanted deflection to cancel out. Space Shuttle has huge elevons and that huge center flap after all. Civilian airplanes and fighter planes have extra elevons (flaps, slats, spoilers...) that deploy for lengths at a time: just to add a constant pitch momentum; lower their stall speed; or break their lift potential after touchdown so the craft doesn't accidentally lift off again. If you have tall vertical stabilizers, consider putting OPT airbrakes up there to serve as Space Shuttle's split tailfin airbrake. Airbrakes in KSP can be used very well to create pitch and yaw moments once you place them well and you know that they'll respond to pitch and yaw commands just like elevons. This spaceplane (available on KerbalX), can (oddly enough) easily hold extreme AoA during reentry. Its wings are high and dry to not cause thrust torque by holding fuel, and to add that paraglider behavior so that it's tumble-proof.

USI Asteroid Recycling Tech makes asteroids much more massive without making them bigger. JNSQ and RSS and a few other planet packs make asteroids larger and more massive but I'm sure you're not looking to change your planets, so USI ART is the answer. Asteroid classes above E are used by KSP 1.10's comets. The range is F to I. You have another fuel problem in addition, if I may point out. You want to move super-massive asteroids with stock engines/ stock fuel. NASA knows better than to try that IRL. USI ART and Stockalike Mining Expansion contain Mass Driver engines which make much more effective use of Ore than the usual process of converting it to LF for liquid engines.

Try it and find out. It's a pretty lightweight mod so I expect it not to break easily.

@AmpCat I assume you're in a progression game. If so, the feature is partially locked by the part upgrade system. Look for these and other circular icons in your tech tree.

@chris-kerbal From what I remember, the bug is caused by bad practice with (usually animated) meshes. I recently made a part that doesn't animate and it had the bug. I can't get at all why that would happen. What I assume is that the origin of an animated mesh is far from the center of its geometry, so when KSP calculates the bounding box of the part, it somehow ends up underground and KSP spawns the part in the air to somehow cover for that. The WorldStabilizer mod (linked in this thread's OP) suppresses the bug. I don't have it in me to deal with OPT's parts (mainly the issue of re-unwrapping and re-atlasing these parts if/when needed) so I can't fix them myself.

Being a command seat it should allow that behavior but maybe its KIS equip nature conflicts with that. Also, if you just happen to be in an older version of KSP where spawning in a command seat isn't a stock feature yet, you're not going anywhere.

@nsgallup Please go this way:

The assumption there is that you leave the region above that for solar panels to fill in. Fuel cells with no upper bound and running while solar panels are working will potentially waste their fuel because the solar panels are doing more than enough but power consumers will still give the fuel cells reason to sip on their fuel and contribute to power generation. A great use case is a science station in high orbit of Kerbin or its moons. You have enough solar panel to feed the power demands of the science converter but you don't have enough battery to last during your pass through the body's shadow/night side. You'll have fuel cells around to make up for that. They don't need to fill the batteries but just to keep them from emptying. Filling the batteries is the solar panels' job before any other power source. If the fuel cell is the best or only power gen method for a certain ship (for whatever reason, like a ship that's too far from Kerbin for solar panels to matter, or the solar panels' combined mass becomes a problem) then you raise the upper bound to 100%. In fuel cells provided by mods (at the basic level, "nuclear reactors" in KSP are fuel cells. They're all converters that sip some kind of fuel and produce ElectricCharge) you could install this feature and give them a lower and upper bound so they could truly function as "backup generators" for your huge ship or base. They turn themselves on when you need them to. You don't have to reach for, say, the AmpYear UI or the NFE reactor control UI (assuming NFE is compatible with this mod as an example. It's actually probably not compatible). Another use case is for a nuclear engine (when you're taking a long trip like Kerbin to Sarnus, or even interstellar) whose reactor can switch over and be a power source. In its default state, if left alone, it could waste the nuclear fuel keeping batteries full while solar panels are still usable, and the engine loses a lot more of its half-life than it ought to.

@O YEAAAAAAH Mr Crabs Another round of work is done. RP-0 tech tree placement is done, all parts fully covered by DRE, OPT's stockalike/non-RO upgrade items are disabled (and the heat upgrades with them, but the VIsp stuff for the Warpjets and EggDog engines are still enabled, parts that had the option for Ablator will have Ablator always-on). You'll have to download all the OPT folders again and make another clean copy-paste of everything. (Delete from GameData first). I'd especially like your feedback on the following. Let me know if to provide these: If you believe the heat limit upgrades should stay (in spite of DRE which kinda makes them pointless). In which case I'll also remove the always-on Ablator. I've made a SMURFF-alike mechanism to easily scale only OPT's masses. It's in OPT_Reconfig/OPT_RO.cfg. Let me know if they should have different defaults (currently just "1" for all). Other RCS fuel options (their mixes and what their Isp's should be). Current options are MMH + NTO, MMH + NTO + EC, IntakeAtm + EC, LH2 + LOx Fuel cell options for the "Tidal Force" (LFO) power spheres. They currently use just LFO and are useless.

You're better off using the Rangers to launch themselves (they have the Isp for it. The launcher was completely unnecessary in the movie, and probably just to be inconspicious to civilians who saw the launch. After all, Endurance's existence was a secret at the time) and have the launcher be a drop tank with OMS and avionics so it can deorbit itself. Nobody has made a cradle for the Rangers and it wouldn't work well in stock aero because the Rangers would be slanted while seated in it, and you know then they'll produce a lot of aero deflection which will demand that you put lots of wings on the launcher.

@Rocket Witch It lets you control the fill % where it stops in-game in case you want it to not be the default of 95%. It also adds the abilities to auto-start when EC falls past a certain minimum %, and toggle the Auto functions altogether. The screenshot in the OP says: "auto start fuel cell when EC is 15% or lower, auto stop when EC is 85% or higher." And the two gray knobs on the "Automatic Threshold" gauge are slider handles. The lower and the higher.

If you don't have Firespitter Core (the FS plane parts aren't important), install it. According to the B9 GitHub, The VTOL tilt action requires that mod.

Since I started playing KSP in 2016 my greatest playthrough goal (that I've held the longest) has been merely to visit every moon of a gas giant (effectively a Jool 5) with a huge and fancy ship, with life support, setup bases at 2 or more of those moons, and return the crew to Kerbin. I hope to finally achieve this at JNSQ Jool and with (the bonus of, if possible) a landable (not a spaceplane) main ship. 1 In my first and earliest attempt I came close to doing the Jool 5 with a big and fancy ship but (either my PC became allergic to KSP or a kraken ate the crew--) something caused me to become unable to finish touring the Jool system and abandon the save. This attempt did not include life support or base-building mods. The only parts I used were OPT and NF Electric, and I didn't even know about config files yet, didn't know I could mess with mods. 2 In my second attempt I used Gameslinx/Linx's After Kerbin planet pack and went after his gas giant (or is it?) and I sough to have the crew camp out (literally pop a tent) by deployabing a Pathfinder inflatable hab from within the inline lander, but the spaceplane literally got bent out of shape over something (like a banana, shown below) and then some other complication may have arisen, or my attention went elsewhere so I also abandoned that save. This is a compound vessel: the very massive main ship, an inline lander for vacuum worlds at the tail, and a VTOL spaceplane that can fly at great length in any atmo and return. Parts mods: OPT, Thor Tech, WBI Pathfinder, NF Solar, Heat Control, Karbonite (just to scoop Karbonite from the vacuum to refuel the main ship). No life support or actual base building. 3 In my 3rd attempt I went to Gauss, the first of the three gas giants in Galileo's Planet Pack. The main ship primarily consisted of WBI DSEV but the landers and spaceplanes had some OPT and Thor Tech in them. The spaceplane was only for scouting inside of Catullus and Tarsiss (the purple bodies to the right). The mission goal was all-out colonization; any significant and large aerodynamic vessel would be launched from the first base on the airless moon Loki. Something vicious hit my base (less like a kraken but more like something in WBI stopped working and everything lost their contents. Most likely something I did) soon before I started preparing to launch infrastructure to settle in Catullus orbit (and later, dive into it and farm its atmosphere). But I was happy that I got far with colonizing Loki. The last pic is a pair of SCANsats probably bound for Catullus. Parts mods: Primarily WBI (Pathfinder, Buffalo, DSEV) then OPT and Thor Tech. I do believe I used WBI Snacks...Or I used no life support. Anyway, I dodged needing DeepFreeze by having the dV to spare to make the trip to Gauss just under a year, and planned to make the return flight just as quick. I have all the crafts necessary for my 4th major attempt but I just have to settle a problem with exo harvesting and get into gear to open KSP to actually play and not just mess with mods. I'm also now tempted to try Beyond Home with Morphisor's 3.56x (JNSQ-alike) rescale instead of JNSQ itself after seeing that there's a Beyond Home Space Race challenge and becoming intrigued.

@martianrock Try using a KAS pipe and some KAS struts to attach and secure your ship to the pad.

@jimmymcgoochie It's possible that B9PS may be malfunctioning on KSP 1.10 in particular. Related: I have an issue in 1.10 where the input resource switching on some (OPT) power sources visibly works but don't actually work. They keep demanding LFO.