Drake1500

You could change the filter to just the mods you've installed (Click the magnifying glass at the top), and then uncheck all your mods. Not quite a one-click solution, but it does make it much easier.

Does this mean that if FMRS is active, StageRecovery will not fire? I thought that perhaps I had hit a bug when SR refused to recover my spent stages, until I tried turning FMRS off.

I concur. Usually, I only use this in-flight, and only display the available experiments, which means much of the time there is a lot of blank space on its screen. A way to resize it would be greatly appreciated.

If that question was towards me... unlikely, but possible, as I've been playing around with adding more mods than the ones listed above, with Interstellar being one of them. However, I have added a LOT of mods, and were I to add KM to that install, I'd want to add it to everything, and that would be quite a bit of work, more than I'm willing to put in at this moment. I've been thinking about the failure on decouplers, though, and I've realized that this is annoying in the late game, but crippling in the early game. In the very first stages of the space program, once you unlock decouplers you have a short period where if they fail in the atmosphere, your mission fails. Jeb dies. End of story. Until you revert to launch. Then, once you get a bit farther, you can handle the failure, but the mission has to be aborted. There's no way around it (and I don't enjoy being forced to abort a mission because of something I had little control over - if it's my fault, it's my own fault, but these failures aren't really my fault, just my bad luck). Once you start getting out of the Kerbin system, though, (towards Duna/Eve etc) you can deal with the failures of decouplers inside the atmosphere. Sure, you lose that second stage, but you have another that could possibly take you into orbit anyway. You can afford to pay for backup systems. Thing is, out of the gate you can't afford to pay for those backup systems. One solution could be to remove the failure rate entirely from the first decoupler you unlock (and only that decoupler), although that is less than ideal (and probably would warrant increasing the cost of that decoupler significantly). Alternatively, it could be hard-coded that if that decoupler is purchased at 100% quality, its failure rate is insignificant (as in, 0.1% chance or less) or even 0% (although this could be simulated by adding a new, failure-proof decoupler that is more expensive). This, however, is a lot of work. Also a lot of work would be to "unlock" failure rates on decouplers at some point in the tech tree (I don't even know if this is possible). Anyways, I'm seriously considering just taking the failure rate off of the original decoupler for my games.

A bit of both. I looked at the other formula and thought "Oh, that's applied to everything, it's not really relevant to what I want to know." And didn't think about the fact that if everything gets square-rooted, that means the actual BPs of the parts is changed as well. Fair enough. Until now, there's been no need to think that it would need to be different. Hmm. In that case, I'll have to check it out again. I remember loading up a previous save and seeing the build rates in the VAB and SPH as blank (couldn't see them, couldn't put any points into them, as though they were all disabled or no longer there). The R&D tab still looked normal, though, so I figured that it was due to the build rate formula changing. I'll see if I can get it to happen again and give you a screenshot of what I mean. Edit: After some trying, I can't get it to do it again. Either my memory is terrible... or, I dunno, something. Ah, wonderful! I just assume that any changes I make will be lost upon update until proven otherwise, and so I write down whatever I do. But this is much better.

Well, this is what I get for posting a "solution" without testing it myself. Sorry. However, I've looked and it seems that the first formula I gave you caused KCT to go through a loop, creating build lines forever, until you eventually shut the game down forcefully (might want to mention that in your documentation, magico13. Would help people like me who want to modify the formulas ) This will solve that: BuildRateFormula = (0.05*[N] + max(0.1-, 0))*sign(20*([L]+1)-) This won't give you an unlimited number of build lines (as I hoped to give you before), but it will give you 20 build lines per upgrade level of the VAB/SPH. I have tested this on my own game, and it works, although you'll need to start a new game (loading an old save will not load the build rates properly).

Now that I'm seeing the formulas used for these things, I'm wondering if the Effective Part Formula should be re-tooled. By the looks of it, after the 3rd or 4th build of a small part, and after the 9th or 10th build of a big part, each time you build a part it reduces the build time negligibly. For instasnce, the second time you use any part it only takes 1/2 as long to build. This doesn't quite sound right to me: sure, some practise is better than no practise, but why 1/2 after the 1st build, and 1/4 after the 2nd? I feel as though a better formula would use a quadratic effect on the number of parts built so far, like this: [C]/( + (*((+1)^(2/3)))) Assuming there's no inventory, that would mean that each time you build the part, its BPs are (roughly): 100%, 63%, 48%, 40%, 34%, 30%, 27%, 25%, 23%, 21.5%, 20%, 19%, etc. This would mean that using the same piece more than a few times would still be reducing its BPs noticeably. This would also help alleviate the issue with build times taking less time than reconditioning (albeit only somewhat - after 30 builds with the same part, my formula would take ~10.13% as long as originally, whereas the default formula is ~3.23%) - - - Updated - - - OK, in that case, step 1: download this new .cfg: https://www.dropbox.com/s/iui9olsjk3gb9n9/KCT_Formulas.cfg?dl=0 Step 2: Drop into the "Kerbal Construction Time" folder inside the "GameData" folder where you installed KCT to begin with. It should overwrite the original. If you update, you'll either need to replace the new .cfg, or go to the "Kerbal Construction Time" folder, and inside the "KCT_Formulas.cfg" (open it with Notepad, or Notepad++), find this line: BuildRateFormula = ((+1)*0.05*[N] + max(0.1-, 0))*sign(2*[L]-+1) And replace it with this line: BuildRateFormula = 0.05*[N] + max(0.1-, 0) ==Don't use this formula, it will cause KCT to crash. Use the formula given below== (It's currently the last one in the document, but that could change, as magico has said that he will be adding more formulas to this .cfg) This will change all your build lines to give you 0.05 BP/s per upgrade, and allow you to upgrade them all right away, rather than the default way of doing it.

The way the build lines work in the base mod is that each new build line will be 0.05 BP/s faster for each upgrade, which is why you can't upgrade the next build line. For instance: Line 1: 0.05 BP/s per upgrade Line 2: 0.10 BP/s per upgrade Line 3: 0.15 BP/s per upgrade Line 4: 0.20 BP/s per upgrade However, you can't have Line 3 faster than Line 2, which can't be faster than Line 1. This means that each Line must be upgraded at least once in order to be able to upgrade the next, since until Line 2 is at 0.20 BP/s, Line 3 would be faster than it with even a single upgrade. As for how to get multiple build lines at 0.15 BP/s, that would probably take some code-editing, to make each upgrade cost the same for each line. But I don't look at the code, and wouldn't know where to look anyway, so I'm not sure about that. It'll have to be Magico to explain that. --Update-- Actually, you CAN change how much each upgrade point adds. In the Kerbal Construction Time folder, there's a file called KCT_Formulas.cfg. If you change the BuildRateFormula to: (+1)*0.05*[N] That should make each upgrade point add 0.05 to the build rate for each line. Can someone confirm this for me, though, that formula does look a little complicated, and I'm not sure of the complete ramifications of changing it. If I'm correct in my guesses, [N] is equal to the current number of upgrade points in the build rate, is equal to the build line number (0 for the first line, 1 for the second, 2 for the third, and so on), and [L] is equal to the level of the VAB/SPH (to limit the number of build rates based on the level of the VAB/SPH) And I just realized that magico posted a link to the descriptions of all these formulas, in his post just above yours. The part about this formula says: BuildRateFormula = "((+1)*0.05*[N] + max(0.1-, 0))*sign(2*[L]-+1)"; Purpose: Defines build rates and how they change with upgrades Variables: N=num upgrades, I=rate index (0 based), L=VAB/SPH upgrade level, R=R&D level Note: This uses some tricks to achieve various goals. First, the max() section sets the first build rate to start at 0.1 and all the others to start at 0. Second, the *sign() section limits the number of rates you can have based on the VAB upgrade level (2 rates at level 0, 4 rates at 1, 6 at 2). It works because a negative rate is considered "disabled"

Ah, OK. I don't know how these things do their magic, but that makes sense. OK, that would make sense. I'm pretty sure the only thing I did before trying to launch (since loading the game) was adjusting the flight of a probe in space. Forgive my ignorance, but what is wrong with launching a craft without going into an editor first? (Aside from the fact that without KCT, that can't actually happen)

So I ran into an issue, but I've no idea what happened. I'm trying to launch a plane from a different runway using Kerbinside, but after the launch loads, I get a message saying that there was an error trying to read KCT data, and the game is unplayable. This hasn't happened before (I've successfully launched from the same runway before, both simulations and real launches at that runway). I think it has something to do with Kerbinside and KCT interacting, since it worked after going into the SPH and changing the launchsite to Green Coast (where the plane was intended to launch from) and simulating a launch there. Here's the logfile from the failed launch: https://www.dropbox.com/s/mtbl2qkoyn2ghiv/Player.log?dl=0 Note: I did not go back and recreate the error with a clean install of KCT.... because I don't know what the error was in the first place, so don't know how to recreate it.

KSP Interstellar Extended Make sure you "Refresh" the repository before you go looking, I always forget.

I do, and I am about to appreciate the hell out of this mod. Take your time. I will most certainly appreciate this addition, but until then I can wait. In my opinion, the "grenade" effect isn't terrible, just not ideal.

I'm currently playing with them both installed, but I'd advise against trying to use any of the FMRS features during a simulation (aside from the Revert, as that hasn't acted up for me). It does work, but it's a bit finnicky and sometimes it doesn't work (once, after going back and forth in the simulation to make sure my stuff would be recovered, when I finally ended the simulation it seemed to have forgotten it was just a simulation....). Otherwise, though, they are playing well together very nicely. As a note, I've noticed that when I reverted to launch with a tourist onboard using the FMRS Revert button, the Tourist (and my Pilot!) disappeared. This hasn't happened any other time, including with just regular crew members. It's not too terribly upsetting, though, as I can just use the stock Revert at that point, and the crew members pop back into their seats, as they should. Also, is there any way to disable the stock toolbar icon? My stock toolbar is getting a bit full, and I'd like to clear out anything that doesn't need to be there (since I have blizzy's toolbar, the stock icon is a bit redundant...)

Agreed. I don't use MechJeb, and while the vanilla node editor is easy to figure out (being graphical), PN just gives far more control, and is far easier to use once you have figured it out. When I was installing 1.0, I was coming back from a hiatus, and PN hadn't been updated yet. I forgot about it, until I saw it on CKAN, and thought to myself, "Oh yeah, this is why I'm so frustrated with the Maneuver Node system. Because I can do better."

I was just thinking, would it be possible to implement a setting where the vessel attempts to keep a certain amount of horizontal speed? After all, you can pitch up all you like, as long as you keep your airspeed high enough. It seems complicated to me, but then this whole mod is over my head. My advice is to install Waypoint Manager, from CKAN or here: http://forum.kerbalspaceprogram.com/threads/104758-1-0-2-Waypoint-Manager-v2-3-2-2015-05-02 It will automatically populate your contract waypoints, and there's a setting to see the exact heading to the waypoint as well. I can hit any waypoint from anywhere on Kerbin, within a narrow margin, with this mod.

Also, only engineers can attach parts to surfaces. Other Kerbals can move stuff around, but it will only drop to the ground, and not attach, even if you hold X (Jeb cares about how to control explosions to propel himself, not how to put a rover together ). This sounds like you were trying to attach something with a non-engineer.

Oh, OK. So I was right, it was my misunderstanding. I thought AoA was the pitch angle between the nose and the ground. Thank you very much.

So whenever I enable Vertical Control for altitude, and there is a big enough discrepancy between my current altitude and my wanted altitude, PA tries to send my plane straight up. For instance, if I am at 1km and tell it to put me at 2.5km altitude, this happens: (yes, I'm running quite a few mods. This was just a quick pic, because I don't understand a lot of the PIDs, so I probably missed a setting on one of those that I need to change.) Max AoA is supposed to be 15 degrees, but it completely ignores that. Or am I misreading something? Is there another setting I need to adjust? What all controls the Angle of Attack?

OK, understandable. Thanks.

The setting of 30km for predeployment causes my chutes on spent stages to burn up if I'm too high in the atmosphere/too fast. I use both FMRS and Deadly Re-entry, and by reducing the minimum altitude (in the .cfg), I'm now able to save my spent stages before I unlock action groups, and don't need to change this setting by hand every time after unlocking them. However, it would be handy to be able to do it in-game rather than through editing the .cfgs (for before I get the action groups unlocked in Career). So, is it intentional that we can't modify the settings until the action groups are unlocked, or did it just happen that since that was the method of editing before the KSC upgrade system was in place, you just went with it? If it's not a design decision, is there a way that we could edit the defaults for chutes in-game, or would that be too complicated?

Computer voodoo indeed! After trying to start up KSP again, now it started crashing on me again! Then, after I re-exported them with GIMP, it started working again!

Just to clarify, you did recover these experiments after conducting them, right? The contract does say, "Science experiments with little to no transmission value may need to be returned to Kerbin to complete each parameter." Also, this particular contract would have come from the DMagic Orbital Science addon, the one that adds extra scientific experiments. If you did recover the experiments and it didn't complete the contract, you will need to let DMagic know about it, as he would be able to help you out.

So something really, really strange is going on with my install. When I start KSP, it crashes during the load (not because it's hit the memory limit, I'm running Linux x64). Specifically, it crashes when trying to load two specific files in the WarpPlugin/UITextures folder: MicrowaveTransmitter.png and MicrowaveTransmitter_selected.png I've confirmed this by removing each of them, and upon removing these two files (and NOTHING ELSE), KSP starts just fine. If either is present, KSP crashes when it tries to load them (even after renaming them, although that may not be surprising either). This is a heavily modded install, and I haven't gone through the trouble of testing without any other mods yet, but still.... .png? What could conflict? There's no other files with that name in any of the GameData folders... My mind is thoroughly boggled. I have absolutely no idea what could be causing this, or what could help determine that. I could just live without these icons, but regardless, I think you should know what's happening, in case there's some sort of underlying issue. Edit: I guess this is what I get for late night bugfixing.... found the solution, needed to update my libpng. Dunno if this'll help anyone else, but I needed to run "apt-get install libpng-dev" and it fixed it. In case there's anyone else here who just moved over to Linux for the 64-bit version, you'll probably need to do this too.

Okay. I finally worked it out. Not sure if this is an issue with FMRS, or SAVE, but FMRS and SAVE were not playing well together for me. I guess the backup feature of SAVE was preventing FMRS from integrating the previous stages, thus causing it to forget what happened to them. After I removed SAVE and reinstalled FMRS, FMRS started working fine again. I say I'm not sure whose fault it is, because the developer of SAVE says himself that he's not sure if it works on Linux. (http://forum.kerbalspaceprogram.com/threads/105399-1-0-2-S-A-V-E-automatic-backup-system-1-0-1-672) Is this a known issue between FMRS and SAVE, or just for me? And for Spanier and DigitalProeliator, if you use SAVE, I'd try removing it and reinstalling FMRS, then see if FMRS starts working again.

I am also having this issue. I'm not really sure how to pick out what is important or not in the debug log, but I could supply a complete debug log for the flight. Soooo.... new details: I've discovered that removing and reinstalling FMRS resolves the issue.... kinda. It works the next time I run KSP, but if I exit KSP and start it up again, FMRS ceases to work again. I use the 64-bit Linux version (Ubuntu 14.04), if that makes any difference.