Pehvbot

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

Version 2.0.3 is out. It's a very minor update that fixes EVA science. https://github.com/pehvbot/LRTR/releases/tag/v2.0.3 The companion Kerbalism config was also updated to version 1.0.5 to fix some science issues. https://github.com/pehvbot/LRKerbalism/releases/tag/v1.0.5

Version 0.6.1 is out. This officially adds in decoupler failures. It also optimizes du bonus code to run a bit faster and adjusts failure probabilities for a few categories. https://github.com/pehvbot/LRTF/releases/tag/v0.6.1 Not sure what's next for failures. I still want to add in the ability have somewhat randomized failure curves so each new save game has unique failure probabilities for each part.

I've experimentally added decouplers to the failure modes. I'm not sure about them yet because they use a slightly modified version of the stock ModuleDecouple and ModuleAnchorDecoupler modules. They definitely need more testing but if you want to look at them, they are in the latest master branch on the GitHub (not the latest 0.6 release). The failures are: Fail to decouple Pyros failure (0 force on decouple) Premature decouple

Version 0.6 is now available. This adds two major features. It adds antenna/communications failures and it adds in data unit (du) bonuses based on category and manufacturer. In practice this means du recording will be a bit faster and later parts will start out more reliable than earlier parts. The failure rates have been rebalanced a bit to reflect this. https://github.com/pehvbot/LRTF/releases/tag/v0.6

There's not enough info here to be sure, but the most common cause is putting the Bluedog_DB 'root' folder in the wrong location. If you manually downloaded it, it can unzip into it's own GameData folder (i.e. Downloads/GameData/Bluedog_DB). Sometimes people copy the entire GameData folder into the KSP GameData folder so you wind up with GameData/GameData/Bluedog_DB.

Sadly, there's very little documentation yet. It's still in flux a bit. I guess (...sigh...) that's next on my list of things to do. If you have any questions about how to customize the failure modules let me know.

Version 0.5.1 is available. It's a very minor update that removes IntakeAir as a failure resource and removes the TestFail button . https://github.com/pehvbot/LRTF/tree/v0.5.1

Thanks! It's still a work in progress, but I'm happy with things so far. I'll be posting a minor update soon to remove the force failure button since that's just for testing plus a couple of minor fixes. I expect there are a bunch of hidden bugs and it hasn't been tested against very many mods yet. There's one known bug from the TestFlight core. It will throw some [EXC] errors in the log when you recover a vessel. It looks to be harmless but you may see it when you leave or recover a craft.

Your craft has officially 'launched' and you don't have the technology (I forget which node) to recover vehicles launched from the launch pad. It's not 100% realistic (Gemini 6 had an abort just after launch and was recovered) but that's how the game is. I think you can allow launch pad recoveries by playing with the CustomBarnKit configs.

Version 0.5 is available. This is the first version I would consider playable in a career game. It updates all the engine failures so they now enable repairs and keep their failure state if the game is reloaded. https://github.com/pehvbot/LRTF/releases/tag/v0.5 Significant updates for v0.5 Engine failures can now be repaired More than one resource can fail per part Preliminary support for Kerbalism and RealFuels As of now LRTF has the following failure types: Engines Coolant (overheating) Performance Loss (lower ISP) Shutdown (in flight engine failure) Gimbal alignment errors Gimbal failure (locks the gimbal) Gimbal speed (slows gimbal reactions) Ignition Failure (engines fail to start) Explosion (engine rich combustion) Avionics (still not sure it makes sense to have all these failures. will playtest to see which ones are the most ... interesting) Axis failure (one of the 6 axes [pitch,roll,yaw,transx/y/z] failed) Axis clamped (one of the 6 axes does not have full control) Axis deadzone (one of the 6 axes is missing control for a section of the axis) Avionics glitch (random dropouts on one of the axes) Inverted (one of the axes is reversed) Partial avionics (one of the axes does not have full range) SAS failure (SAS module has failed) Jammed Thruster (no control over the thrusters) Total failure (no avionics control at all) Resources Resource leaks (slow leak of a resource) Resource failures (resource will no longer flow but can be pumped to a working part) Aerodynamics Disabled control surfaces Deployed control surfaces (partial deployment of surface) Parachutes Reefing failure (parachute will not fully inflate) Deployment failure (parachute fails to stage or deploy) Failure (parachute completely detaches or won't deploy at all) RCS RCS block fails Reaction Wheels Alignment errors (pitch, roll, and yaw will not align correctly) Failure (reaction wheel fails completely Wheels Brake failure Steering failure Motor failure

I've been messing around with the TestFlight failure mod. It's a super configurable and has a lot of neat features, but it's also very incomplete and a royal pain to configure. It's almost exclusively used for RealismOverhaul/RP-1 and it shows. I've been trying to see if I can bash it into shape for stock and stock-ish games and honestly I've been having a lot of fun doing it. I've added in support for non-engine parts as well as a repair option (both missing or broken in the base TestFlight) The mod is really designed for 'in flight' failures rather than long term ones so anything that can go wrong happens while you are actively controlling your vessel. My question is: How useful and/or annoying would it be to automatically open up the PAW (the Part Action Window) when a part fails? Obviously this feature can get enabled or disabled. My thinking is getting quick access to the specific part that fails would give a better chance to react to failures and to deal with them in real time, but I don't know if this would be too intrusive. Any thoughts on this?

Version 0.4 is available. It includes some bug fixes but mostly it adds part repairs. As noted above this is currently only for non-engine failures (although you may notice that gimbal failures can be repaired as the stock gimbal failure is broken so I added this in using the LRTF extension to TestFlight). I originally planned on just adding a basic repair ability for testing but... I don't know. Things got out of hand I guess. https://github.com/pehvbot/LRTF/releases/tag/v0.4 The mod in approaching usability, but isn't quite there yet. It's playable but probably not for a save game you care about. There are still quite a few issues that need to be fixed or adjusted, including: Currently resource failure modes can only happen on one resource at a time (or ALL resources). This is a limitation of the TestFlight core mod. It needs to be able to fail multiple times (e.g. both LiquidFuel and Oxidizer should be able to both fail independently on each part). Avionics failures are not well balanced or thought out. They should probably be pared down and possibly modified a bit. Failure probabilities still need a lot of work. Repairs are brand new and almost certainly buggy. It's a bit complex and I'm still not sure if it shouldn't be simplified. So the next step will be to fix how resources are handled and maybe add in control surfaces.

The vast majority of times this is a problem with placing the planet pack in the wrong place. It should be [KSP Folder]/GameData/KSRSS. Sometimes it ends up in [KSP Folder]/GameData/GameData/KSRSS or has an altered name (e.g. KSRSS Copy). If it's not something as simple as that you may want to head to the KSRSS page: Following jimmymcgoochie's advice above, they may be able to help.

Another update coming as soon as I can nail down a few glitches. This one has a bunch of bug fixes and adds repairs! At least for non-engine failure modes. Core TestFlight is missing a few key features. One is remembering its 'state' when a craft is reloaded, the other is a functioning repair feature. I'm avoiding messing with the core engine failures for now, so these won't have a repair feature or remember their failure state, but all the other failure modes have these features now. Repairs will have a probability of success based on the type of failure (hardware or software for now, others are possible), the number of 'data units' (du) gathered for that part, and ciucrmstatinal adjustments based on the failure type combined with: Comms connection to the ground and the level of Mission Control Whether a trained astronaut is aboard and their experience level The least stupid astronaut aboard Whether an Engineer is aboard, and their level If an astronaut is on EVA If there is a repair kit available The base repair probability is more or less the inverse of the failure chance (i.e. it uses the same number of du and the same failure curve). This number is modified based on the above adjustments. In practice this means parts are unlikely to be repaired until you have nearly maxed out the du for that part (i.e. fully tested and debugged it). Software repairs for example are almost entirely based on contact with Mission Control and its level, with a small bonus for an astronaut, their brains (i.e. inverse of their Stupidity), and if there's an engineer, but with no bonus for EVA or repair kits. Hardware repairs do best with an Engineer on EVA with a repair kit and contact with Mission Control but still get some bonuses for astronaut level and brains. Repairs can be retried but only if the repair probability is better than the last attempt. There is always at least a 1% of repair and it's never higher than 99%. In practice situations are never ideal and repair chances are lower than this. Early in a career you can expect repair rates in the 2-3% range. Late career can give something like 95% under optimal conditions. There's a difficulty slider in the Settings window that can adjust the repair chance a bit.