Faster

Great mod! I really enjoy the choices I have to make based on igniters and missions to resupply igniters. After years of playing with it, I'm finding the ullage simulation doesn't really change anything for me, that is, I don't make any choices or face any challenges based on it--other than whether I remembered to quickly wiggle a vehicle's rear end before igniting in micro g and having to over-complicate stages for vehicles automated with things like Smart Parts. I see some older comments about disabling the ullage simulation by doing a global replace in /GameData of UseUllageSimulation=true to false (since the settings UI isn't wired up as of 1.3.6.2). Is that currently the best way to disable ullage or is there a better way now?

I've really enjoyed the choices this mod brings to strategising in career. It seems to work just fine in 10.1.1 with CKAN's versions of Scrap Yard, Stage Recovery, and KCT. Thanks! Some thoughts for whatever they're worth: I enjoy a rare, truly surprising failure that I have to figure out how to recover from and I enjoy choices like needing a ship launched now, damn the torpedoes, vs having the luxury of waiting for a more reliable cryo tank. After a few times of novelty, doing many tests of each part, clicking through Scrap Yard's click-intensive UI to ensure I'm upping the gen rather than just reusing a gen 1 over and over, I feel like I'm doing some serious busy/make work. Then later I find myself doing serious extra clicking (and forgetting to do so) with Scrap Yard to make sure I'm not reusing very old parts. So, I'd love to get rid of the beginning and ending of the curve and have parts be reliable, with failures still happening at a rare, "oh scrap! that was a surprise" rate. If there's a simple way I can do that now by editing files or whatever, I'd love to know. There are issues in GitHub already talking about this likely with better thinking behind them, so I'll just briefly note my ideas: I'd be happy to get rid of the beginning of the curve by deciding in settings which generation parts start at or even which generation they start at plus a first manufacture penalty per part. For example, I might select that parts start at generation 5 and the first time I order each part, that first part takes 500% longer to manufacture or 500% more to make. Just changing the start gen without a time or price (likely complex to code) would be a great, 99% solution*. And, ideally, getting rid of the end of the curve would happen in the integration with Scrap Yard with a feature that let's me select the reuse count at which parts are automatically discarded. Semi-related/unrelated: what think would be fun along the lines of "part testing" is seeing part gen jumping way ahead on failure ("lessons learned") and (out of scope and probably nigh impossible to mod) part performance increasing via usage counts, for example seeing ISP going up a tiny bit per launch with diminishing returns. * I've been playing KSP since .23 as often modded as stock and never have I seen anything remotely like a balanced, rational career economy, which makes the complexity (of coding) of cost penalties highly optional from my point of view and time penalties far more interesting, since the latter actually impacts Kerbal survival, contract success, etc. tldr; feeling of busy work eventually overruns added fun and so maybe add setting for initial gen X of parts, add setting for %Y time penalty for first part, add setting for auto-discard at uses count Z.

Noticed with a few different craft that when the power production is slightly higher than the drain, e.g., 2.337 drain and 2.500 production, and the stored power is increasing at 1X time warp, increasing the time warp by one or more steps will cause the stored power to begin to decrease while the drain and production readings remain the same and dropping back to 1X reverses the problem.

OK, I've not had much luck finding guaranteed reproduction steps; the problem of the game reverting to an earlier KCT launch immediately on switch to the Center seems to come and go. I uploaded the end of a log where the following occurred: 1. I launched a craft to orbit the Mun and did that. 2. After that craft exited the Mun's SOI I launched another craft to orbit Kerbin. 3. After getting the #2 craft circularized, I switched back to #1. 4. I brought #1 down in the ocean and recovered the vessel (the log begins at here at splashdown.) 5. The Center view loaded then immediately switched to the launchpad with craft #2 there un-launched and all other state and time reverted back to that of #2. https://gist.github.com/Famous-Shoes/e39f94ecf02e44e01b33 Let me know what I can check to help nail this down (or rule out KCT as the root cause.) Update 1: Note, I ran no simulations with the #2 craft. Update 2: Also, after launching craft #1, I switched to the Center and building views and other craft many times without issue. After launching craft #2, I did not switch to the Center again until clicking Recover on craft #1. Update 3: I'd been thinking KCT was the only mod I had that should have any "reverting" logic in it, but I just realized I'd installed Flight Manager for Reusable Stages based on a Manley video and then forgotten all about it. Looking at it's thread, it seems to be known to be a bit buggy and so I'll uninstall that and see if this ever recurs.

Is there a patch for this with Engine Ignitor? For example, to fix the LV-909 which shows in the VAB as supporting only Aerozine 50 + NTO or LH2 + LOX but then appears on the launch pad wanting generic hypergolic. Granted, it does burn the Aerozine 50 and maybe the current approach is the smoothest KSP itself makes feasible; just wondering if there's any patches already floating around that clean up these discrepancies so, for example, the automatic fuel selection options for fuel tanks work smoothly and the Delta-V readouts are correct? [update 1] Apparently getting the 909 to burn Aerozine 50 as hypergolic was a fluke, I can't seem to repeat that--so as it stands RF and Ignitor seem incompatible without a patch (though the chatter in this thread would seem to indicate otherwise.) [update 2] Now I can't get a 909 to not burn Aerozine 50; after all the convolutions of trying to figure the interplay of RF and EI I feel like I've been sniffing Aerozine. So, I'm back to the original hypothesis: the oddity of showing "Hypergolic" and then only Aerozine is just the best that can be done with the limitations of KSP. (Ignore the comment about incorrect delta-v above, that came after the Aerozine sniffing began.)

Noticed this causes some null reference exceptions with the toolbar, i.e., NullReferenceException: Object reference not set to an instance of an object at ApplicationLauncher.RemoveModApplication (.ApplicationLauncherButton button) [0x00000] in <filename unknown>:0 at WingProcedural.WingProcedural.OnDestroy () [0x00000] in <filename unknown>:0 Perhaps the member stockButton should be checked for null before being handed off to RemoveModApplication at: https://bitbucket.org/bac9/b9_aerospace_plugins/src/e8e08b27c372ed120ae440757cea7d000c1b1477/B9_Aerospace_WingStuff/WingProcedural.cs?at=master#cl-3256

Wow, Squad must have done something really nuts to change exception propagation that significantly, must make it impossible to stay sane as a mod developer. Anyway, plenty of exceptions in my log as well--always have been, presume there always will be, so there's just no cure then--too bad, great mod! Thanks for taking the time to respond.

Ditto, just observed with satellites that have a Stayputnik as the root and two small, inline reaction wheels (amongst other parts). The wheels were scaled to 0.625 in the VAB. On launch, they're back to 100%.

Sounds like you're using Active Texture Management and need an override to keep it from messing up KCT's icon. ATM's config files are perpetually out of date and so the first place I'd look. I don't have my KSP install handy, but I'm pretty sure I had to add an override file for KCT to ATM.

I'd run many simulations before the launches, edited the craft after starting construction, and duplicated it. To launch I go the space center view then click the KCT icon, then VAB, and finally the Launch button next to the craft in question. Since it sounds like it might be an issue, I'll have a go at some cleaner reproductions and a log file later on.

Seeing something odd that seems new to 1.1.5 and I'm not sure yet if I should report as a bug (could be coincidence with my installing 1.1.5 and is related to some other mod entirely.) Basic sequence is: 1. Use KCT on the space center view to launch an unmanned satellite lifter. 2. Do the normal launch things, you know, maneuver deftly, shout, panic, punch the air when it fails to explode horrifically. 3. Switch to other satellites in orbit to adjust their antennae settings to include the new satellite (which is out of atmo but still coasting to apoapsis) in they're (Remote Tech) network. 4. Once that's done, hit esc, click Space Center. Then I'm taken back to the space center as normal, but after it renders, maybe half a second later, I'm taken back to the launchpad at the time of #1, i.e., faster than I can reach for the mouse, the game reverts to the launch of step 1 above as if I'd been running a KCT simulation instead of a launch. Thoughts? (Does this sound likely enough to be KCT I should go through some more structured repro attempts and get a log file uploaded?)

On a career mode setup in 0.90 I'm noticing past events, e.g., successfully orbiting Kerbin, reaching Mun, are being forgotten and new "be the first to X contracts" are being generated. At first I thought this was a contracts bug, but then I noticed that if I sent different Kerbals, then Final Frontier would award them "first to X" ribbons making me think the problem is deeper in KSP than its contracts code. My question is: can I repair this, e.g., by editing persistence.sfs (now and as the symptom repeats throughout the play-through)? Here's the snippet of persistence that seems relevant (note: the game currently (again) thinks no Kerbal has reached Mun's SOI): SCENARIO { name = ProgressTracking scene = 7, 8, 5 Progress { FirstLaunch { completed = 120716.973798846 } FirstCrewToSurvive { completed = 121416.258603572 crew { crews = Jebediah Kerman } } AltitudeRecord { completed = 447870.213549721 record = 70000 } ReachedSpace { completed = 447870.213549721 vessel { name = Meatball 3 flag = Squad/Flags/retro } crew { crews = Jebediah Kerman } } Spacewalk { completed = 1269197.37314923 crew { crews = Jebediah Kerman } } Kerbin { reached = 120677.913798839 Orbit { completed = 599472.988429759 vessel { name = Meatball 4 flag = Squad/Flags/retro } crew { crews = Jebediah Kerman } } Escape { completed = 3535224.98060267 } Landing { completed = 120677.953798839 vessel { name = Jebediah Kerman flag = } crew { crews = Jebediah Kerman } } Splashdown { completed = 121384.218603565 } SurfaceEVA { completed = 120677.913798839 crew { crews = Jebediah Kerman } } FlagPlant { completed = 1409464.37108338 } ReturnFromOrbit { completed = 600525.815656174 vessel { name = Meatball 4 flag = Squad/Flags/retro } crew { crews = Jebediah Kerman } } } Mun { reached = 3535224.98060267 Flyby { completed = 3535224.98060267 } Escape { completed = 3537471.86158694 } } Minmus { reached = 5111324.97396296 Flyby { completed = 5111324.97396296 } Escape { completed = 5126889.85694749 } } } } [update] Corrected prefix.

I am, and I just pulled SETI and verified this symptom (missing fuel) presents with just RF and KCT and without SETI. Sorry for the confusion folks!

Another issue semi-related to Real Fuels I'm seeing is tanks reading full in the VAB sometimes show up on the pad with a portion of one fuel missing. For example, a "0 Procedural Tank" had 1,621 RP-1 and 1,729 of LOX in the VAB. It showed up on the pad with 1,621 and 1,785 respectively. Not consistent, but not infrequent either. - - - Updated - - - I'm sure it's a problem between Real Fuels and Procedural Parts. I only brought it up here because when the symptom presents, it makes the first few things in SETI fairly difficult at best and so while SETI, with a few Mod Manager patches, is compatible with both RF and PP separately, the bug those two have when together means the three all at once is not a great user experience right now.

The burn time can change on load seemingly at random. This usually only happens if you change a procedural parameter, so it's most noticeable when trying to make a SRB craft that won't exceed the limits of an early contract, e.g., test a chute at 2-5km at 200-500m/s. You may build in the VAB with a burn time of sixty seconds and a TRW of 2 only to find when the craft shows up on the pad the burn time has morphed to 1,200 seconds and so the TRW is essentially zero. So, depending on your mileage, which may vary, the first few contracts may be harder to do or nigh impossible.