• Content Count

  • Joined

  • Last visited

Community Reputation

99 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. 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.
  2. 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.
  3. 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?
  4. @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.
  5. 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.
  6. @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...
  7. 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.
  8. 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?
  9. 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.
  10. 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.
  11. 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.
  12. 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:
  13. @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?