JadeOfMaar

@kerbiloid A hexagon-based terrain generator really seems like it would introduce a whole new breed of planet designs and could quickly get awkward being used in parallel with/beside KSP's existing convention for choosing and lying out geological features. There's the new issue of having terrain features compartmentalized like this could get stale fast unless someone first belches out a very, very wide repository of preset tiles for things. And that too would be a huge task like: Mountain range Mountains with desert plains and dunes Mountains with surrounding hills Mountains with an intersecting canyon (and how many way the canyon intersects them) Mountains with a crater Mountains with a river Mountains with a valley And that's just mountains. And each of these options would need to magically blend into each other after being placed as there's no way to build them to lego together perfectly in absolutely every combination. I think I can see other issues but this would be a very interesting and welcome thing to have, once done properly.

Sorry for the necropost. I believe the ideal in-game planet editor would be one that resembles that of Universe Sandbox but also has granular tools for producing procedural planets or their textures, and is able to accept external textures and use them as a base for producing other procedural textures. Biome maps will remain a tall hurdle on their own to jump, to make, because there are a few unique ways to approach a given biome and its unique purpose.

You can create a science game and use the progression cheats to unlock the tech tree right away. Science mode is officially called "Science Sandbox" somewhere, inside the persistence file, I believe.

Different intakes have different operating ranges and capacities. Different sizes and shapes have differing intake area which allows more or less air per second. The faster you're going, the more air you can draw in, but depending on their type, some will draw less air instead. The thicker the atmosphere, the more air you draw in despite the type. The thinner the atmosphere, the less you draw in. You will very often see these two intakes on SSTO spaceplanes or hypersonic airliners: Shock Cone: It's pointy (good for aero/drag). It's great at heat tolerance so it's often the front-most part. It's a shock or ram type intake so it's less likely to draw less air because you're going faster. Engine Precooler: An inline intake. It has great passive ability to conduct and disperse heat produced by an engine directly attached to it. As a turbine type intake it has amazing ability to draw in air so it can feed many engines or feed engines that really guzzle air, but it also becomes very poor at high speed. It also holds the most IntakeAir in it which helps engines to not flameout as easily in thin atmosphere.

@Bootes The purpose of the version file is to let you know what the last version of KSP was, that this mod was tested and confirmed to work on. In the case of KSP 1.8, 1.9 and 1.10 introducing terrain shaders (or fixes for them), it's very convenient and proper that you'll be warned about using this mod in newer KSP. These shaders (and whether they're active) will break a planet mod that hasn't been updated since the shaders started coming. Changing the version file only amounts to silencing the alarm and does not fix any problems. Not all mods have or need KSP version limits in them, but they will if their makers see it fit to set them. In the case of Galaxies Unbound, this mod is huge and therefore quite a chore to troubleshoot. So it helps the dev to be aware of problems just by letting him know that you're using a particular older (or newer) version of KSP.

@caipi That's simply an oversight. I believe I've caught it but it won't be released just yet. I have some localization remaining, some possible remaining FAR config entries to do, and maybe some other little thing I don't remember.

Alright, I see where this has been going. Pardon me. My handling of OPT parts (still very WIP) should change appropriately.

It's interesting that you choose to divide by 50 to produce the SystemHeat value you want. According to Nertea's handling of the stock folding radiators, you want to divide by 5 again (or 250 in total). The gray numbers are config values. (Yes I know the medium folding divides by a different amount but it's still really close.) I've followed this trend for OPT parts. I just learned that Heat Control's radiators may use different scaling. I'll have to update this image and see.

@Dr.Lxweei I can't say that I support the OPT/WBI Cryo tank options anymore. I've rewritten all of OPT's WBI integration (but not released yet) and any references to the boiloff plugin no longer apply when Pathfinder is installed. So simply delete the boiloff references from the configs in your install. If you still get problems then it's time to pick apart your install. Also, your exception snippet mentions the visual mod, KS3P. I wonder why you have KS3P and TUFX installed together? I highly recommend you don't do that.

@Nertea For the situation of DBS and the abundant ElectricCharge storage, the root of the problem has to be that DBS does not agree with Angel-125's tank switcher module. (One of the OPT cargo bays must be set as a battery bank.) For the situation of the empty Thermal UI tab, the OPT cargo bays have radiator modules in them but no System Heat patch exists for them.

I just produced this bit of documentation and came up with two new aspects while doing so: Reflectivity (we have ablator and sweater type heatshields, but what about polished mirror heatshields?) Cryo-Hazard (exposure to extreme cold, such as splashdown in LqdNitrogen).

@fatcargo The first and best thing to do is to manipulate these: // passive undeclared keys and values PART { buoyancy = 1 // dimensionless (0 ~ 1). do not exceed 1 maxPressure = 4000 // in kPa } All parts have these values by default, and so, have maximum buoyancy (before what other calculations are applied like mass-volume ratio? which cause some parts to still sink in spite of this or still float when they should sink). Angel-125 has a solution for buoyancy and pressure limits already in his Buffalo/Guppy rover.

That sounds about right. Parts by default have a pressure limit of 40atm. Judging by @Clamp-o-Tron's statement, they haven't learned yet that: Due to Eve's SL pressure, the undersea pressure scales faster, so parts will crumble at a lesser depth. Since Jool lies about its SL pressure in the Tracking Station, it will destroy you before you reach the kraken at -250m altitude. Jool's SL pressure is actually 50+ atm.

@EimajOzear Hmm. I won't say I'm particularly interested in that and I have my doubts that B9PS will get along well with the kerbal.

Aww man. Well also I'm the only one who's added CivPop features to other mods, it seems.

@linuxgurugamer I tried your update and I was going along well at first but I eventually had the issue again of the birth countdown going negative and losing the abilities to recover craft, quicksave/quickload, switch scenes. [EXC 17:56:58.488] NullReferenceException: Object reference not set to an instance of an object KerbalRoster.ValidateAssignments (Game st) (at <c1858a3f77504bd1aaa946fdccf84670>:0) Game.Updated (GameScenes startSceneOverride) (at <c1858a3f77504bd1aaa946fdccf84670>:0) Game.Updated () (at <c1858a3f77504bd1aaa946fdccf84670>:0) PauseMenu.<draw>b__25_7 () (at <c1858a3f77504bd1aaa946fdccf84670>:0) DialogGUIButton.OptionSelected () (at <c1858a3f77504bd1aaa946fdccf84670>:0) DialogGUIButton.<Create>b__23_1 () (at <c1858a3f77504bd1aaa946fdccf84670>:0) UnityEngine.Events.InvokableCall.Invoke () (at <5aeafee3fea24f37abd1315553f2cfa6>:0) UnityEngine.Events.UnityEvent.Invoke () (at <5aeafee3fea24f37abd1315553f2cfa6>:0) UnityEngine.UI.Button.Press () (at <99c70f3212f546f499a5c598b1663bb9>:0) UnityEngine.UI.Button.OnPointerClick (UnityEngine.EventSystems.PointerEventData eventData) (at <99c70f3212f546f499a5c598b1663bb9>:0) UnityEngine.EventSystems.ExecuteEvents.Execute (UnityEngine.EventSystems.IPointerClickHandler handler, UnityEngine.EventSystems.BaseEventData eventData) (at <99c70f3212f546f499a5c598b1663bb9>:0) UnityEngine.EventSystems.ExecuteEvents.Execute[T] (UnityEngine.GameObject target, UnityEngine.EventSystems.BaseEventData eventData, UnityEngine.EventSystems.ExecuteEvents+EventFunction`1[T1] functor) (at <99c70f3212f546f499a5c598b1663bb9>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.EventSystems.EventSystem:Update() I've made a zip with save file (as asked), the KSP.log at the time, and the MM patch that adds this mod's features to Pathfinder. OneDrive link. Used in KSP 1.10.1. The only mods you'll need to install are Pathfinder (and its dependencies: Wild Blue Tools, Classic Stock). The sample vessel with working/fixed Time UI open.

They won't conflict. They're perfectly safe to use together. And you can even go ahead and add the SpaceDust telescope features to Tarsier's telescopes, or Tarsier to the SpaceDust telescope. I do see a possible glitch happening where modules from one telescope might not respect the lens cap animation being controlled by a foreign module, if they depend on the lens cap animating. I haven't tested it but I'm entirely confident in it.

Heheh. ;D Yep I went there. There's a major problem with the idea of "cooling the hull to absolute zero" ... I don't need to tell you that you really, really, don't want your atoms to stop moving. You invoke an exceptionally huge requirement for cryogenic material and a cryogenic chamber to expose the craft to, and you introduce the parallel, extreme dangers of: making the hull brittle and worthless in the moment that you're flash-cooling it to such a degree; making the hull brittle by exposing it to the utterly extreme temperature gradient between touching absolute zero and burning in hypersonic flame (assuming the hull even stays cold enough by then that the cooling efforts matter). Moving parts and their fluids would very quickly crumble or shatter as their chemical behaviors change along with the state of matter. Pressurized parts might shatter and implode or explode because the air or propellant inside them would turn solid and possibly cause vacuum pressure that they weren't designed to handle. There are proposals for sweating cryogenic propellant to dampen reentry heat. Methane has been proposed at some point by SpaceX in order to help Starship's survivability on reentry. To carry enough of a cryogenic substance that isn't propellant is to carry dead mass The microwave air plasma thruster in concept meets the demand for both a scramjet and a viable electric or nuclear jet engine. Once that's made up, classical scramjets and possibly nuclear turbojets would become relics. You could tank the air for a microwave jet and have the liberty to ascend more steeply because you don't need enough intake ram effect to fill a pressure vessel as you would need to: super-heat the air so it readily ignited when it reaches the scramjet's candle and fuel injectors; and to maintain enough intake air pressure to keep scramjet combustion stable and thrust production sufficient. We're also now quickly moving along with battery density tech which is critical to having the electrical systems to power electric engines or EM heatshields. If compact fusion power happens, the demand for fission reactors may drop quite quickly. All that said, I more enjoy using LF-burning scramjets in KSP than the idea of using "a rocket that consumes mainly/only air."

@Spacescifi I know of a plausible concept for using an EM field (potentially, effectively polarizing the hull) to repel reentry plasma. The subjects I know of that correlate are MagnetoHydroDymanics and Electromagnetic TCS. In a sci-fi setting, I would be quite confident that for hulls: the material heat tolerance problem would be solved, or EM-TCS would be very effective and common-place, and for hypersonic propulsion: scramjets would be replaced by a fully matured form of the trending prototype microwave air-breathing plasma thruster, which in turn would be complemented with (if I may go there) Methallic Hydrogen + (LH2 or Water) bipropellant rockets.

Two very important reasons why air-breathing/spaceplane SSTO can't be done yet are: Producing hull materials that can survive shock heating at speeds over Mach 3. The X-15 rocketplane and X-33 VTHL easily come to mind. Carbon fibre and ALON transparent ceramic are the best materials I'm aware of, but who knows how well they've been tested. Scramjet tech hasn't developed much, and might be on the backburner (thanks to Skylon precooler testing making progress) as far as John Public gets to know. The core of the scramjet problem is how to keep the pilot light/ flame holder from being yoinked when supersonic air is rushing by it in the combustion chamber.

Actually no I have not see that! Thanks for the link!

I finally rebuilt my BattMan (see: KSP battery labels) Tumbler. It was meant to be my entry into the 2017 DAKAR challenge but the craft file quickly poofed out of existence. The visible wing segments are all Tweakscaled to 40% or 70%. Some further changes may be pending (like enlarging the rear wheels) and it's not identical to the original but I'm quite happy with how it turned out. ..

I've wound up providing support for 3 tech trees in OPT Spaceplane Parts. (Updating existing CTT support; and creating support for Tetrix and RP-0). Fuselages and wings bundle up very nicely. Those are most of the parts, but the challenge remains in that the engines are truly various in nature so they still end up scattered pretty widely. With that and the rising provision for tech branches specific to solid and hydrolox rocketry, I've seen the potential need to also tag engines by their propellant and possibly their type, in a more flexible but precise way than targeting the engineType key inside ModuleEngines(FX) {}. I see OPT's engines as hydrolox (so they are placed accordingly in the hydrolox branch) meanwhile Airplane Plus' engines would remain LFO. OPT also has scramjet and TBCC engines, plus RP-0 has an actual Scramjets tech node so I populated that. Following that I would see something like techEngineFuel, techEngineType happening. It would be like the subcategory = 0 key/value you see in many part configs but actually useful in this case. This key pairing would allow for great precision whereas stock ( engineType) just has SOLID_BOOSTER, LIQUIDFUEL, TURBINE, NUCLEAR, ELECTRIC... but we would want to see: // Choose one value for each key or don't set the key. // The part can be targeted for defaults in the asbence of the key(s) // First listed value is the default // Propellant dimension techEngineFuel = liquid, solid, hydrogen, methane, mono, air, atm, metal, electric, exotic // Class dimension techEngineType = rocket, hybridEngine, propfan, turbojet, ramjet, scramjet, atomicjet, atomicrocket, ion, torch // * exotic is a catch-all for sci-fi and fantasy fuels like // USI's Karborundum, WBI's Graviolium, OPT Dark Goo, Taurusfecallium... // * air vs atm is to distinguish between air-breathing engines // that rely on Oxygen or can do without. See IntakeAir vs IntakeAtm usage. // * hybridEngine can refer to either hybrid solids that accept // SolidFuel + a liquid Oxidizer, // or engines that are jet + rocket like the RAPIER. // * ramjet may not be popular now but I'm making use of it myself in engine concepts.

I have unleashed dust bunnies upon the stock planets. .

The already highly anticipated party pack for @Nertea 's ISRU overhaul, Space Dust. Dust Bunnies ensures the presence of not only the resources used by his mods but resources relevant to some popular outside use cases: Life support, Mars Direct, Exotic rocketry. Space Dust + Dust Bunnies can run in parallel with Rational Resources. Note that converter and tank patches will not be provided here. Only resource placement and the related options for the scanners and harvesters. Use Rational Resources Parts and your favorite fuel switch mod for those. You will find LqdAmmonia, LqdCO2, LqdDeuterium, LqdMethane, LqdNitrogen, Rock and Water (the added resources) in many interesting new places. Let me know if I should switch out Oxidizer for LqdOxygen. Supports: Stock JNSQ Support is planned for: OPM No promises on an RR-alike template system happening. The resource placement nodes here have a higher granularity and complexity than stock ones. DOWNLOAD :: GITHUB License: MIT