SpacedInvader

Members
  • Content Count

    1,047
  • Joined

  • Last visited

Community Reputation

100 Excellent

About SpacedInvader

  • Rank
    Junior Rocket Scientist

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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
  3. That's really great to hear! I'll happily wait for the release then. Thanks!
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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?
  10. @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.
  11. 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.
  12. @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...