JadeOfMaar

How you use MOLE boils down to: You first need to unlock the science processor (I forget its exact name) which sips on time, EC and ResearchKits and produces LabTime. This simulates the experiment running and being observed (as is the nature of LDEF (Long-Duration Exposure Facility) experiments). You need to unlock the experiment wedges themselves and preferably, the mounting structures for them. Once you have them, check their advanced info and see what their requirements are. Some demand certain stock experiments, some demand certain situations, some demand crew, some even demand resources. The Botany experiment requires parts that can produce "Plants" and these include a botany wedge or a MOLE greenhouse. All experiments require LabTime. That's the default. Some science parts have the ability to load multiple LDEF experiments into them such as MOLE itself (in the proper science lab mode), the WBI Buckboards, and the stock Experiment Storage Unit (actually I think this only holds 1). The MOLE lab and compatible labs also hold a LabTime generator which you can supplement with the wedges for the same. And you'll want to. Time is precious. MOLE labs also have a feature or a mode just like the stock science lab. These require scientists and sip on EC + something (I don't remember, likely ResearchKits) and produce science points that you transmit back to KSC. I like it much more than the stock science data processor. ResearchKits largely replaces the Science Data mechanism, and with some effort and the requirements, a base or station can make new ResearchKits.

@Jimbodiah Speak of the devil. I'm betting RSSVE has obsolete, broken sunflare configs. scatterer has had a few breaking updates recently, after all, one of which was the change of config syntax at about KSP 1.6.

I cloned the Whiplash engine and made a proper ramjet out of it. Inoperable under Mach 2.7 but enables cruising speeds between Mach 5 and 6 and is super efficient at top speeds. Triumphantly, I landed at Darude while flying westward from the launchsite. Fortunately (or not) there was no sandstorm.

JNSQ has a few of its own extra space centers, airports and misc facilities (currently just mountaintop observatories). Some of these (currently just the observatory centers) are marked as anomalies and not readily accessible to the player. And eventually there will be more places like shoreline or mid-ocean bases (for boats to pit-stop at) and more biomes, primarily Kerbin's oceans. Currently there are: 9 large airports (all with always-on short-range groundstations) 2 mountain-top observatories The DLC-replacer space centers (2) 4 alternate major space centers The airplane boneyard near the KSC 2 harbors Tundra's (extra) Space Center when KSC Extended is present The Island Airfield KSC2 (whose existence I may challenge) More KK stuff is planned to come, and not just space centers. There will be plenty to fill the spoilers category with, in due time.

You'd have to edit our TweakChutes config and add the proper needs so that it doesn't activate for the particular mod it's conflicting with. Is this "RealChute Lite" a mod with its own name or is it merely a feature within FAR? In case of the latter, then you should write :NEEDS[!FerramAerospaceResearch]

This pair of mods is absolutely powerful for whatever you're thinking of and far better than what you think you want the devs to do for you. Once you settle into using them, it becomes a simple matter of sharing the waypoint coordinates of the places you want, in plain text, and you can easily set and see in-game, any interesting locations that other players share. I personally haven't seen the several custom waypoints that come with Waypoint Manager (maybe they are career only? I don't play career) but from what it looks like, with just a little text editor skill, you can simply copy the waypoint data out of your save file and into a new config file, and share that around.

@zer0Kerbal Just declare it --> scale = 1.0, 1.0, 1.0 If the key exists already then prefix it with % as this means "Edit if it exists, create if it doesn't exist." --> %scale = 1, 1, 1 ...I suppose MM will let you do math on all the array items at once. Try this: @scale[*, ] *= 1

Now that is nice.

Technically that's what the included PDF is for. If you're looking for different content than from the PDF (basically just stats) then do describe your vision for this reference. We can't promise your idea will happen though. There's plenty on our plates.

@zer0Kerbal This is how you target an item in an array. @node_stack_top[1, ] *= 1 // the space within the [] is important. Do not remove that. And yes, the index starts with 0.

If that's how it is in the download itself then that download is in error. I suggest you try the nearest compatible version and confirm this is not happening in those too.

I like what's going on here. I would agree that it would fit here very nicely. I just have a few questions regarding the characteristics of a Cold Plasma engine. I assume that for jet engines (as you showed "EngineType = Turbine") it works well in the turbojet and ramjet performance envelopes. How do I handle the "monoprop" Plasma rocket mode? With such high given thrust (no engine diameter is given) I must assume that its Isp is very low. If it's meant to have very high Isp then I'm going to trade a lot of that thrust away. Note: When you give only one propellant (with mass) to an engine, set its ratio to 1. It makes no sense to give a different value because there are no other propellants (that have mass) to factor it into a ratio with. If you want the one propellant to be consumed more, lower the Isp numbers in atmCurve{}. I don't have a concrete grasp on the combustion potential of Cold Plasma. Am I to presume high power with low exhaust velocity (chemical rockets-- LFO? LH2?), low or moderate power with high exhaust velocity (magnetoplasmadynamics, namely the heavy ion engines in NF Propulsion) or high power with high velocity (nuclear pulse or torch drive)? If it's the nuclear pulse sort, I'll need to look into ways to nerf this as it instantly becomes too OP. Does the presence of Oxygen mean much regarding combustion potential? I assume that any CP engine's thrust will take a hard hit in atmospheres like Nitrogen-only or Carbon Dioxide-- or will get a strong buff from breathable atmosphere. This was meant to be the case when I first made Thor Tech but I didn't yet know of any means to actualize this difference in operations... I could do that now, thanks to B9PS, but I won't.

Maybe? ... KK bugs. OSS hasn't been updated to use the new shaders. Anything with the launchsite feature enabled -- KK is unable to read the grass color modules and defaults on them. The same happens to the runways at all of JNSQ's airports and will happen to KerbinSide's runways. ... I just learned the other day that the kerbals need to be held first in a KK static that has the barracks module. I typically only give this feature to the astronaut complex static which KSC Ex and TSC do not have. I should deal with that.

@Titan 3001 You have an interesting situation. WBI has an alternate resource system and a play mode for it. When any one mode is active, its configs have the .cfg extension and are read by KSP. The other modes' configs are disabled, renamed to .txt. Your log tells me that you have .cfg and .txt files for every mode which is a total mess. You'll need to delete and reinstall all of the WBI mods to fix that. That should be enough.

@zer0Kerbal @Jiraiyah I fixed that for ya. @PART[DM-SphericalTank-*]:NEEDS[B9PartSwitch,CommunityResourcePack,UmbraSpaceIndustries] { @MODULE[ModuleB9PartSwitch]:HAS[#moduleID[SphericalTankFuelSwitch]] { SUBTYPE:NEEDS[UmbraSpaceIndustries/Karbonite] { name = #DST_name_karbonite // = Karbonite title = #DST_title_karbonite // = Karbonite tankType = DSTKarbonite } SUBTYPE:NEEDS[UmbraSpaceIndustries/KarbonitePlus] { name = #DST_name_karborundum // = Karborundum title = #DST_title_karborundum // = Karborundum tankType = DSTKarborundum } } } There's no point in setting a NEEDS for the same mod that it's a part of. And the AFTER is invalid. AFTER[SphericalTanks] assumes that GameData/SphericalTanks/ exists, which it does not and is not part of this mod. The target parts array is condensed since all the target parts have a very large common section in their names. I know, right? They should be 2000K. 2900K is higher than the Mk3 plane parts and entering heatshield or fairing territory. I like that the fuselage parts have a bicoupler thing going on. I could add nodes for those if anyone wants them.

Ever since I heard that this was a thing I've thought about it, very rarely concerning KSP actually, but still a lot. My interest in it has been indirectly sustained by my involvement with Angel-125's mods, namely the ones that do use an "ElectroPlasma" resource which is a product of fusion reactors. I'm currently messing around with JPLRepo's Endurance mod and I've upgraded its power and engine systems to involve ElectroPlasma, but its RCS have only been raised to ArcJet level. I haven't thought of actual plasma RCS thrusters. Getting back to Thor Tech: Its shield generators also have an alternator to them. Electromagnetism is a 2-way street so the generators, once they start producing Shieldnir, will return some EC from Shieldnir. This benefit is small but is best experienced when they're shut off, or in some extreme edge case that I can't imagine. Thor Tech itself doesn't include a fusion reactor as it's arguably out of scope for why I built this mod, and because i was inexperienced with Core Heat. But now I'd like to possibly change that and add at least one engine that uses hot plasma and involves a lot of heat. An end-game deep space engine to aspire to, to complement the existing WarpJet engines that rule atmospheric flight. I've been leaning towards the idea of a small scale torch drive which can accept nearly anything for its propellant. How that'll work in-game is already planned out and can be done with just stock modules and one pseudo resource. The plasma aerospikes which are loved already... are only mid-game.

TweakChutes was created to answer two problems: "Okay, we have a Mars-like planet in stock. It has some considerable atmosphere. But for this planet pack we want it to be next-to-gone like real Mars so players will approach it like real space agencies do: drogues + powered landings only. There is literally not enough atmosphere for main chutes to work properly on, no matter what their size. And if you manage to bring nearly enough chutes, their masses might add up to a noticeable, insane amount." Stock chutes actually have a serious bug. They do not ensure to meet the partial deploy check before they meet the full deploy check. Let's fix that too. Drogues can ofc full deploy on JNSQ Duna, but the altitude of the minimum full deploy limit for main chutes is far too close to sea level and nobody will want to play that game. There's no winning it....unless you are Bradley Whistance. (I might be remembering something wrong here. Here's to OhioBob stepping in and correcting me if needed )

I assume you mean there's too much acceleration. My guess is to go after maxMotorTorque first. (I don't know better. I'm not much of a car parts enthusiast. But I assume this represents the raw power out of the cylinders and crankshaft.) And thanks for the Thor Tech love.

@Azic Minar Regular heat has some flexibility already. Not much, but likely equal to or greater than the amount that can be done with Core Heat. The ablator module can be customized to kick in at any temperature that a given part reaches, customized to use any resource that has a non-zero "hsp" value in its definition, and it has an alternator (typically used in RO to produce "CharredAblator"). This allows for the immediate use of special ISRU chains that depend on parts being heated externally in conventional fashions. The great things I've done with the heating systems so far are: In Thor Tech, my intermediate super radiator draws nearly a megawatt of heat from around the vessel but doesn't have much capacity for thermal mass so it's like a heat exchanger/capacitor and it saturates very fast. It accepts a number of resources to convert any one of them at a time or in parallel into a pseudo resource "_Cooler" and then ablates this resource to quickly dump its gathered heat. Instead of costing lots of EC, it costs you in payload capacity to bring along its accepted input resources if you choose to use this part. In Thor Tech, my far future TCS (thermal control system, based on the real concept of EM shield ablator) adds the ablator module to nearly everything that doesn't have it already, with differing strengths depending on the use cases of each part, and feeds these ablators with the "_Shieldnir" pseudo resource. The protected parts don't need to hold this resource themselves. Shieldnir, by nature, is OP and is meant for use on landers and ascent craft on Eve and harder planets, not for use on Kerbin. The challenge of Shieldnir lies in: bringing along enough of the Shieldnir generators; dealing with their masses; avoiding exceeding their output capacities in the extreme phases of ascent and reentry; protecting your power sources from overheating while feeding the Shieldnir generators; protecting parts that get less protection as not all parts can be equally shielded. In Rational Resources, my implementation of a thermonuclear turobjet is that it uses a converter with Core Heat to produce ThermalPower resource to be consumed by the engine module. The part is configured such that when it runs for a long time at high thrust (or extreme thrust in thick atmo like on Eve) the converter's core temperature will rise due to the radiators being saturated by both core heat and engine heat production. As this happens the ThermalPower production capacity goes down (loss of efficiency due to overheat). When the engine reaches a certain fraction of its heat tolerance the converter shuts off and the engine itself gets to run for up to 10 seconds on its ThermalPower buffer before "cooling down rapidly" and having a flameout. In Rational Resources, there is a "blacksmith" system that simulates the science lab having a forge and its furnace inside, and the kerbals carrying motlen material with them on EVA (let's say, via industrial heat resistant hoses and spray guns) to refill Ablator on heatshields for interplanetary landers that try to use their heatshields more than once. The heatshields themselves receive a converter that accepts "work," ThermalPower and an input resource or two and generate Ablator within themselves for this since Ablator is non-transferable. In Rational Resources, not only the Blacksmith system... but the Restock MonoProp APU also uses CoreHeat primarily for its spooling effect. The APU is described as a turbine and has no real business with the "overheat" situations so the APU uses this only for the effect of revving up, not starting instantly, and never needs a radiator once it reaches its core temp goal.

Seriously... I hadn't thought of it. I mention that need in the OP of this thread and on GitHub. Sorry, dude. Will fix.

@linuxgurugamer Delivering more things we didn't know we needed! Epic "YES!" gif in the spoiler

Sorry for derailing thread, Shadowmage. @adsii1970 A few of us are aware of the wider possibilities for the use of Core Heat. Unfortunately, it was only implemented in KSP for one purpose-- to make the ISRU parts overheat and to demand cooling. By consequence this is the one job of the radiator system. Unfortunately there is no means (that I know of) for part or module A to tap into core heat produced by part or module B; neither is there any means to readily convert between regular heat and core heat; neither any means to readily use core heat as an input or output in other module functions so it's effectively a small, useless, walled garden. If Core Heat was this flexible then we could have simplified forms for the awesome yet overbearing thermodynamics system in KSP Interstellar and achieve things like: solar thermal; parts having operating temp limits-- not just overheat but overcool; proper stirling engines/other thermoelectric generators.

A couple of KSP players are fans of the concept of stage-able radiators as seen in Elite: Dangerous. And Thor Tech (one of my oldest mods, and one I'm no longer very proud of) provides two exceptional means for managing extreme heat... Not including stage-able radiators. Thanks for the motivation to return to Thor Tech. I can do this easily...And I want to. I'm well-versed in Core Heat now, enough to produce documentation for how to precisely tune it for a given converter and I can even use Core Heat just to spool the converter and cease to produce internal heat (never need a radiator) when it reaches its core temperature goal. This is amusing and somewhat appropriate for any power source that relies on revving up internal spinning parts such as turbine APUs.

@damonvv Breh. :U Format yo' changelog post please.

@Borkman6 @banditsan That's not file corruption. That's the Restock DepthMask feature introduced in KSP 1.8... For KSP 1.7 and older you must delete the OPT_Legacy/Parts/DepthMasks/ folder.