magico13

That would indicate that the game no longer will let you revert to the editor or to launch, which probably would happen with just FMRS+Stock. You can check that by pressing the escape button and seeing if it will let you revert through that menu. If so, that's not a KCT problem. Assuming the jump isn't totally breaking the simulations (wholly possible that it is, btw. There are reasons quicksaving/quickloading is disabled.) you should still be able to exit the simulation by returning to the space center.

@FirroSeranel The editor estimates define stages as being split by decouplers, and decouplers only. "Stages" only matter for the editor calculation, which is just for player reference and isn't actually used for anything. When you actually launch and drop stages StageRecovery will work fine with it, as it takes the entire set of connected parts as a single entity. Since it's just the editor estimates having issues, I'm not too worried about it. I'd need to totally rewrite the stage splitting code for it to handle that corner case and you can just design the subassemblies to be recoverable in which case the editor estimates aren't needed for them.

I haven't tried it but I don't expect to see any.

The basics of the inventory are that parts are added to it when you recover them (using the stock recovery mechanics) and using parts from the inventory results in a reduced build time. Parts are automatically added to the inventory when you recover vessels, and are automatically removed from the inventory when you build new vessels (unless you uncheck the "Use parts from the inventory" button). If you want to have the absolute minimal build time, you want to construct things using parts exclusively from the inventory. The scrap button is similar to recovering the vessel. You get a 100% refund and all the parts are added to the inventory. If you scrap an in-progress vessel you get a 100% refund and only some of the parts are added to the inventory (based on how far along the vessel was). Where you add them depends on what you want them to do. If you wanted a build rate entirely governed by the levels of Engineers at KSC you might try: BuildRateFormula = "0.1*([EnL]+1)*sign(2*[L]-[I]+1)" which would give you 2 build rates per VAB upgrade with each one at 0.1 BP/s per Engineer Level + 0.1BP/s base. (5 total combined levels at KSC would result in 0.6 BP/s). The "sign()" part is only setting the total number of build rates per VAB level ([ I] is the index of the rate, starting at 0, and [L] is the VAB/SPH level. When the value of the inside of sign() goes negative, sign is -1 and the rate is disabled. When it's 0 or positive sign() is +1) Or here's one that adds a build rate of 0.75 for every engineer at KSC (+1 rate in case there are none). BuildRateFormula = "0.75*sign([EnK]-[I])" Oh, I somehow missed that you explained what you wanted. Let me see if I can come up with something that might be close. BuildRateFormula = "(([I]+1)*0.05*[N] + max(0.1-[I], 0))*sign(2*[L]-[I]+1) * (1+([EnL]*0.2))" Now, this would add 20% for each level of engineer at KSC, so if you had 2 engineer kerbals with a combined level of 7 (perhaps a lvl 4 and a lvl 3) then it would be 140% faster. You could divide by the number of kerbals at KSC to try to mitigate that but hiring a new engineer would lower the average. You could also wrap it in a "max()" to set a maximum limit. Here's an alternative that adds only 10% each level, up to a maximum of 100% bonus (or twice as fast) at 10 total levels BuildRateFormula = "(([I]+1)*0.05*[N] + max(0.1-[I], 0))*sign(2*[L]-[I]+1) * max(1+([EnL]*0.1), 2)"

I have a modlet called Tree Toppler that lets you unlock the tech tree for free (either the whole thing or just certain parts). I've used it in the past to completely remove the need for science, but still be constrained by funds. I turned on the "part purchases" setting and took contracts to get funds, then did whatever other missions felt fun. When I start my next playthrough I'm going to ignore contracts entirely (except as inspiration) and will be using BROKE to give me a strict budget each quarter (once I finish writing the Funding Modifier [aka, mod] for it).

None of the formulas use crew information like that by default, but many of them support it if you want to add it in yourself. Read through this wiki page and specifically look for the "Crew Variables". I don't think I'll be adding anything like that in the near future. If I get around to rewriting the inventory code then I'll make it possible to easily add in this sort of functionality. RP-0 restricts the player to 1 build rate per VAB level. A possible workaround would be to use a different KSC for testing than the one you use for launching, since the build queues of different KSCs are separate. Tech node unlock times are only controlled by the "Development" rate in the Upgrades window. Build times can be reduced by upgrading the build rate, using parts that have been recovered, using parts that have been used frequently in previous builds, and potentially by upgrading the VAB/SPH (depends on the Preset, I don't think the RP-0 one uses this). You can purchase additional upgrade points in the Upgrades window (I think RP-0 has them at a fixed cost of 10,000 funds)

You get an upgrade point with every tech node you unlock.

Hmm, could be. It'll be a quick fix. I might be able to get it out in a few hours, otherwise it'll be tonight. E: You can create the file yourself and it should work fine I think. Unfortunately I can't take a look at it until I get home later tonight. E2: Fixed in Editor Time v1.0.2.1. @awang @eightiesboi

Furthest distance by land, assuming a sphere (if you want to look it up, the distance used is called the Great Circle Distance). In this case it's just half the circumference of the sphere with 600km radius.

Development version that fixes this posted on GitHub. I've seen that in the past when a GUI window is behind the simulation configuration GUI. It's likely an Input Lock being stuck on. You can check by opening the debug menu and clicking "show input locks". You should see a few from KCT regarding quicksaving. If you see others, take a picture and upload it somewhere and I might be able to figure out which mod is causing it. You can clear the input locks to resume playing, but don't quicksave while simulating.

With the tens of thousands of exceptions being logged I'm having a hard time finding anything useful. A few things: can you turn on KCT's debug messages in the KCT settings menu, and KerbPaint and ProbeControlRoom are throwing a huge amount of errors. When using KCT's recovery you actually have to pay to recover the vessel based on the distance (really you get the recovered amount, then KCT takes the full value back). It uses the stock formula for calculating recovery percentages: 100% landed on the launchpad or runway, 98% at KSC, 10% exactly opposite of KSC, and linear between 98% and 10% based on distance (here's a plot for Kerbin, x-axis is km).

I didn't end up leaving work until 9 last night and I'm travelling to go to a friend's wedding today. I might get a chance to do it tonight but I might also be busy all evening (my fiancee is in the wedding party so we might have things we have to do to help get ready). It shouldn't require more than a recompile so its just a matter of getting time to sit down with my laptop. Edit: EditorTime is now updated to KSP 1.1.2 with no other changes made to it. It's only on GitHub for now, I'll add it to SpaceDock (and thus CKAN) sometime in the next few days. @awang, @eightiesboi

No, I just never got around to it. It probably only requires a recompile so I'll see about getting it updated tonight.

I'll try to get you guys a build tonight that fixes it. I've been distracted by Stellaris I'll be keeping the KCT simulations in for as long as they aren't a pain to maintain. If an update causes them to stop working and requires a bunch of work to fix it, then I'll probably not spend the time on it. As long as they work I may as well leave them in as an option. I'll take a look at this when I get a chance. Only new parts are supposed to be pulled from the inventory. The whole edit mechanic is a bit buggy and I want to spend some time on it in the near future. If you're using RP-0 it's probably a restriction caused by the RP-0 Preset. Looking at the Preset it seems like RP-0 restricts it to one rate per VAB level. Edit: Also, it's a known bug that in new games the second rate appears when it shouldn't. If you put a point into it, it gets lost until you upgrade the VAB.

I haven't actually tried it with RO myself, but I'd recommend turning the DR Max Velocity or whatever it's called in the settings up to 4000 or more, to whatever you feel is appropriate. In Stock it's balanced so that there's a chance of burning up when you drop the stage from a suborbital trajectory, but those speeds are much lower than you'd see in RO. Keep in mind that atmospheric drag isn't applied to an unloaded vessel but gravity is, so it'll be moving faster than expected. For comparison, the first stage of the Falcon 9 separates at about 1650m/s and still requires a reentry burn to not burn up. As for the distances, right now all you can change is setting the distance modifier to a constant value. The function it uses is based on the Stock one so that the numbers are in line with if you actually landed the vessel. I've been meaning to add support for KSCSwitcher for a while, although I'm honestly a bit surprised it doesn't already work since KSCSwitcher moves the KSC and SR just uses the position of the KSC as told by KSP.

Field Experience doesn't do anything involving science or contracts. You might be thinking of a different mod. I think @nightingale has a mod that you might be confusing Field Experience with.

If you're sure you're using the correct version, then I'll need the log files (read this post). That definitely doesn't sound like the correct behavior.

Actually, after cutting out the "ignore list" it's up to 102 as of right now. When the next update happens I wouldn't be too surprised to see 105 or so.

Well, figuring BROKE isn't really at a properly functioning state yet that's understandably not a priority

With how docking works in general I'm not surprised about that. I also know that the current code would cause issues with parts that are missing a symmetry partner (I have a fix for that in KCT that I'll transfer into here at some point in the future). KSP isn't really designed to go "backward" from Vessel to .craft, so I definitely can't guarantee that method to work all the time.

May I also suggest FMRS?

As of now, no. There are plans to break out the recovery mechanics to other mods so they can add their own weird parachute-like modules but that effort hit a wall when I couldn't get sensible values out of the parachute drag cubes, which would allow me to unify much of the code base instead of having separate methods for stock, realchute, and any future modules. Make sure you're using the release version and not the older pre-releases. The error has to do with Kerbal Konstructs failing to recover the vessel for some reason. Because the vessel doesn't get destroyed KSP attempts to destroy it again, over and over again, meaning the events that SR listens to are being repeatedly called. I've got a planned workaround, but it just treats the symptoms and not the underlying problem. If you still have the issue after you redownload and reinstall StageRecovery and Kerbal Konstructs then I'd suggest also cross posting on the Kerbal Konstructs thread. If the parachutes were deploying and being destroyed then that certainly would make it appear as if SR wasn't working. Hopefully that's all it was! In the settings you can reduce the required TWR. I've got longer term plans to add support for "gliding recoveries" where much smaller TWRs would be needed (if any) but that depends on me figuring out how to calculate drag on the entire vessel at an arbitrary AOA and speed, with the vessel unloaded.

If you're just checking that a strategy is active then that's probably pretty easy. I've never actually done it though so I'm not sure off the top of my head how easy it would be. I imagine it's just one function call to the right place. Then, based on the status of that check you can have the FM do whatever you want.

Alright, Ship Save Splicer updated to actually work with 1.1.2 and experimental Exported Vessel to .craft file functionality added. Left-Shift the button to convert an already exported vessel to a .craft file. I expect it will be a bit buggy, so watch out. That functionality is made entirely possible by @Claw and his work on InflightShipSave. Most of the code is directly copied because I was feeling somewhat lazy and didn't want to spend more than a few hours on this.

Ok thanks, that should make testing pretty easy. On a scale from 1 to 10, how annoying is it? I can put out a dev build for you later with that disabled if it's really annoying.