Pehvbot

As a followup, while this solution works, there's an edge case that still has this issue. If a ModuleSAS fails and the craft is no longer infocus but still loaded (i.e. from undocking or EVA) and returned to while still loaded and then repaired, none of the SAS modes turn up. Leaving and returning to the craft (i.e. just pressing the '[' key) fixes the problem. I haven't found a way to trigger the reevaluation that fixes this issue so at this point it's either bin the whole idea or live with this glitch.

I was never able to stop PartResource.FlowMode.None from allowing magical resource transfers. Other parts seem to still see it as a source/destination for transfers regardless of flowState or flowMode. I finally just went with just flowState = false and hideFlow = true. This still allows manual resource transfers, but since the mod is really intended as an 'in flight' failure mod, it seems like a reasonable compromise. Hey, if players can manage to transfer fuel while in flight (or have a craft that can survive a tank pressurization failure and transfer it later) good! Yeah, I ran into the PAW update problem. I went with MonoUtilities.RefreshPartContextWindow(part); but this looks like a better option. I'm still very much at the 'monkey pounding the keyboard until something good happens' stage here so I really appreciate your help.

Perfect! This solution does the trick. SAS is just being disabled/enabled with ModuleSAS.moduleIsEnabled, so definitely nothing fancy. Technically SAS does work (i.e. you can press the SAS button) if the reloaded vessel is repaired, it just doesn't have any SAS levels (not even 0) so it doesn't do anything. You are probably right about some events triggering re-evaluation for SAS. My other option was to find if there's an accessible function that can manually trigger this, but I wasn't able to find it. Thanks for the help with this.

I am working on extending the TestFlight failure mod and have run into a problem with re-implementing a failure when a vessel with a failure is reloaded. Other failures can be redone during OnStart(), but the ModuleSAS failure has a problem. If it's re-implemented during OnStart() the vessel will not activate SAS again if the part is repaired. The repair works fine if the vessel never leaves context (i.e. you break and repair it from without reloading) and if you repair it then reload it, SAS returns. Something happens soon after the vessel is loaded where it seems to pick up it's available SAS levels. Neither OnStart nor OnStartFinished works. If I re-implement the failure using OnUpdate, add in a small 20 frame delay then 'fail' the part, it works correctly and sees SAS when it's repaired, but only if it delays things for a few frames. //this one works, as long as the ticker is above 10 public override void OnUpdate() { base.OnUpdate(); if (failed && ticker++ == 20) DoFailure(); } //doesn't work public override void OnUpdate() { base.OnStart(); if (failed) DoFailure(); } Obviously this is a really ugly hack. Is there a better way to run a function soon (but not too soon!) after a vessel has been loaded? Or maybe there's a way to update a vessel to 'see' it now has SAS available when the part is repaired.

Version 0.3 is available. This is a pretty big update and is more or less the first playable release. It's still only tested for stock games and doesn't support some fairly critical mods yet (RealFuels, procedurals for example). https://github.com/pehvbot/LRTF/releases/tag/v0.3 Full features list for this version: Adds a submenu to the TestFlight Game Difficulty menu: Supported failures can send a message to the Messages menu Supported failures can halt time warp Supported failure types can be enabled or disabled (Wheels will be added later) Resources/Tanks Avionics/Command RCS Reaction Wheels Parachutes Adds failure types to the PAW of each part that fails. Engine failures are still using the stock TestFlight failures. Engines are divided into 'types' with rated burn times, failure modes, and failure probabilities applied to each type: Solids Boosters Sustainers Vacuum Maneuvering High Efficiency Jets Nuclear Electric Rewrites and refactors non-engine failures so they are properly applied if a craft is reloaded in flight (missing feature in stock TestFlight) Resources/Tank failures (leaks and access failures such as pressurization failures or battery failures) Avionics failures (SAS failures, alignment errors, etc) RCS failures (currently disableds entire RCS block, others may follow) Reaction wheel failures (torque failures and total failures) Parachutes (reefing (full deployment) failures and total failures) Wheels (brake, motor, and steering failures) The actual failure rates are still being adjusted since these really require some playtesting and most of my time has been used adding features and testing for bugs. I've removed solar panel failures for now. TestFlight really works best when applied to 'in flight' failures and doesn't really work for long term failures. There is still a whole bunch of things that need to be done so this still isn't 'Save Game' ready yet. The next things on my list are: Begin adding a 'repair' function. This is a longer term project so the first version will likely only be for debugging/cheating at first. Balancing failures probabilities for the various parts and failure modes. Bug fixes Bug fixes for the bug fixes above More bug fixes After that it's expanding support to non-stock mods but I don't know how far I can take this yet.

https://github.com/KSP-RO/RealismOverhaul/tree/dev You would need to download the entire source tree and extract the GameData folder (green Code button on the upper right). However, using a dev version is a bit dangerous. Don't expect it to always work or be complete. It's in development for a reason.

I'll be adding a substantial update sometime over the weekend but this is definitely more work than I was expecting. TestFlight is a really interesting failure mod but it's quite incomplete and everything except engine failures is badly broken. I guess that shouldn't be a surprise since more realistic engine failures was the main goal with everything else an afterthought. I think most of the non-engine stuff was written for testing but not fully implemented. The biggest issues is that TestFlight has no built in mechanism for saving failure states, so reloading a craft erases most (but not all!) failure effects. Fortunately it's super extendable. It's fairly easy to create new failure mods that include the ability to save and restore failures. My current focus will be to add and improve non-engine related failures and just use the 'stock' engine failures. So far I've created or updated: RCS failures Tank(resource) failures Avionics failures ReactionWheel failures The mod works best for instantaneous or in flight failures so the things I'm adding will only look at parts being actively used. Another big issues is it doesn't really have a repair mechanism. It has 'stub' functions that I think the devs were hoping would get used at a later date. It doesn't look like it would be super difficult to add in a fairly simple repair mechanism so this may be next on my list after creating a core of non-engine failures and getting things in a more or less playable state. Extending this mod to beyond just stock (RealFuels, Procedurals, etc) is likely a far future task.

I've also been playing with a failure mod and I am trying to 'lock' a resource (think pump failure). PartResource.flowMode looks like it does this since you can set the resource to FlowMode.None and the resource is still there but can't be accessed. However this does not stop other parts from seeing the resource for transfers. Other tanks can fill or drain infinitely via transfer without changing the failed resource. I haven't found a good way to stop this from happening. Things I've tried: Use PartResource.flowState (the start/stop button in the paw). This works for using the resource (i.e. it can't be used) although it still allows resource transfers, just without the magic infinite resource. I also haven't found a good way to lock the stop button so it can't just be turned on again. I think I can hide button but haven't gone any further. Use PartResource.isVisible. This works but it of course removes the resource from the PAW. I do put a failure message in the PAW, but this is not ideal. Things I think might work: Swap the resource for a dummy resource. I'm not sure how to do this and I don't think it will play well with other mods. Disable crossfeed. I don't know if this can be done with a single resource though and I have no idea how to do this either. Remove the resource while broken and add it back in after it's repaired. I assume I can create a hidden 'Mass' resource via MM and add or remove the right amount of mass to balance the removed resource, but this seems clunky. Right now I'm just locking and hiding the resource. Something like: resource.flowMode = PartResource.FlowMode.None; resource.isVisible = false; Does anyone know if there's something I'm missing about this 'broken' resource transfer behavior or have any better ideas?

Thanks! For the engines I've just kept the numbers from StarStrider42's base mod which are about half that. I think you are right though, these may be a bit punishing. I'm trying to balance things so a first flight gives something like a 50/50 chance for a successful launch, depending on how many new parts are used. So far most of my focus has been adding in a few new failure types, in particular for fuel tanks and RCS. Some of the stock TF failure types don't look like they were ever fully tested (in particular the avionics/ModuleCommand stuff) so those may need more work as well.

Version 0.2 is out. It adds RCS support and changes how fuel tanks are 'recorded' plus a bunch of other changes to the failure modes and failure curves. https://github.com/pehvbot/LRTF/releases/tag/v0.2 I've moved to a design goal of only tracking parts while in active use as much as practical. TestFlight is primarily an engine failure mod and seems to work best when parts can only fail while being used. In practice this means MTBF will look fairly bad for parts like tanks, rcs, etc simply because the mod won't check for failures unless they are being actively used. This is very much a work in progress and these releases are just snapshots when things seem to be stable and working. Any part of it can change at any time. Obviously not suitable for an ongoing career game. If you have never played around with Test Flight and don't mind the rough edges, it's a good chance to see how it plays, without the full experience of RealismOverhaul.

Version 2.0.2 has been release and is now available on CKAN. This version requires KSP 1.12.x and fixes numerous contract issues, improves support for RealAntennas, and also brings things in line with the current version of RP-1 (thanks drhead and Wallum). A couple of important notes: This mod depends on Custom Barn Kit, which is only rated for KSP 1.10.x and looks like it has a bug in science and sandbox mode in 1.12.x that resets KSC buildings back to their lowest level. If you are looking for this mod on CKAN you need to include previous KSP version 1.10 in your install and search. This also means playing sandbox or science may be frustrating. Unfortunately this is the nature of user supported mods. https://github.com/pehvbot/LRTR/releases/tag/v2.0.2

Less Real Test Flight uses and extends the TestFlight failure Mod, and is intended for stock and stock-alike games. Download: https://github.com/pehvbot/LRTF/releases Prereqs: TestFlight, ModuleManager. KSP version 1.12.x Player Tips: LRTF builds on StarStrider42's experimental (and likely abandoned) stock part configs: https://github.com/Starstrider42/TestFlight-Configs If you are unfamiliar with TestFlight, it is a parts failure mod mostly used by RealismOverhaul/RP-1. https://github.com/KSP-RO/TestFlight It has a nice set of features and is insanely configurable, but it comes at the cost of being complex to configure each part. I wanted to use TestFlight but I am far too lazy to actually write configs for every part. I also wanted to extend it a bit by adding in some more recording and failure modes. It turns out being lazy is hard work! Instead of writing TF configurations for each part this mod tries to sort parts into one of several configuration profiles, then makes a few adjustments to the parts as needed, generating the actual TF profiles using modified versions of the StarStrider42 scripts. Currently it configures engines, command parts, fuel tanks, parachutes, rcs, wheels, reaction wheels, parachutes, and antenna. Although it *should* work well enough for most stock-alike mods, it's completely untested and there are almost certainly specific parts that won't work or will be badly configured. It includes the ability to repair LRTF failures, including engine repairs for LRTF configured engines but not TestFlight 'stock' configured engines. My goals: near, far, and blue sky: Near Bug fixes. Always bug fixes Balance the failure rates and curves for the profiles Balance repair probabilities Test RealFuel and Kerbalism support (currently preliminary) Far Real Antenna support Done! FAR support FAR Parachutes are done! RealChute support Done! Support for other parts mods Blue Sky Add somewhat randomized failure rates and curves for each part for each save. This means when you start a new save, each part will have its own failure rate and curve, simulating the fact that you don't always know how smooth development will be nor how good the ultimate product may be. Done! Use TestFlights ability to boost research for part families based on flight data from previous parts. See if this can be done by using manufacturers, engine class (booster, vacuum, solids, etc), etc instead of previous parts Done! The mod doesn't overwrite existing TF profiles, or at least it shouldn't. Give it a shot! What's the worst that can happen?

Kerbalism may be doing this. Select the craft from the Kerbalism window and go to the config tab. Unclick the notification boxes and see if that does it.

The short answer is you don't. Or rather you wait until it's ready. It's a hairy monster of a mod and updating it takes time and effort. The devs work on it when they have the time and it's strictly volunteer work. Some folks have dug through the mod and all it's dependencies to make it work for them, but these are personal efforts and not really distributable. It's frustrating, but it is the nature of user created content.

Procedural Parts and Procedural Wings would solve your craft building problems since you can fairly easily configure it to give you any tank or wing shape you want from the start. You can add all the Structural parts to your start menu using something like: @PART[*]:HAS[#category[Structural]]:FINAL { %TechRequired = start } FINAL is kind of a tricky modifier here since you don't really know how final FINAL is, but this should force to to run after any tech tree mods. You can also use this same trick to throw in all the Aero category parts into the start node.

If you are installing manually check to make sure the planet pack folders are in the right spot and for RSS and KSRSS that you also have the RSS textures.

Good tip, but nothing there either. The parameter is listed and looks good and everything works as expected, except it doesn't pass that specific check. As far as I can tell CC is either not checking at all (and auto failing) or it isn't seeing the two values as being equal for some reason.

I have a question about how PartValidation FILTERs works. I am able to use them for some criteria but not others. Working example vs non-working examples: //This one works fine ... PARAMETER { name = PartValidation type = PartValidation FILTER { MODULE { name = ModuleScienceExperiment experimentID = mobileMaterialsLab } } } //This one matches mobileMaterialsLab doesn't match for totalScienceLevel even though it's defined for the part being checked ... PARAMETER { name = PartValidation type = PartValidation FILTER { MODULE { name = ModuleScienceExperiment experimentID = mobileMaterialsLab //gets defined for different parts with mobileMaterialsLab totalScienceLevel = 1.0 } } } I'm able to work around the problem, but I haven't been able to figure out why some criteria work and some don't. Logs don't seem to offer any insight. Does anyone know what's going on with this?

Yes. Thanks for the heads up. I should know better than to make these changes late at night and in a rush. It should be fixed now. My apologies to anyone who downloaded the wrong file.

For those interested, I've updated Less Real Than Real(ism) to the first 2.0 release. This fixes all kinds of bug, selects the correct settings for Kerbal Construction Time for stock or 2.5x, and adds Kerbalism support for stock and 2.5x size worlds. More info here: In addition to the requirements listed, I strongly suggest using Kronometer, Restock/Restock+, and KSC Switcher. As always, let me know if you run into any bugs, if it doesn't work as expected, etc.

Version 2.0.1 Now with even less realism! This is the first release version of LRTR version 2.0. If you are upgrading from the previous release versions be careful. This will likely break your saved games. It is compatible with and fixes many of the bugs from the beta of 2.0. It adds better support for KCT presets, and generally cleans things up a lot. As with the beta, it only supports KSP 1.12+. Download for v2.0.1 (for KSP 1.12) here: https://github.com/pehvbot/LRTR/releases/tag/v2.0.1.0 (It's still in pre-release until CKAN metadata can be updated) Download KerbalismConfig v1.0 here: https://github.com/pehvbot/LRKerbalism/releases/tag/v1.0.1 (Supports both the 1.11 and 1.12 versions) The new minimum requirements (as with the beta) ModuleManagerClickThroughBlockerCustomBarnKitContractConfiguratorDMagicScienceAnimateMagiCoreModularFlightIntegratorReal Solar System, KSRSS, or KSSRS 2.5x NOTE: RSSDateTime formatter does not currently work in 1.12.x and will likely not be updated until RP-1 is updated to 1.12. There is a pirate version that works in 1.12 here:

Thanks! Everything is scaled by 1.6 linear (2.56 area, ~4 volume) so 1m, 2m, 3m, 4m, 6m, and 9m.

Yep. Click on the settings (gear) icon in the KCT window. You can adjust all the settings there, including disabling it entirely. It's the top button on the middle-right. The only down side is I think it disables crew training as well. NOTE: That version has some serious issues (as expected). I'll post the latest beta today. It should be a drop in replacement since it's basically all bug fixes. It's still a beta so if you find something wonky with it let me know.

BEHOLD THE POWER OF MODULE MANAGER! I kind of liked the idea idea of a Soviet, US split tree and I was bored, so I did just that with a single page of MM scripts. The script takes the stock tree, makes two copies (US and SOVIET) and mirrors them ,then rotates the stock tree so it sits on top (i.e. west is the US, east is the USSR, and on top is the stock tree). It then looks for Bluedog and Tantares parts and moves them to the new trees. The only piece that's missing is that I would like for unlocking either the US or SOVIET node automatically unlocks the stock node. The frustrating thing is I can do it, but it creates a spagettified mess in the R&D building since I can't figure out how to hide the lines going from parent to child (probably needs a DLL to handle this). This isn't really a full mod and is quite brittle. Using anything but the stock tech tree is likely overflow the canvas space and probably create overlaps between the branches. Anyway, you can see how you can manipulate the TechTree using MM.

Start by taking a look at the stock tech tree cfg file in GameData/Squad/Resources/TechTree.cfg. Each node is a specific technology: RDNode { id = start title = #autoLOC_501020 //#autoLOC_501020 = Start description = #autoLOC_501021 //#autoLOC_501021 = The technology we started out with. cost = 0 hideEmpty = False nodeName = node0_start anyToUnlock = False icon = RDicon_start pos = -2568,1199,0 scale = 0.6 } RDNode { id = basicRocketry title = #autoLOC_501022 //#autoLOC_501022 = Basic Rocketry description = #autoLOC_501023 //#autoLOC_501023 = How hard can Rocket Science be anyway? cost = 5 hideEmpty = False nodeName = node1_basicRocketry anyToUnlock = False icon = RDicon_rocketry-basic pos = -2385,1257,0 scale = 0.6 Parent { parentID = start lineFrom = RIGHT lineTo = LEFT } } ... From here you can do one of three things: Change the node, remove the node, add a new node. Notice the second node points backwards to its parent. If you want to make a simple change for example you could make your entire tech tree more expensive (it's a dumb example but it shows how this stuff works). You would create a ModuleManager script (MM is pretty much required for any mods that change game mechanics) @TechTree { @RDNode,* { @cost *= 2 } } @TechTree { @RDNode[survivability] { %cost = 5 } } ModuleManager scripts are a pretty big subject but the basic idea in this example is: Look for the thing called TechTree Look at all the things called RDNode (that's the comma + star part) Multiply the cost in each of these by 2 Look into the TechTree again Look for the RDNode called 'survivability' Set its cost to 5, removing the previous change. Creating a new node is a bit more complicated. You need to place it somewhere on a grid (the pos =... line), make sure it points to it's parent, make sure any children point to it, give it an icon, a cost, etc. You can use examples you find as a template. Once you change the tech tree itself you may then need to change the tech node the parts use. It would look something like: @PART[bluedog_Centaur_Avionics] { %TechRequired = nasa_tech_4 } This takes a Bluedog part and places it into a hypothetical 'NASA' tech tree branch you created so NASA and Soviet (Tantares) parts are researched separately.