Pehvbot

Thanks for the report! The error comes from the mod looking for the stock ModuleParachute MODULE but not finding it. My first guess is that there's a custom parachute mod such as RealChute installed. If this mod is being configured after LRTF then LRTF sees the stock MODULE, loads all the failure info, but the stock MODULE gets replaced by the new mod later. LRTF doesn't know it's been replaced so it just tries to run, can't find ModuleParachute and poops its pants. If you can send me a link to your ModuleManager.ConfigCache file I can check to see if that is what's happening. If that is the issue then the immediate solution will be to disable parachutes in the Settings/TestFlight window. You won't get parachute failures but your game should work otherwise. Moving forward I'll add in some error checking so if something like this happens it will fail a bit more gracefully. In a perfect world I should add failure modules for things like RealChute but I just may not have the time. Even if this isn't whats going on, I do need to add more error checking for issues like this.

My first guess is that this may be an ordering issue with the part you created. Since it's being created FINAL, after all the LRTF configs, it may be trying to use radialDecoupler for all the configs. It's probably safe to create the part much earlier. See if removing FINAL fixes things. If that's not it, send me the ModuleManager.ConfigCache file and a saved game with an active vessel with this part. I'll see if I can figure out what's going on.

Thanks! I've had a blast (pun maybe intended?) working on it. I'll take a look at Pay To Play when I get a chance. Adding in a built in repair/replace feature is likely outside of my ability and/or time. TF does all the user interface work and doesn't have VAB tools. I do think it might be possible to create a simple button to open the PAWs (part action window) for all the failed parts. This would make it much easier to locate and fix any failed parts with something like PtP.

Yep, the pressure curve is hard coded and the same for all engines. The module looks for dynamic pressure (specifically the Part.dynamicPressurekPa attribute ). It uses this to modify the base ignition failure chance which is based on du. The curve values were lifted directly from StarStrider42's original code and I'm not entirely sure how well they match with real world engines. I've actually removed the dynamic pressure failure from SRBs in the current dev version. I can't find any documentation on this being an issue and it I don't think it makes much sense in any case. Solids typically ignite form the top of the motor and once lit nothing will put it out. You can still get ignition failures, they just won't get worse based on dynamic pressure. If you wanted to keep them you can add in the following script somewhere. @PART[*]:HAS[@MODULE[LRTFFailure_IgnitionFail],#lrtfConfName[Solid]]:AFTER[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 } } } You can make simple adjustments by tweaking the second values in the keys (0.85, 0.4, 0.15). The higher the values the more reliable the engine. I use this super useful mod to help visualize these curves. You may want to wait until the next version is published though, I've made a few changes in how it orders things.

Got it! It was a bug in my code, but not what I first thought. Your fix pointed me in the right direction: @PART[*]:HAS[#lrtfConfName[Solid],~lrtfBurntime,@MODULE[ModuleB9PartSwitch]:HAS[#baseVolume]]:NEEDS[LRTFConfig]:BEFORE[zTestFlight] The script was supposed to look for the amount of fuel stored by ModuleB9PartSwitch using the baseVolume and using that to calculate expected burn times. The problem was it was only looking for the module itself. Because RealFuels sometimes no longer uses baseVolume, the script was trying to do math on something that doesn't exist.

Looking deeper into it, it looks like the original MM script is correct so there may be an issue somewhere else in the process. I'm not getting any error messages and the Bluedog SRBs I looked at seem to work. Do you know which part(s) were not working correctly? I'm not sure if this is related, but one rare problem that's come up is the failure curve isn't calculated properly. LRTF creates a random failure curve for each part in each new save game and once in a while it fails to make a valid failure curve. The TestFlight window gives a 'NaN' (not a number) error for that part.

There isn't much to see in the VAB. If you center click on a placed part you should see things like the number of data units ('du') collected so far for that part and the failure chance but that's about it. This is how TF is designed. The latest versions of TF have removed the (apparently problematic) R&D options. KCT will remember your parts so yeah, there's currently no method for 'clearing' the error simply by recovering it. What I do is reload the entire craft from the saved vessel. Interestingly, by doing this it tends to add some time back to the build process which is a pretty good approximation for the time it takes to fix the part. Ideally there should be an option to reset parts in the VAB but this may be a bit beyond my skill level. Maybe something for a future update?

Good catch! Yeah, that was a typo and your fix is correct. I'll roll it into the next update. Let me know how it goes. Any feedback is super useful. This is still deep in the 'work in progress' phase.

I'm adding this mostly for myself, so I can remember where to look if I need to do this again. The latest version of MacOS has removed the 'checkbox' that allows you to run MacOS apps in lower resolution mode. This means if you run KSP on a Mac with a Retina style screen it can't be upscaled by the OS and will appear very small. The solution is to right click on the KSP.app and select 'Show Package Contents'. This will show the hidden parts of the KSP.app. Open 'Contents' and then open the Info.plist file with a text editor (TextEdit will work). Scroll to the bottom of the document and just before the final two lines insert <key>NSHighResolutionCapable</key><false/> It should look something like this: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> ... [A bunch of stuff up here] ... <key>NSHighResolutionCapable</key><false/> </dict> </plist>

It looks like a glitch to me so I would say 'Cheat'. Open the cheats->contracts menu and complete it that way.

You can disable it from the TestFlight panel in the KSC view. Look for the pull down menu in the bottom right to find panel with the toggle. I forgot which pane it’s in. Look around and you should find it.

Yep. It gives the RP-1 tech tree, contract tree, etc for stock sized worlds.

Yes, but doing this will also break your craft builds and it’s completely untested and means editing the rescale.cfg file. I think there’s a description up thread on some pointers to how to do this A good option might be to use KSRSS, the Kerbal Sized Real Solar System mod instead of RSS. Existing craft should work just fine and LRTR is fully balanced for it.

For what it’s worth the config.cfg file controls most of the RP-1 features and KCT can be turned off from its KSC scene menu. It’s a round about way to do it but you can run it in more or less stock that way.

Less Real Than Real(ism) does this as well as adds a modified version of RP-1

Is the part a fairing base? The rescaler scales fairings asymmetrically. I did this because stock fairing bases are too thick when scales 'correctly'.

Less Real Than Real(ism) does exactly this. It upscales the mass and performance of nearly all stock and stock-alike parts. It also includes a modified version of RP-1 with the contracts, science, crew training, etc. You can disable most of these features from the config.cfg file or by simply turning them off in the game menu or KSP scene.

v0.7.1 is available. It fixes a small bug with dynamic pressure (Q) engine failures. https://github.com/pehvbot/LRTF/releases/tag/v0.7.1

Version 0.7 is out! This is a fairly major update and reworks the reliability curve which determines the parts failure chance. https://github.com/pehvbot/LRTF/releases/tag/v0.7 The mod now creates a unique reliability curve for each part in each new game save. In practice this means each part will have its own development path during your game. Some parts will have a relatively smooth development, with fewer early failures, others may be more difficult to perfect but eventually offer a highly reliable part, and some parts will just be trouble and never get fully perfected. You won't know until you try! You can set the random-ness from the KSP Settings-TestFlight tab Here's a good example of two similar parts with different development cycles: (special thinks to sarbian for the AmazingCurveEditor mod) The left part starts out a bit less reliable but quickly settles down and in the end is pretty reliable. The right part on the other hand has quite a troubled development and takes a while to iron out all the issues but never quite solving all of them. In general parts take about 10 flights to fully debug. The X axis is the chance of a failure for the full flight time and the Y axis is how many du (development units) you have gathered. You can see that the left part is mostly debugged by flight 2 while the right part takes 3 flights and still has issues. While this shouldn't break existing saves, the mod is still a work in progress, so keep that in mind when upgrading.

Version 0.6.4 is out. This fixes a problem with the instantaneous decoupler failures not properly registering with TestFlight. https://github.com/pehvbot/LRTF/releases/tag/v0.6.4

Version 0.6.3 (skipped a 'bad' version 0.6.2) is out. It now supports the new TestFlight v 2.2.0.1. I recommend updating to the latest version of TF as it fixes some issues. https://github.com/pehvbot/LRTF/releases/tag/v0.6.3

IMPORTANT: TestFlight has been updated to 2.2.0.1 but the update breaks the current version of Less Real Test Flight. I should have an update of LRTF over the weekend to fix this issue. In the mean time you may not want to upgrade TestFlight.

I don't know if it's included but it should be compatible. There is an RO kerbalism config. Note: I have never used it except for a few quick tests so I'm not 100% sure

Use the CKAN RP-1 express install but uncheck any of the visual mods and use the lower res version of RSS. You will need to downgrade your KSP version to 1.10 https://github.com/KSP-RO/RP-0/wiki/RO-%26-RP-1-Installation-for-1.10.1 It should run okay on most systems.

Most times, it's because the KSRSS folder is in the wrong place. When the download is uncompressed it comes in a containing folder. Be sure to copy the KSRSS folder itself into the /GameData folder (i.e. it would be [KSP Folder]/GameData/KSRSS