Strych74

I've been wondering the same thing. I suspect Strategia is looking for a specific trigger to hook its reward function into. This trigger works for stock science but not for the way Kerbalism science is handled. I noticed the question about getting "To Boldly Go" to work with Kerbalism was also asked on the Strategia thread, and the response was unfortunately "go ask on the Kerbalism thread". From the bit of digging around I've done I suspect getting a fix will require actual programming rather than via an MM patch, which is beyond my skillset. My work around has been to open the console (Alt-F12) and manually credit funds for each new biome I collect science from. Note - it's only one payout for each new biome, not for each experiment per biome In the meantime, if there are any individuals with coding skills able to come to the rescue you would have our undying and everlasting gratitude!!!

No probs. Just in terms of additional data which might help, the cloned buttons also appear in the SPH, but all the clones are removed when restarting the game. I also considered whether Janitor's Closet might somehow be involved, but I've removed JC and still getting the same behaviour

I'm using the new version 0.8.1. I've noticed that every time I go to the VAB the TF icon is being copied. Doesn't matter if I'm editing an existing vehicle or going straight to the VAB, the icon generates. I've also tried exiting the save and reloading from the main menu, however the buttons are persisted. I'm about to test what happens with the SPH and also with a restart, and update accordingly.

Quick update. I did the seed change and reduced the randomise value to 4, but had another part come up with a NaN time. I've dropped the randomiser to 3 and so far (touch wood) not a problem. On a separate note, since parts are persisted with KCT, anything failures that happen in flight are kept when the vessel is recovered to the VAB/SPH. Unfortunately there's nothing in the VAB/SPH that allows you to identify the broken part/s. There's two things I'd really like to be able to do in the VAB in relation to failed parts: As a minimum, identify the failed part, either through a part's PAW or via the TestFlight UI. The ability to 'fix' and/or replace the failed part. Again, using the PAW would be fine. Borrowing the idea from Pay to Play, perhaps have a cost related to the repair of the part? Are either of these things something that's possible to add via LRTF, or is that functionality something that belongs to TestFlight core?

I've popped the quicksave as well as my MM.configCache file in a DropBox folder. The part I'm having a problem with is the battery - if you search the .sfs file for "cid = 4286892222" it will jump you to the specific part on a vessel on the launchpad. I'll give your suggestion a go and see if that makes a difference. I did have the randomization slider set all the way up so fingers crossed dropping that a notch will help.

Hi Pehvbot, I was wondering if you have had any luck with the 'NaN' errors - I came across one for the first time yesterday with a battery part. I'm still accumulating data, and in the MM.ConfigCache file the part has a MTBF value, but I haven't had any failures with the part itself. You mentioned that LRTF fails to create the failure curve - is there a way to reset / regenerate the curve?

<Yawn>... sorry, my eyes glazed over when you mentioned DLLs. MM patches are about the limit of my programming expertise. I'd love to learn how to do more of the complex stuff - I've got plenty of ideas rattling around in my brain, but but have no idea of where to start!

I've recently put the error logging to screen and noticed that when loading the game I've gotten a few alerts about this mod. Here's a sample from my log file: I know I don't have any of the huge parts (last few categories) so I can understand if these categories aren't instantiated. I'm just wondering if it is normal/typical behaviour to report these to the log file as errors, in which case I can safely ignore, or is this behaviour unusual and I need to dive in a little deeper. Happy to dig out all the mod list / log files if necessary, but didn't want to bother anyone with in-depth checking if the answer is "oh yeah, totally normal, does this all the time!"

Would it be possible to use the TestFlight GUI in the VAB to show any failed parts on a vehicle? Since the parts are persisted, so are their failures - there's been a couple of times when I've recovered a craft, refuelled and relaunched it, only to find that a part that failed on the previous launch is, well, still failed. Unfortunately, at present there's no way to identify the failed part in the VAB/SPH so that I can fix/replace the part. Being able to use the GUI to at least list failed parts would help so that I can manually replace them. An even better option would be to extend the PAW so that I have the option to repair/replace the defective part, ideally without having to manually pull one out of the inventory and attach, which can be quite tedious for a craft that has a large part count, or fiddley placement. At the moment, I'm having to rely on the TF failure messages to identify the failed part, and then wonder which one of the 6x symmetry parts was the one that failed. It's worth having a look at the Pay to Play mod, which has this PAW functionality. In a perfect world the "ideal" mod would combine your part reliability mechanics with their VAB part handling...

I'm (definitely!) not a programmer, so please forgive my naivety, but is it possible to "extend" the existing parachute failure code to cover the RealChuteFAR module? Something along the lines of "IF MODULE = [ModuleParachute] OR [RealChuteFAR] THEN DO LRTF_FAILURE_PARACHUTE"? (sorry about the clunky pseudo-code).

So would using the @atmoTopLayer produce the same atmosphere curve as the "hard-coded" version you provided above? Would you recommend using the atmoTopLayer rather than the hard-coded curve to 140k?

Hi, sorry to bring up an old post with (yet another) rescale question. I'm setting up a new save with a rescaled atmosphere of 140k. I have set up a MM patch for SigmaDimensions using the values below. This patch produces the following values, taken from the MM.ConfigCache: pressureCurve keys have been multiplied by 1.25x. PressureCurve values remain unchanged. MaxAltitude is 87,500m. In the tracking station the atmosphere height correctly reports 140km. Barometer readings above 87.5k altitude all show "minimal". What I'm not sure of is whether there has been any extrapolation of your pressure curve - your last key is "70-0-0-0" so it made me wonder whether extrapolation is not possible because your curve isn't an asymptote, it has a hard 0 value at altitude 70km. I came across one of your posts from waaay back that talked specifically about extending/extrapolating the curve for a 140km atmosphere: I had a go at multiplying the key values of these curves by 1.6x (giving me a final key of 112km) which was then picked up by the Sigma patch and left me a curve out to 140km, but turns out the curve wasn't extrapolated, only the keys were multipled (first by me 1.6x, then by Sigma another 1.25x). In the tracking station I wound up with an atmosphere of 224km, so clearly not working right. I was hoping to get your guidance on how best to handle this, I'd like there to be "some" atmosphere in the 100-140km range, even if it is only very light. I suspect the solution might require tweaking the last couple of keys to make the pressure curve asymptotic but not really sure if that's the correct solution or not.

From the checking around I did, there's definitely something funky about FAR. I've checked the logs, turns out FAR patches all of the parachute parts to replace ModuleParachute with it's own version RealChuteFAR. This is happening before LRTF occurs (I think). I added in my own patch file to add the lrtfConfName flag at the same time LRTF is patching all of the other parts, and I can see the parts are then correctly inheriting the LRTF test modules further down the config. I can't rule out the possibility that FAR does some funky stuff at the end of the process, however - I've written another config patch to run at :FINAL that should add two additional fields to the RealChuteFAR module, but for whatever reason they don't appear. I can't see anything in the cfg files to explain why this might be happening, so I'm guessing it might be in the .dll's somewhere, but that's well beyond my limited programming expertise! It's worth noting that FAR has some logic in it's early patching to allow for RealChutes. Basically, if someone has both FAR and RealChute, then RealChute will run first and patch the parts it knows about, converting ModuleParachute to RealChuteModule. FAR then patches anything left over and converts ModuleParachute to the RealChuteFAR. Either way, if someone has one or the other (or both) then most (if not all) of the stock ModuleParachute MODULES will have been renamed/replaced. Here's a link to the ModuleManager file and log, I've also included the patch file from FAR as well as my own LRTF patch intended to make FAR compatible with LRTF. Enjoy https://www.dropbox.com/scl/fo/9rqxoxjplmmpwlmipxc6g/h?dl=0&rlkey=4ugkph0d6fdhljkoeq5hkufht

I've been experiencing some exception errors which "look" like they're related to LRTF - although I can't be sure if there may be a mod conflict. From what I can tell: The error only triggers when there's a parachute attached to the vessel Stock parts as well as the parachutes in USI Sounding Rockets trigger the error Parts from Bluedog Design Bureau, KNES, RN US Rockets, and RealChutes do NOT trigger the error I've tested them with FAR installed and then removing FAR, however the errors still generate. **EDIT** : I've checked the ModuleManager.configcache, all of the parts have the LTRFFailure_ParachuteDeploy module, and as far as I can tell they all look correct (albeit the configuration= key is different for each part). Please let me know if there's anything I can provide which might help lock this down.

Back again. I've started a new save and am currently doing a bunch of sounding rocket launches using SRB's (USI Sounding Rockets) using a rescaled Kerbin. I'm finding I'm getting a LOT of 2nd stage ignitions due to the dynamic pressure penalty. I like the idea of this, but I am wondering how I can fine tune this. I came across the following code in the "configure_engines.cfg" file. Would I be correct to say this looks like a hard-coded pressure curve (altitude, %ASL air pressure)? @PART[*]:HAS[@LRTFCONF[Engine]:HAS[#pressureFailures[?rue]]]:FOR[zTestFlight] { @MODULE[LRTFFailure_IgnitionFail] { pressureCurve { key = 0 1 0 0 key = 5000 1 0 0 key = 15000 0.85 -2.25E-05 -2.25E-05 key = 30000 0.4 key = 50000 0.15 0 0 @key,*[0, ] *= #$../../LRTFCONF[Engine]/qMult$ } } } I'm wondering how to tackle this, and keen to get your thoughts. My thinking on this is: Define my own pressure curve, or take a pressure curve from another source (e.g. Realistic Atmospheres) "Tweak" the failure curve based on engine type, e.g. solids have a lower penalty than ASL liquid engines Would there be a way to link the ignition failure chance to the DU of the engine as a further modifier? So as an engine increases its testing, it's probability of ignition at a given dynamic pressure also improves?