JadeOfMaar

@Xd the great Thanks for noticing. Your changes have been made: The Mk3 and Mk4 pods all have control point toggles now. SuperHeavy 1.5 SL TWR Mk4 SL Raptors appropriately weaker than Mk4 Vac Raptors. I just added this (stock feature) too, so you can sort by rocket families. CCK doesn't allow that, I think, but it's very tedious to do this.

Tundra can work well in 1.7.3. But just expect that it will look sub-standard and the plugins (for the fins' ability to action group, and Starship's built-in legs) to fail. The Starship Mk3 and Mk4 parts are a whopping 5.6m size. That and how tall the stacks for these parts are, easily are quite OP for stock. They were tuned for JNSQ. I'm pretty sure it's just you. I tuned it and so put a lot of effort in. Then again, I don't know what the initial TWR of the IRL engine is supposed to look like so it may be on the conservative side.

@Critter79606 I'm seeing some things concerning ModularFuelTanks. I just released a revised MM patch for that and now I see that I didn't ensure that they don't apply at the same time. Delete OPT Reconfig's OPT_MFT_RF.cfg file and your problem should go away.

NodeHelper is an absolutely powerful tool. Godly, even. Every other month I find something new to do that benefits from having this around. Just the other day I setup 3-way and 6-way symmetry. Snowball's chance in the inferno, of making that happen without this mod. Thanks much for your efforts to keep this mod alive @linuxgurugamer. Actually, I think click-through blocker's influence will have a huge impact. I suffer a fair deal from exactly that at times.

OPT Legacy 1.5.0 All legacy engines: New plumes! New sounds! Added Restock DepthMask module to the following. This allows for parts to clip properly into each other and be less likely to show through where they should not, and for "low profile" engine assemblies to look better. See example above: All cockpits with built-in intakes. Mk2 and 2.5m (J92) intakes. All engines. Added missing lift surface ratings to these engines: All Mk2, Stail linear aerospike, J-81. Added re-entry grade airbrakes (cloned from B9 Aerospace). Added J cabin IVA to Humpback cabin. Adjusted engine performance for: J-81: Air-breathing performance buffed for thicker Oxygenated atmospheres. J-60D: ClosedCycle in thicker atmospheres. Might not be notice-able. Fixed missing default light action group in legacy J cockpit. Fixed low heat tolerance in J-60, J-60D engines. Were 2000K, now 2400 ~ 2700K. Fixed (Bandaged) intake module problem in Humpback cockpit. It's now actually useable and equivalent to 2x OPT Mk2 intake. Made the ARI-73 much more expensive with reference to its nuclear engine nature and unique advantages. Moved RCS plume assets to OPT_Reconfig. Removed many old configs. Some adjustments to costs and performance of engines. OPT Reconfig 1.8.0 All main engines: New plumes! New sounds! Added missing lift surface ratings to these engines: HAE-02 Mk2 engine, J Linear aerospike. Added surface attach to Mk2 Nose. Adjusted Power Sphere fusion selection. Some options are now only available when relevant mods are installed. Removed duplicate LqdHe3 option. Adjusted Dark Goo balance. Added mass. Slowed its consumption and production rates. Added immense buffs for Dark Drive to serve as a half-decent interstellar engine. Made Dark Drive incredibly more expensive to match. Revised MFT/RealFuels configs. DOWNLOAD - OPT Reconfig DOWNLOAD - OPT Legacy

Restock Depth Mask feature For all cockpits that have intakes, for the mk2 and J-92 intake, and for practically all of the engines! Coming very soon to OPT Legacy. With OPT themed, re-entry grade airbrakes! (From B9 Aerospace.)

@Fireheart318 I'll see about it. I can see the 3-way being angled 3 ways though so... a normal T style one? There's no Deep Sky Core thread. Any questions regarding that goes here.

@juanml82 I don't know for sure. But most of the mass of a water molecule is its Oxygen atom so that's what I went with.

I didn't anticipate that you''d go drilling for it, sorry. The problem (highlighted) is that you need to have some amount of available tankage for the resource you're drawing (even just 0.01 units max). Your craft simply cannot hold the resource so it declares itself "full." The ResourceName value needs to change from Water to LqdWater in RationalResourcesParts\CRP\zDrills_Stock.cfg Unfortunately that's one of a few very major flaws in the stock resource harvesting system. An atmo harvester's harvest rate depends firstly on how fast it's moving. The moments when you do receive something are because you're drifting at how many mm/s because of friction-less ground. Ideally it should work fine when sitting still but at some point it got unfixed and is going to be that way forever, probably. Edit: You might (also) need an extra ISRU module added somewhere that converts Water to LqdWater. It'll be a pain to change the references to "Water" in everything, especially all the resource placements.

With its simple codename "Hump" I created something that resembles and performs like the Avatar Cockpit Revival shuttle here... But I wanted something that could clearly and with less struggle, deliver payload to JNSQ LKO if I wanted it to. I also wanted it to be able to carry more payload so it has been well tested with 60 tons of Ammonia. So with the simple codename "Hump" this appeared. It features 8x Mk2 intake pods (I made the OPT Mk2 nose surface attachable), 2 of which are in the cockpit to make up for its broken intake feature. It features 2x J-60D and 2x Tweakscaled J-92 engines and hence, mostly relies on scramjet mode for the upper ascent TWR. Due to this reliance and the gluttony for air (of the enlarged scramjets) it's forced to take harsher burns from JNSQ's reentry fire and the cockpit is more often than not, brought to the edge of melting. Earlier images showing less of the Mk2 intake pods.

In the footsteps of the OPT Avatar Cockpit Revival spaceplane, I wanted to have a Humpback plane that could properly SSTO in JNSQ and deliver great payload (unlike the former). Its reliance on the scramjet mode dooms it to face JNSQ's particular reentry fires and makes for a tight-rope walk over keeping the cockpit from melting. It features 8x OPT Mk2 intake pods (I made the OPT Mk2 Nose surface-attachable), 2 of which are in the cockpit due to its broken intake transform. All of them are to feed the Tweakscaled J-92 engines (which become as heavy as Dark Drives). Landing on bingo fuel with its test payload of 60 tons of liquid Ammonia. Some prior industrial servings of developing a Skylon has enabled me to very safely land monsters like itself (as long as there's some Oxidizer to spare). Earlier picture showing just 2 of 4 intake pods.

Just install it. Like any other mod. You should end up with a GameData/CustomPreLaunchChecks/ and a GameData/KerbalKonstructs/ folder. But that's all you get. KerbalKonstructs alone is only the mod that makes anything else work that's related to it (like EVE is nothing without the content packs for it like SVE or Spectra). If you want to see complete bases or the statics to build your own bases you gotta download the content pack mods for those. To build or edit a base, press Ctrl+K while you're in the world with an "active vessel."

@Gameslinx @TarasK I don't get to see the original screenshot so my guess isn't sharp, but ResearchBodies is present due to "ProgressiveCBMaps.dll" mod DLL. Perhaps the bodies are somehow affected by ResearchBodies' weird planet shader effect?

@paul23 The number of physics calculations in a vessel scales in a great way (like logarithmic or exponential) as part count increases. A major thing is that KSP calculates how a certain part will respond to a physics interaction (like drag, thrust or impact) and how every other part will move and experience stress as a result of this certain part moving or turning-- like poking a puddle and causing a ripple. For me, I get very annoyed when a given craft's part count passes 100 and I consider KSP unplayable when total part count in physics range reaches 300. Some people have the patience to still play KSP when their "frames per second" becomes "seconds per frame" and wouldn't be troubled in your situation. If your station is doing too much (such as, it has lots of USI LS and MKS parts and all their converters are on) that will hurt you too. I assume you have lots of docked modules. These docked modules may likely have their own probe cores, batteries and RCS. This is bloat and should be replaced, as much as possible, with an orbital tug system (Only the tug will have the probe core, battery and (most of) the RCS.), and all extra RCS thrusters removed when no longer needed. If you have lots of open/unpaired un-shielded docking ports, they will create their own special kind of lag. Those are always scanning for whether another docking port is near and about to connect to them. Shielded docking ports have the ability to stop that scanning. USI Konstruction contains welding docking ports-- docking ports that vanish and directly attach the nearest parts behind them to each other. It's massively useful for permanent orbital stations and helping to control part count. If you have a mod that lets you destroy parts and reclaim resources from them, make more use of that mod, and if possible, install and use OSE Workshop to build (and put into inventory) bigger, better versions of the weaker parts that you have been spamming. One large solar panel from the Near Future Solar mod will save you from spamming stock Gigantors. If you have lots of ladders (especially for aesthetic value) then definitely remove them. 99% of the time, there won't be a kerbal holding onto them, and when a kerbal is holding on, it will be to 1% of the total amount of ladder. That's also an enormous waste of CPU. Instead, have the kerbal carry a single ladder and a tool in their inventory. If the kerbal needs to hold onto a particular place while working, have them bolt the ladder on where needed. With how long KIS has been around, it would surely be able to have stored parts not count so I think you're safe with many incredibly full containers. Finally: Just install an FPS counter app (I use the freeware "FRAPS") or such a mod and watch how the numbers change. I'm pretty sure LinuxGuruGamer owns one.

@juanml82 No it wouldn't. The config I offered you doesn't change a B9 subtype. It creates/adds one. You will have the Water and LqdWater options together. I'm planning on supporting Alumina and Mopedantte [forum censor] (these are particular to KSPI) and introducing ISRU chains to make them useful. Alumina to produce Oxygen, Metal(s) and SolidFuel. (To be availed in EL recipes.) Mopedantte to produce RareMetals, Oxygen and Phosphorous. Phosphorous is super rare in nature and largely found in living beings so it has a great potential in-game for farming money and fitting into obscure life support related processes. Carbon (not mine-able but received from the prior existing CO2 splitter process) which could go with Water or Hydrolox (IRL it would actually go with Phenols but I don't want to implement those. The end of this process would be Ablator. (Also to be availed in EL recipes.) Given that Ablator and SolidFuel are non-transferrable, I have the idea to introduce an intermediate process that requires a staffed science lab or other appropriate part for industrial processes to produce employ CRP/USI Chemicals which is then consumed by a converter module in the SRB or the heatshield. This idea targets players who develop reentry vehicles from outposts in vacuum or who experiment in reusable SRBs and vacuum-only SRBs. I read something about proposals for cheap lunar-based SSTOs. Furthermore I've entertained for a long time, the concept(s) of making parts from mods (according to certain themes they follow) have requirements for different combinations of resources and diverge from the one-size-fits-all solution of MaterialKits or RocketParts for everything... Particularly parts that aren't actually rocket parts (see: base parts mods, science experiment packs, glass domes, Of course this means a lot of complexity and it reaches into RealISRU territory and will likely remain a pipe dream/daydream. Since I very rarely casually play, I won't have it in me to enjoy and develop this for myself. I could start these but I'd need to see some sufficient evidence of demand for these things. Base parts like Firma (Screenshot) which are built from the crustal material around them (see: Mars 3D printed habitats) may require mainly Rock or Silicates. Tundra Exploration's Starship would have required mainly Carbon (while SpaceX was focused on using Carbon Fiber). Glass parts (screenshot) would require mostly or only Silicates. WBI Pathfinder does something like this for itself already, requiring lots of its own Equipment or Konkrete resources. Equipment is equivalent to MaterialKits and Konkrete is largely made from Rock, Slag and possibly Water.

In RR's Extras folder is a config that applies RR's fuel options to tanks that have the stock manufacturers. I haven't tested whether it applies to any fuel tanks added by Restock Plus but it should, and nobody has asked to provide this feature for any popular rocket part mod's tanks. Also in RR's Extras folder is a config that provides the Ore tank options to all of SSPXr's parts, however, I do not provide fuel as SSPXr explicitly is not meant to hold propellants, and LqdCO2 is good for nothing but propellant and fire suppression. I would therefore go after NF Launch Vehicles and CryoTanks. I remember that a "liquid water" exists in KSPI but I do not know its internal name (likely abbreviated) so you'll have to find that yourself and change it from "LqdWater" if this is incorrect. It occurs 3 times in the example config below. Save this config anywhere in GameData and it should work for you.

Release 1.0.3 Added Restock+ new Ore tanks (KSP 1.8) to Ore tank resource switching. Fixed missing Water in Duna and Laythe polar regions without JNSQ. Fixed specific restrictions at Mun Polar Crater without JNSQ. Fixed missing NEEDS in OPM patch. Download links in thread OP

@juanml82 It is. I have that set up already. However, I just looked and confirmed that I have the biome name very wrong. I expected "IceCaps" but it's actually "Poles." I'll have an update out soon.

This amuses me.

I'm pretty sure that's a stock bug feature.

I'm resurrecting @CaptainKipard 's WIP Skylon C2 from late 2014. I've stripped out its dependency on Firespitter and done a ton of work to make it playable in today's KSP. However, even with current Firespitter installed (before I stripped it out), the main wheels don't work well. (Stack node attached wheels may generally be "brittle" no matter how strong they are.) Maybe the configs themselves need to be rewritten. Anyway, I would like these to be usable with stock modules or KSPWheel/KerbalFoundries. If there's a kind soul out there who's willing and able to re-animate and re-config these, I'd be very grateful. I can send .blend files. If nobody is out there, I'll make do with cloned stock wheels and fill in the open sections because the Skylon wheels are the hull cutout style and won't visually fit at all with anything else. Black 2x stock medium wheel for the nose. Cutout style Skylon wheels + repainted stock wheels

@Xyphos I don't know how to add and use your own icon but according to a source, you have all of these built-in options to choose from: Look for the key stagingIcon = X in the config of any engine or decoupler for live examples.

Since Damon mentions AlphaMensae immediately above the second image, you must go here:

@ztoundas I can't help with bicouplers and tricouplers, sorry. I tend not to use those or not pay attention to potential aero issues in their general areas. I do tend to use the OPT J quadcoupler often, and when I only need to use 2 of the rear nodes (which is half of the time) I cap off the other two with nose cones larger than their nose size to try and meet that difference. I'm testing another part mod right now and I had to add an attach node to its most troublesome adapter parts, facing in the necessary direction, in order to make room for that "counterweight" nose cone.

@ztoundas The second value in the triplet is the drag coefficient (not necessarily the coefficient of any particular axis). It is in effect the bluntness or steepness rating of the part. 1 = fully blunt; 0 = fully pointy; but note that the majority of pointy parts (in stock) are rated at about 0.37 which gives you a good sense of scale for this number. The M2X super-pointy nose or tail might have a noticeably lower Y+ (but not Y-) value. Congrats on that progress there.