undercoveryankee

KW parts use stock modules only (no third-party plugins) so all of the parts still work in 0.90. Since the configs were written on older versions, we're relying on the automatic process of assigning "propulsion" parts to the "engine" and "fuel tank" categories. Some parts may land in counterintuitive places. That wasn't enough of a change to be worth packaging a new version, so nobody has updated KerbalStuff. Go ahead and run the current version on 0.90.

The B9 2.5m cockpit was designed with a similar window layout to the old Squad Mk3 cockpit, so it would be able to share whatever IVA Squad added to the Mk3. Since the Squad part is gone, the only IVA that was ever made for that window layout is by TouhouTorpedo and hasn't been distributed since Spaceport shut down.

The KineTech plugin provides various modules that control an animation on a part based on some other parameter (throttle, speed, altitude, atmospheric pressure, and the like). Some B9 parts have Kinetech-controlled animations that won't play if you remove the plugin, but I don't think it does anything that would keep the parts from functioning.

It's like trying to detect the original Firespitter parts with :NEEDS[Firespitter]. How much would it break to have the RSS plugin itself under a separate name/folder something like "RSSPlanetConfigurator" and then allow the actual config files and textures to be loaded from a folder named after the config pack? So "RealSolarSystem" would always be the configs that ship with RSS, and 64k, for example, would be able to keep all of its RSS configs and textures inside its own "64k" folder. The issue would be when and how you detect that there's more than one pack installed and let the user choose.

Fractal hasn't updated since his 0.13 release that runs on 0.25. Boris's bug-fix branch provides basically the original experience on 0.90, and then there are one or two extension/rebalance forks downstream of that. None of them are "official" that I know of, and I can't tell any clear winner on market share. I'm not sure whose release to recommend either.

Boris-Barboris is shipping CRP with his branch of Interstellar and using the resource definitions. He's still using ORS for scanning and extraction, though.

That's one advantage of using the table over the kOS approach: with the kOS approach, the final node is the one you have to set by hand before auto-generating the ones closer to you. Setting a node 90 hours out is a problem with my idea, not yours.

There was a bug in KSP versions before 0.25 where you had to set those scale factors to the reciprocal of the part's rescaleFactor to get it to actually come out the intended size. It looks like the instant-power configs didn't get the scaling update applied when the main configs were updated for 0.25.

I think I can translate the spreadsheet into a kOS script. I'm picturing a workflow where you create a maneuver node for an all-at-once departure burn, then run the program to generate a sequence of nodes with the final burn at the time of the input node. Setting a node 90 hours out while you're in LKO is probably easier with a node-editor mod than with the stock +/- 1 orbit buttons, but that part can be left as an exercise for the reader for now.

Or the old bug when a scaled model was the root part isn't quite squashed yet.

I'm pretty sure the 1.25 and 2.5 KW fairings share a model. If I were modeling a 1.25 expanded fairing specifically, the lander can would be an obvious thing to check. But if I had already completed and tested the model at 2.5m scale, I could understand going with the shape I liked at 2.5 even if it was awkward with a couple of designs at 1.25.

To explain: the "spoiler" setting on a control surface tries to deflect the control surface upward to kill lift and push the aircraft down onto the runway. Generating drag is only a side effect. If a control surface is exactly vertical, it's a toss-up which direction FAR will decide is "up," and there's a good chance that two vertical spoilers in basically the same place will decide to go the same direction. Rotating each surface by one notch so it has an unambiguous "up" direction allows you to control what it does and trick it into serving a purpose it wasn't meant to do. - - - Updated - - - If you're still getting the isShielded indicator with FAR set not to display shielding, that's a problem. FAR is either failing to write its settings file or failing to honor the setting. Would anyone who's seeing this mind sharing a Unity log of a KSP session where you toggled the setting?

Yes, you delete top-level nodes (e.g. PART) the same way you delete lower-level nodes: !PART[criteria] { }. "-PART" is most likely synonymous with "!PART", but the "!PART" version is more common in the wild. Include the curly braces so the parser knows that the thing you're deleting is a node.

I try to keep stock parts balanced to their stock values. I've made a few minor tech tree changes to suit my mod selection and play style: moved the stock launch escape system up to the same tech node as the command pod and the RTG up to Nuclear Power. Beyond that I have a couple of local changes to mods. I felt like the 2.5m engines in KW Rocketry had become useless after 0.24 buffed the Mainsail and Skipper, so I moved the KW engines to fit between the stock engines on about the same thrust/Isp curve. I also created a custom 2.5m probe core with built-in kOS because it's hard to use the 1.25m kOS box in a 2.5m launch vehicle.

No. All textures and models in GameData are loaded into memory whether they're ever referenced by a part or not. Even deleting the part's original .cfg without also deleting the models and textures will leave you with no real savings.

The KR-7 is useful for "active vessel" or spare dishes that need to go all the way out to the edge of the SoI, because the DTS-M1 doesn't go much beyond Minmus. Once you're using one or two KR-7 for that type of role, using KR-7 for Minmus as well is a matter of aesthetics and symmetry.

The equipment to condense oxygen and store it for later is bulky and heavy. The cost of lifting it even on a reusable-jet first stage is likely to be greater than the cost of lifting the oxidizer for the entire vacuum phase of the mission from the ground. Trying to feed a conventional rocket engine with harvested oxygen in real time is similarly heavier and more complex than existing air-breathing engine designs. The closest to this that you're likely to see is something like the Skylon/SABRE concept where you use advanced air-breathing engines to get as high and fast as possible before switching to stored oxygen.

64k tries to match the RT ground stations to the launch sites, but the numbers in LaunchSites.cfg don't quite match up with the ones for RemoteTech. The coordinates in the current GitHub master put KSC's RT station about 0.17 degrees west and 0.06 degrees south of KSC's origin. On the bigger planet, that's in the neighborhood of 12 or 13 km.

Some modules get reinitialized on database reload in a different order than they were initialized on game startup, which causes plugins that make assumptions about what exists when their modules are initializing to throw exceptions. Many of these exceptions are harmless unless they keep KSP from finishing what it was doing, but they take up log space and the log file writes cost you performance. It's most likely not a bug in ExceptionDetector, although you'll want to find the full stack traces in the Unity log and confirm that the decide-what-plugin-to-blame logic agrees with your own judgment. - - - Updated - - - Those glitches that you mentioned tend to be triggered by TweakScale or TweakableEverything.

If you're playing without a part-failures mod, fuel toxicity and instability are mostly concerns for the designers of the parts and fueling systems. Life support shouldn't really be affected because crew wouldn't be exposed to fuel unless something fails. In KSP terms, fuel-handling difficulties should mostly be reflected in higher costs for those fuels and parts using them. If you are playing with random part failures, difficult fuels should have appropriate modifiers to failure probability and damage. - - - Updated - - - ModuleManager isn't quite smart enough to figure out whether you have engines that aren't managed by Stockalike that might want those fuels. It's even harder to figure out whether some mod might be using those resources for something that isn't an engine. I think showing everything that's available for the tank type is going to be the most reliable approach.

RSS changes the latitude and longitude of the launch site, but the config file that moves RT's ground stations is part of Realism Overhaul. If you're playing RSS without Realism Overhaul, you're probably a lot more than 3 km from the nearest ground station.

The flexotube uses the same modules as KAS's pipe, just with models that look big enough to walk or crawl through. KAS could probably package the models MKS is using without violence to the license until someone has time to do it in a different art style.

I would guess that "IX" just comes from "Ion" and "Xenon".

The stock OX-STAT and small folding solar panels should all be storable and attachable. If they aren't, you have some type of installation issue that's keeping the ModuleManager patches from being applied.

Those context menu entries are provided for debugging and aren't displayed unless you've specifically enabled them in your FAR settings. For diagnostic output, I like to see the internal name in the debugging display as a reminder of what it's called if I'm working on something that needs to refer to it by name.