undercoveryankee

What you want is for everything under GameData in the zip to end up under the main GameData in your KSP install. The quickest way to do this on Windows is to extract or copy the zip's GameData folder itself to the top-level KSP folder where KSP's GameData lives. But it's the end goal that matters: You should have Kerbal Space Program\GameData\WarpPlugin, Kerbal Space Program\GameData\OpenResourceSystem, and the same for the third-party dependencies in the zip.

When a program releases throttle, by ending or by UNLOCK THROTTLE, it goes back to whatever was set before the program took control. This will be 50% if you started the program on the launch pad without first resetting throttle.

Most Interstellar parts actually have the techRequired in their config files set to a stock node out of the box, with entries in tree.cfg for TreeLoader to override those assignments if it works. The workaround is to pull TreeLoader so it doesn't try to tamper with those assignments, then edit the techRequired of any parts that are missing.

Viewing the maps and tracking background ships' scans has been moved from individual parts to the flight scene. It works whenever you're controlling a ship, with no need for any particular part or module. The controls are available through a button on blizzy's toolbar. If you don't want to use the Toolbar, you need a SCANsat part to get any of the windows open without the Toolbar.

Some Windows installations block loading of plugins from anywhere under Program Files. Instead of installing mods to the KSP folder inside your Steam Library, try copying KSP to a location outside Program Files and running that copy with mods.

The stock experiment module doesn't support consuming resources. There's a module in Station Science for that, but this package has a goal of avoiding dependencies.

ModuleManager's syntax hasn't changed, so it will parse the file. Some of those parts are included in the general part renaming that took place in 0.25, so you'll have to check their config files for their new names. Also check the RemoteTech changelog. RT 1.5 includes a fix for that bug.

The ! and @ operators select on child nodes with a specified name attribute. Since CrewCapacity is an attribute, you want the #/~ operator pair, e.g. HAS[~CrewCapacity[0],#CrewCapacity[*]].

Some of the greenhouse mods will use it, but the Waste-consumer I'm most likely to have installed is MKS.

SCANsat follows the "even-numbered releases are stable; odd-numbered versions are prerelease" convention. 8 is the stable release that's compatible with 0.25. 7 is the prerelease of 8.

Missiles probably have it, as part of a philosophy of using whatever sources of information are working at any given moment. Civilian GPS receivers are required to cut out if they exceed specified speed and altitude limits so they can't be used to guide missiles off the shelf.

More specifically, a star tracker tells you your orientation relative to the background stars, which are far enough away that their directions are basically parallel anywhere in the solar system. To get position, you need angles or distances to objects within the solar system. A sailor with a sextant uses angles between the Sun, Moon, and stars and Earth's horizon, along with the most accurate clock he can afford to carry, to find the location on Earth where gravity points the right direction relative to the stars he can see. If you were navigating a spacecraft without help from the ground, you or your instruments would be doing basically the same thing, using measurements like "angle between a star and the nearest edge of a nearby planet or moon" or "time when a star crosses the limb of a planet." The time when you gain or lose signal between the spacecraft and a particular relay station adds a valuable data point; for spacecraft doing burns on the far side of the moon, the time of reacquisition of signal was often the first indication the ground had of whether the burn had gone correctly. The ground has radars, telescopes, and better clocks, and whenever you have line of sight probably knows more about your position than you do. Since manual star sightings are slow and even automated star trackers can take a while to get their bearings after a major maneuver, spacecraft use various types of gyroscopes to maintain their orientation between sightings and correct any errors in real time. A modern inertial measurement unit also includes sensitive accelerometers to keep track of the actual acceleration the vehicle is experiencing. This is essential if you're in atmosphere and have to correct for wind, turbulence, or variations in engine performance moving you around. In space, many engines are predictable enough that burning for a calculated time is enough to achieve the necessary delta-v accuracy. If you're designing a vehicle where that's the case, you can use lighter or less expensive accelerometers because their purpose becomes catching equipment malfunctions. There are some cases in games where adding more realism to what's being simulated can make the outcomes less realistic. Yes, there's software available for real spacecraft to do everything that MechJeb offers, if not on the vehicle itself than by uplinking the results of calculations done on the ground. But there are tough design decisions about what sensors and how much drive space for software to put on a vehicle, so real spacecraft typically don't have the flexibility to command any maneuver you can design at any time. MechJeb by itself gives you the software that makes your life easier than stock KSP, while abstracting over the design decisions that are needed to make those capabilities work, so it's reasonable to find that hand-flying is a better-balanced game. It's one of those cases where making one aspect more realistic, without simulating other things that balance it, can give you a less realistic overall outcome. I use it so I can spend more time being creative and doing the interesting parts of missions and less time punching numbers into spreadsheets and flying routine mission profiles to lay the groundwork for the next interesting thing.

Nothke seems to have been focusing on bigger projects like Kerbin City when he's had time to work on KSP stuff. His last post on this thread was just after 0.24. The license allows redistribution of modifications, so if I come up with a stock-animation config that works I'll post a repack here.

The example matches parts that contain at least one resource, but none of those resources are ElectricCharge. It sounds like you want to match either 1) parts that contain ElectricCharge and no other resource, or 2) the inverse of that. I think you could match batteries (EC, but no other resource) with something like @PART[*]:HAS[@RESOURCE[ElectricCharge],!RESOURCE[*]:HAS[~name[ElectricCharge]]]. The shortest way that comes to mind to invert that test and match all non-batteries is to split it in half: @PART[*]:HAS[!RESOURCE[ElectricCharge]] matches parts with no EC, and @PART[*]:HAS[@RESOURCE[*]:HAS[~name[ElectricCharge]]] matches parts with non-EC resources.

These parts are now distributed as part of the USI Survivability Pack. The version included in the Survivability Pack has been updated for 0.25.

Waste is automatically discarded if all available waste storage is full. If you want to dump waste before the containers are full, I believe TAC Fuel Balancer can do that.

It's an intentional multiplier. Been in Github for about a month; this is the first released version it's appeared in. Brakes that are powerful enough to be useful in higher stock drag feel overpowered in FAR, so they are now multiplied by 0.2. If the brakes you're using are balanced for the older versions of FAR that didn't apply a multiplier and you decide you want to change it on the FAR side, it's on lines 112-119 of FerramAerospaceResearch.cfg.

TreeLoader has been partially broken since 0.24. On 0.24, you could work around it by manually installing the tree.cfg ( http://forum.kerbalspaceprogram.com/showthread.php?p=1445494#post1445494 ). If you've completed those steps on an install of 0.25 that has only the mods bundled with Interstellar, then 0.25 may have moved TreeLoader from "partly unusable" to "completely unusable".

For KSP 0.23 through 0.24.2, there were two required changes to each config file: change the name to something that isn't the same as the name of the fixed Alcubierre, and change TechRequired from ExperimentalElectrics to one of the Interstellar nodes if using the Interstellar tech tree (refer to tree.cfg for the names of the new nodes). Adding balanced costs would be nice, but not required to make the game work. For 0.25, they're probably also affected by the changes to model scaling. Once I figure that out, I'll probably just publish a repack that works out of the box.

KW parts use stock modules only, no plugins. There should be nothing in it to break. Unless one of the stock modules has different parameters or something has a zero entry cost and the game doesn't like that. Post a log (http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29) from the point where the game freezes. If something in KW needs to change, that will help us find out what.

There's a config file in 7rc5 (Resources/SCANresource.cfg) that maps between ORS keys and bits in the bitmask. Since I was going to share maps between Uraninite and Interstellar uranium, I was planning to put those maps on the bit previously assigned to Interstellar uranium. If the ORSX key is Uraninite, the patch to take over that bit would look like: @SCANSAT_SENSOR[Uranium] { @name = Uraninite } Now that I've had a chance to look at the files and seen that your ORSX key is Uranium, you can use the same configs that would scan Interstellar uranium.

https://github.com/FractalUK/KSPInterstellar/wiki/Alcubierre-Drive

I'm afraid publicizing the change or acting like it's a major feature will draw critics out of the woodwork. Might be better to make a generic change description like "Support for multiple kerbal models. Support for separate name pools per model." and let the fans figure out for themselves what it means.

You have ATM or TextureReplacer set to make textures not readable, and you don't have a config to designate that texture as readable.

There's a ModuleManager patch for node sizes a few thousand posts back: http://forum.kerbalspaceprogram.com/threads/43839-0-24-2-KSP-Interstellar-%28KSP-0-24-2-Support-25-09%29-Version-0-12-2?p=1093576&viewfull=1#post1093576. Anyone who's having trouble with node sizes can grab it, and it's probably a good place to start designing a native fix. Since CRP gets its life support resources from TAC, Water integration is part of my CRP integration pack. Here's an edit of my file for use if you have only TACLS: // KSPI/CRP Integration Pack // Convert Water to the resource used by TAC Life Support. @WARP_PLUGIN_SETTINGS:NEEDS[TacLifeSupport,WarpPlugin]:AFTER[WarpPlugin] { @WaterResourceName = Water } @PART[*]:HAS[@RESOURCE[LqdWater]]:NEEDS[TacLifeSupport,WarpPlugin]:AFTER[WarpPlugin] { @RESOURCE[LqdWater] { @name = Water } } @BASIC_NTR_PROPELLANT[Water]:NEEDS[TacLifeSupport,WarpPlugin]:AFTER[WarpPlugin] { @PROPELLANT[LqdWater] { @name = Water } } @PART[*]:HAS[@MODULE[FNModuleResourceExtraction]]:NEEDS[TacLifeSupport,WarpPlugin]:AFTER[WarpPlugin] { @MODULE[FNModuleResourceExtraction]:HAS[#resourceName[LqdWater]] { @resourceName = Water } }