SpacedInvader

Hmm, ok, I can see how that might be an issue, though I'm by no means experienced with Unity. My limited programming experience would tell me that calling something before its been initialized would lead to problems, though. I'll keep an eye out for the new version of Deadly Reentry since that's also on my "must have" list. I can imagine LGG would have had a lot of work on his hands... he's taken on such a critical role in maintaining so many really great mods, I don't know what this community would have done without him. As for my sources, it was just a couple of people who responded on Reddit when I'd asked about which version of KSP I should take, so I can't really be sure what they actually experienced, but my guess is that this is the culprit as it sounds like a respectable collection of commonly used mods suffered from it. Whatever the case, thanks for the detailed info and I'll look forward to the updated RF when you release it.

BTW, @Starwaster, I know this really has nothing to do with RF, but you've been around a long time and I trust your opinion, so I'm going to ask it anyway. A couple of sources have mentioned that 1.8.x is one of the most unstable builds they'd seen and recommended using 1.7.3 even if all my desired mods supported 1.8.x since my goal is to run a very long career mode playthrough (the goal is to have an MKS colony or research base on every planet not only in the stock system, but also OPM and Extrasolar... so something like 30+ colonies or bases). Their experiences were that you're rarely able to play for more than an hour before the game CTDs without warning, causing lots of lost progress, and as such, the recommendation is to use 1.7.3 because its far more stable, even if it doesn't have the performance improvements that came with 1.8.x. Anyway, I'd really like to know what your thoughts would be about this topic. Thanks

That's really great to hear! I'll happily wait for the release then. Thanks!

I'm returning to KSP once again and in the process of trying to decide if I want to run 1.8.1 or 1.7.3 based on the available mod compatibility. I'm curious what RF's current status in regards to 1.8.1 compatibility is as the last mention of this KSP version was several months ago. I consider this one of my must-have mods so its likely that if its not compatible and will remain that way for some time, I'll opt for the older KSP version.

deleted

The instant jump to high timewarp is the result of "warp to" commands like what you get from "warp to next morning", but also mods like KAC and KCT will instantly set max timewarp when you use certain functions. That all said, I first noticed the issue around the 1.0 release and persisted through the last time I tried playing around a year ago. I can't rule out mods causing it to be reintroduced, or at least exacerbating it, but if they did work to fix the issue, I'd definitely not seen it as of a year ago.

This specific problem has stopped me from playing for years. I don't have the issue while playing within the Kerbin SOI, but 100% of my attempts over the last few years to launch interplanetary missions have failed because the mid-course corrections have needed hundreds or even thousands of m/s of dV that I could never seem to get ahead of. I even tried building an extra 1.5km/s of dV into one design only to have it need nearly 2km/s at a midway course correction. If this gradual timewarp change actually does fix the issue, I might just come back to play again.

I'm definitely seeing serious improvement. I'm still getting the 1-second interval stutters, but they are markedly shorter (~.1s compared to ~.5s) and thats with my dumpster fire of an install.

I've actually experienced something similar to this a few days ago. I have a Mk-1 pod on top of a rocket and the FASA launch tower as part of the ground equipment. When I went to launch the vehicle, Val was correctly placed in the MK-1 pod which appeared after the launch tower's 16 crew slots. When I loaded into the flight scene, Val was nowhere to be found and I couldn't control the rocket. After several more attempts with the same results just to be sure I wasn't accidentally loading her into the tower, I tried putting her in the first slot, which belonged to the tower and presto, she was magically in the pod when I loaded into the scene. I kinda figured it was a bug with the launch tower since that mod is quite old not officially supported beyond 1.4.2, so I didn't bother to report it here. It's only after reading about your issue that I think something similar might have been happening. I'll try to get some logs relating to this tomorrow as I won't have time tonight.

Now you can start building saved craft from any screen.

You know, I really kinda wish they would stop putting new updates out every 2 months. It's probably way early to be asking about this, but 1.7? Seems like they didn't change all that much so I wonder if a new KCT build is even necessary?

@Starwaster I think I may know where part of my problem has been coming from in trying to do anything with the ISP values. Years ago, NathanKell instructed me to change the key values in the RealSettings.cfg file in this manner: But when I tried to go back and make the changes a couple of years ago and then again now, the patch I tried to use went after the "IspSL" values in the engine configs instead of the key values from RealSettings. For some reason, this wasn't just reducing the sea level Isp of the engine, but also its sea level thrust. For example, using a multiplier of .35 caused the Mainsail to have a seal level thrust around 450KN which isn't even enough to launch a small 4K dV rocket because its too heavy. Here's the code I used: @PART[*]:HAS[@MODULE[ModuleEngineConfigs]]:FINAL { @MODULE[ModuleEngineConfigs] { @CONFIG,* { @IspSL *= 0.35 } } } And the result: So now I've got several more questions. First, is this the proper behavior that I should be seeing when modifying the "IspSL" value in this way, or should that, as I was guessing when I wrote the patch, only adjust the actual Isp value and not the thrust? Second, I'm guessing the answer here is no, but is this even an appropriate way to approach this issue? The reason I went after this value is that it seems like it should be the most logical way to do this, but now that I'm looking back all those years to see the original way that NathanKell suggested, it also seems to be a much easier way to do it since you can access these values with an MM patch and I don't think you can do the same with the RealSettings.cfg keys. That said, is there a way to do just that? The patch being what it is, it would be much easier and more beneficial to be able to change one value and have it affect all of the relevant target values than to have to go through and manually recalculate each value.

Hmm, so it really sounds like "useRealisticMass = false" is the least problematic, if less realistic, solution to this... As for going up to RSS, I've spent a lot of time there already (Not sure if they still use them, but I created the heightmaps for the Moon, Mars, Venus, and Mercury from real elevation data years ago... Some of the screenshots on the release page even show the test lander I used to sharing pictures of the terrain), and while I'm not opposed to playing on that scale again, going to all the stock system planets is actually something I never got around to doing and so that's where I'm going to stay for the time being. I've even gone so far as to add OPM and Other Worlds, so I've got like 20+ bodies to visit across two star systems in my current career.

@Starwaster I wonder if I could get your input on something. A couple of years ago I tried messing around with an MM patch to automatically scale all my engine ISP values by 1/3 to get more realistic looking rockets in a Kerbin scale system. The problem is that it caused my Vac stages to grow way out of proportion. I even did a comparison and found that it caused my Mun lander to need around twice the fuel mass to accomplish an Apollo style mission as the real Apollo style missions needed. Here's the original post: Anyway, fast forward to now, and I'm not loving the fact that my Mun lander probe rocket looks like this: I mean, the payload is nearly a third of the vehicle's length and that's including an upper stage that's intended to stay in orbit of the Mun for communications relay purposes. I should probably also point out that this is with the setting useRealisticMass = false. The reason I'm bringing this all back up again is that I noticed that I never got any sort of definitive resolution for the question back then and I'm wanting to get back at it now to see if I can't find some happy medium where I get realistically large launch vehicles without running into unrealistically large landers. So, there are two questions I'm hoping to try to get answered. First, if I go the MM patch route, should the 1/3 ISP multiplier be applied to both keys or just the atmospheric key, and second, since I don't think I've ever seen an answer to this, would that 1/3 ISP multiplier result in Kerbin-scale realistically sized rockets or Earth-scale realistically sized rockets? Not sure if that last question makes sense, but I've been wondering for a while if stock rockets aren't already properly scaled for Kerbin's size and whether or not trying to artificially increase their size through reducing engine ISP even makes sense...

Wonderful, thank you!

Is there a rule of thumb calculation for converting the volume of liquid fuel / oxidizer tanks into real fuels modular tanks? I've got some tanks built into the probes plus mod parts that need to be converted, but I'm having a lot of trouble figuring out just how much volume I should attribute to their tanks.

Now that I think about it, it does seem more like a question for this thread since it isn't a bug and now that I know what the source of the extra O2 is, I could easily patch it to output something non-usable like "GaseousO2" or something like that. So the question is, would that O2 byproduct from the propulsion system really be usable in the life support system?

The last edit was more for information for anyone who lands on the post with the same questions. Essentially, the system is working as intended and I didn't know that the system existed prior to my investigations. I'm not 100% sure about the realism of propulsion system LO2 being use in the life support system (which is indeed a question for that thread), but ultimately, this isn't a bug, but a feature.

I've been doing some searching and not found an answer, so here's the question. Does TAC-LS automatically convert the Real Fuels resource LqdOxygen into O2? I noticed that my first manned orbiter in this save (the first for me in at least a year) never lost O2 until after I decoupled the service module which contained Kerosene and LqdOxygen. In the past I remember that LO2 and O2 were considered completely different resources and the only way to get your Kerbals to breath the LO2 was to create a converter, but for the life of me I can't find any sort of patched in converter.. I've been searching for anything in a module manager config throughout my entire install that would create a converter for this and have come up empty so far, though that doesn't mean I'm not just looking in the wrong place / using the wrong search terms. Mainly the reason I'm trying to figure this out is because I don't want my Kerbals to be consuming my dV when they have perfectly good O2 already stored in the form of life support resources. Anyway, any help / direction on how to sort this out would be greatly appreciated. EDIT: Further testing has shown that there is definitely some sort of conversion going on, as the capsule O2 will be continually filled as long as there is LO2 on the craft at all. Disabling crossfeed and shutting off the tanks containing LO2 had no effect. Essentially, the only way to stop the LO2 from being converted into O2 is to remove the LO2 from the vehicle. EDIT 2: I believe I've figured this out on my own after much searching and testing. It appears that there actually wasn't a real converter patched in anywhere at all, but instead this is a function of Real Fuels when using the Service Module tank type. Real Fuels models fuel boil off so when liquids like hydrogen or oxygen are kept for a long time in non-cryogenic tanks, they eventually evaporate. In the normal tanks, this happens passively and it is simply lost, but with the service module tank type specifically, O2 is specified as the byproduct and is recaptured if there is space available in the life support tanks. This is why my O2 levels weren't going down as I'd used the service module tank type for my craft. Additionally, in case anyone runs into the same question, the kerbals aren't sucking up the craft's dV for their own use, but rather simply making use of what would otherwise be lost in this circumstance.

Wait, you can disable the people? As for a log, doing a fresh start now for the logs and yes, I've got one recently completed craft that needs a rollout and thats when I noticed the issue.

I'm still getting the stutters, but its performing much better now. That said, when I try to click the VAB button in the space center window, it folds up on itself like so:

@linuxgurugamer So I'm not sure if this is helpful at all or just another headache for the pile, but I have some new behavior to report now that I'm actually trying to play the game a little instead of the starting and spinning. With KCT enabled, click events seem to be hit or miss while in the editor. What I mean by this is if I attempt to click on a part to remove it once its already attached to a craft, the editor will freeze momentarily, and then there is maybe a 20% chance that the click actually registered properly and the part was separated from the craft. Disabling KCT still sees the editor freeze momentarily (this I'm guessing is a direct result of my bloated mod list), but there is a 100% success rate for actually selecting the part and being able to manipulate it. I'm currently trying to find a video recording program that shows clicks so I can highlight whats happening better. EDIT: @vardicd does this seem like something you're experiencing at all and if so, can you confirm whether or not disabling KCT in your install fixes it?

Oh, I understand fully and I very much appreciate any progress your able to make. I've been slowly trying to test for additional issue mods, but my load time isn't really much better than yours and I'm also still trying to actually get a little play time in as well.

Wait, so you got different results on two different runs of the same parameters?

Follow the links in my answer post. You'll find some file names, just do a search for those to see which mod is the source. If they don't show up, its not the same issue.