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?

I really like the whole concept of TF/LRTF and how that affects my gameplay. I'm not sure what you have on your roadmap with regards to functionality, but Pay To Play is a mod you might want to have a look at. There's a couple of features there that I think would fit nicely with TF. When inside the VAB, right-clicking a part gives the user the option to service/repair a part that has experienced a malfunction/failure (for a fee). It also gives the user the option to replace the part completely. All of this is done via the part context menu, rather than having to manually select/replace parts individually (which is a PITA when they have parts attached to them which then needs to be redone all over again). In my own little perfect universe, I could imagine entering the VAB with a vessel that's been recovered and seeing the TF UI window with the parts of my ship that are defective, where I can then choose to either repair the part or replace it entirely (with some sort of cost model factored into either of these options). I don't know whether that is something that is LRTF vs TF functionality (although I'm guessing it's probably more the latter ?). Also, not sure how much once can borrow from another mod's concept (personally I prefer the term "inspired by") without running into IP/license issues . I'm just a guy who loves the TF/LRTF concept, and Pay To Play, and ScrapYard, and wishes that some smart people like yourself were able to moosh them all together into a single glorious part testing/reliability/maintenance mod that does everything!

So I don't know if this is an issue with TF, or LRTF, or both, or just me being a plain old imbecile. I can see the TF button in the KSC screen, and also the in-flight button and window. What I CAN'T see is anything while inside the VAB - no button, no R&D window, nothing TF related in the right-click part-window. I'm running TF v2.2.0.1 and LRTF v0.7.1. As an aside, the mod itself does appear to be working properly - I launch a rocket with a new engine and I can see the UI for TF, the data accrual, failure reporting etc. I've also been able to confirm that the failures are persistent. Returning the vehicle to the VAB (using KCT here) and then returning it to the launchpad shows the parts are still malfunctioning. What I'm not clear on is whether there is a clean way of fixing these failures while in the VAB - can I see a list of the parts that are malfunctioning, can I repair/replace them from within a UI, or do I have to remember the malfunctioning part/s and manually replace them one by one? Apologies for the questions, I just haven't been able to find any screenshots / videos of people using the mod to give me an understanding of what to expect.

I'm using CNA Consumptor, AmpYear, and Kerbalism together. Although the EC consumption is visible in the Kerbalism windows both in the VAB and in-flight, they're NOT visible in the usage or calculations for AmpYear. I'm not sure if this has to do with how the consumption is exposed to other mods - is this something that might require a change to CNA Consumptor and/or AmpYear in order to work together?

@siimav and @magico13 - I've added in the suggested code and it works just as I was hoping. Thank you both, you're legends!

I have done my own set of part balancing that means I don't have any engines with $0 cost, so can't talk to any issues there. My main "issue" is with the staging being reinstantiated (love that word) by P2P. I've done some testing with the stock SRB's, and noted that while the Mite, Shrimp, Flea, and Hammer SRB's all seem to work correctly, the BACC, Kickback, and Pollux behave differently. I've outlined what I'm seeing for you below. I've uploaded a copy of my KSP.log file and the MM patchfile I created for the KSP parts to DropBox. EDIT: Since P2P does appear to be working (albeit with a workaround required for some engines) this is something I see as more of a tidy up / hygiene issue that a gamebreaking defect. Let me know if there's anything further I can do to support. Here's how the engine maintenance is working for me: this was done using the BACC "Thumper" SRB: 1. On recover to VAB and edit the vehicle, the staging icons for the SRB's are not there: 2. Updating the engine with fuel and maintenance 3. SRB icon is not reinstantiated, however the new Delta-V stats do appear to be captured 4. Saving the edits, leaving the VAB and then re-editing shows the engine updates appear to have been applied correctly

I'm having some trouble where doing maintenance / restore ignitions on some engines does not reinstate a staging icon in the VAB. I've done some static fire tests on the launchpad and when I recover them I'm able to maintain the engine and restore the ignitions ok, but when I've launched vessels and recovered the "restore ignitions" and "maintenance" buttons are there, but neither of them cause the engine staging to be restored. I'm having to remove the engine entirely and fit a new one which triggers the new stage. I've come across this using engines from the Knes mod; other than this particular instance I haven't had any issues using P2P with Knes so far. I'll try testing a couple of other stock parts to see if I have the same problem. Otherwise is there anything I can do that might help further diagnose the problem?

Feature request: Would it be possible to implement a toggle / flag that would restrict the number of tech nodes that can be researched concurrently? At the moment you could (theoretically) unlock x number of tech nodes and they will all commence research at the same time and run their research in parallel. I'd like to "throttle" this so that only one tech node can be researched at a time, similar to how ship construction has a queue mechanism. I currently do this manually by selecting a single tech node for research, then wait for it to finish before selecting the next node, but enabling an automated approach within the mod would be an awesome addition.

Anyone know of a way this can be done via kOS scripting? I've worked out how to use the Action/Event names in the Experiment module to show the info window and activate the experiment, but if the science has previously been collected for that experiment then the experiment simply goes from "Stopped" to "Waiting". If possible I'd like to trigger a force run via kOS code, but I can't find anywhere with a part's MODULE that I can call.

I'm curious... how does this mod compare to Scrapyard and Oh Scrap? Would I be correct in assuming this an alternate (and therefore incompatible) to these other mods? I like the idea of recovery / maintenance / reuse of parts. I'm wondering what sets this mod apart from (better than?) similar mods out there.

As many have pointed out Kopernicus is a HUGE mod in term of what it changes in the game. But does ALL of it have to move to stock in one go? I think one of the features that would be great to have in stock would be the ability to re-scale the game. Being able to start a game and having the 'out of the box' option to pick from standard, 2x, 2.5x, 3.2x, 5x, 10x..... you get the point. By implementing processes "under the hood" where solar systems and planetary bodies can be rescaled, this would (hopefully) provide the hooks that modders can tap into in order to specify their own custom rescales. The devs wouldn't even have to worry about part balancing really; we already know the stock parts are a bit OP and are perfectly adequate for the smaller rescales, and there's a ton of mods already out there that either modify the power configs of stock parts to make them workable at larger scales, or even introduce new components which are better suited to upscaled sizes anyway <looks knowingly at BDB>. Once you've tackled the challenge of rescaling, then the other components start to fall into more manageable pieces: Adding in additional planetary bodies Editing existing planetary bodies Deleting and/or substituting either individual planetary bodies, or entire solar systems. As some have already pointed out, it appears that the Kerbal system is 'hard-coded' entities rather than treating planets/moons as configurable entities. My guess is that that the effort to transition to a config-based system would be "not inconsiderable". As a software development studio, it then begs the question "why invest the effort to create a feature for people who have already paid for the game". In all fairness, I think the folks at Squad are fairly respectful of the user community and do listen to feedback. They have already shown that they are willing to make functionality / quality of life improvements outside of the payable DLC content. So why make these changes? I think there's a couple of valid reasons Squad should take a look at this: There is a clear and unequivocal demand from the user group that this is a functionality change that they want to see included at the base level of the game. There is the capability of being able to 'hide' this functionality behind the paywall of a DLC pack, making the decision to incorporate these changes an economic one rather "all work and no payoff"; or They use this as an opportunity to develop a system as a "proof of concept" that can be used in future releases (KSP2 anyone?). Perhaps the most enticing of these is reason three. For example, it opens the door for Squad to make new DLC packs (income generation) which focus on new star systems / planets. Done Kerbol in 2.5x? Well have a try of our new "Alpha Centauri' DLC pack, or the Sirius DLC which features "hot" gas giants circling in close orbit around a binary star system. In the end, we all love Kopernicus and what it enables us to do in a game we all enjoy playing (shut up kraken, I'm not talking to you). If there were only a handful of people that played using JNSQ or OPM or ReScale then I doubt we'd be having this discussion. In reality there is a significant number of us who are committed to playing with these mods, and the effect is that many of us are not keeping up with content patches / bug fixes with the latest releases because Kopernicus update isn't available. < TO THE DEVS > Devs, if you're listening (well, reading actually, but whatever): is this something you have written on a card wall somewhere? Is there an item in your improvement suggestions list that says "Kopernicus" or "stock rescaling". My hope is that there is, and if you don't, then I suggest that there be a genuine sit-down discussion between the guys who pay the bills and the guys who do the work about putting this on the radar. And let us know... if the decision is "we're not doing it" then that's ok, the community will keep doing what it has always done. But on behalf of all the other players of this awesome game as much as I do, I really hope you give this one some serious consideration.