Agathorn

See also these posts, though bear i mind they are older: Not a known issue, but certainly shouldn't be happening. Just to be clear, the minor failures existed when you saved? So restoring back to that save should bring the failures back, but they ASO should appear in the window. I added that relatively recently though and i'm not sure it got well tested, so might be a bug. Any chance you could provide this save file?

Hi @CoriW As @Phineas Freak states, that is a bad example because it is just one piece in the massive cog that is RO. It is very clever MM script that takes data we put in other places and builds the findl TF configs for the engines. You could, as stated, install RO, run it, then look at the final MM cache but while that is easy it is probably a real pain for someone who doesn't want to run RO in the first place The documentation you link to ti is mostly up to date, but might be missing some of the newer features. It is a solid base though. That said, it makes mention of the yaml syntax which you may or may not want to do with. The yaml config is an intermediate config that is used to build the final configs in the project. It allowed me to more easily have multiple parts with the same configs without having to duplicate them. But to use the yaml you need to update the yaml file then run the processor to turn them into cfg files, which again you probably don't want to mess with. Instead you can just write the configs straight up and use those. The wiki documentation covers the various properties available on the modules, what they do, and what the modules do. It doesn't cover any pure MM information though so you really need to know what you are doing with configs in general before diving in. Also the RO configs are further confused by the fact that in RO a single engine PART can have multiple configurations, allowing the player to swap between sub models of an engine in runtime. TestFlight has to work with this, so the configs are more complicated in that you will see multiple entries for the same TF module sometimes, one for each config. That said, here is a an example of an ENGINE config. Different parts will be different given what modules they have on them. The `configuration` property in each of these can usually be ignored in Stock. MODULE { name = TestFlightInterop } MODULE { name = TestFlightCore title = LR105-NA-3 configuration = engineConfig = LR105-NA-3:LR105-NA-3 maxData = 10000 techTransferMax = 2000 techTransfer = } MODULE { name = FlightDataRecorder_Engine configuration = LR105-NA-3 flightDataEngineerModifier = 0.4 flightDataMultiplier = 1.93939393939394 } MODULE { name = TestFlightReliability configuration = LR105-NA-3 reliabilityCurve { key = 0 0.000303030303030303 key = 2250 0.000150757575757576 -1.34261974584556E-08 -1.34261974584556E-08 key = 10000 0.0001 0 0 } } MODULE { name = TestFlightReliability_EngineCycle configuration = LR105-NA-3 ratedBurnTime = 330 engineConfig = LR105-NA-3 cycle { key = 0.00 10.00 key = 5.00 1.00 -0.8 0 key = 335 1 0 0 key = 500 100 0 0 } } MODULE { name = TestFlightFailure_ShutdownEngine configuration = LR105-NA-3 duFail = 100 weight = 32 failureType = software failureTitle = Engine Shutdown duRepair = 50 severity = major REPAIR { canBeRepairedInFlight = True dataSize = 1 dataScale = 1 repairChance = 75 canBeRepairedOnSplashed = True canBeRepairedByRemote = True } } MODULE { name = TestFlightFailure_IgnitionFail configuration = LR105-NA-3 restoreIgnitionCharge = False duFail = 300 oneShot = True failureType = mechanical failureTitle = Failed to ignite additionalFailureChance = 0.2 ignorePressureOnPad = True severity = major 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 } baseIgnitionChance { key = 0 0.89 key = 2250 0.95 5.29032258064516E-06 5.29032258064516E-06 key = 10000 0.97 0 0 } } MODULE { name = TestFlightFailure_ReducedMaxThrust oneShot = True configuration = LR105-NA-3 duFail = 100 weight = 8 failureType = mechanical failureTitle = Loss of Thrust duRepair = 250 severity = minor REPAIR { canBeRepairedInFlight = False canBeRepairedOnSplashed = False canBeRepairedByRemote = False repairChance = 75 } } MODULE { name = TestFlightFailure_EnginePerformanceLoss oneShot = True configuration = LR105-NA-3 duFail = 100 weight = 16 failureType = mechanical failureTitle = Performance Loss duRepair = 250 severity = minor ispMultiplier = 0.5 ispMultiplierJitter = 0.1 REPAIR { canBeRepairedInFlight = False canBeRepairedOnSplashed = False canBeRepairedByRemote = False repairChance = 75 } } MODULE { name = TestFlightFailure_Explode configuration = LR105-NA-3 failureTitle = Explosion! duFail = 400 weight = 2 failureType = mechanical severity = major } Now to quickly address the batteries. Why did they fail? The stock configs I did have no special configs for batteries IIRC. Most likely they are simply getting picked up as "tanks" that hold electrical charge. Further mode I think those configs were written before I added the ability for parts to have super low failure rates more conducive to missions that last for years. I'm not sure if it documented on the wiki but on the TestFlightCore module you can add a property `failureRateModifier` which is a multiplier against the base failure rate of the part. It defaults to 1, and thus no change. But if you set it to something smaller than 1, like 0.5 for example, then the effective base failure rate of the part will be half what the config states it is, and you can go even lower if needed.

Getting the same NRE and in my case it is causing the parts to not initialize properly in some cases, which is causing RCS FX to play in the VAB. Removing CLS fixes it.

A couple of things here I want to mention, even though you have decided not to use TestFlight at this time. 1) The toolbar duplication is only an issue in the latest DEV release, which is a beta release. Use the latest full release (IE not beta) and you won't have that issue. 2) Based on the fact that you have batteries exploding, I am going to guess you are playing Stock. Sadly the stock configs for TestFlight are pretty crap, and more sadly are going to remain there until a Stock player steps up and does better ones. I play RealismOverhaul so that is where my attention ts focused. Sorry you had this issue though!

Is there any way to rebind the Numpad controls to use other keys for those of us without numpads?

Thanks! Just didn't want to see your work get pulled due to missing source (it's a requirement)

It is? I see your patch'ed version, but I didn't see any source code in it unless I just missed it.

Hi thanks for doing this. Can you post your updated source code please? Thanks!

Thanks @Diazo for the config change! One step closer to being able to load from cache and save 15 minutes each starts up

Ok that makes a sort of sense. Currently I use that event to know when the toolbar is going away on a scene change, so I can remove the button and avoid duplicates. But I can see how that could be causing an issue. I will see if I can refactor things but I need to do some testing first to get a better feel for when the various events fire.

Well I don't see what I can do from my side. I'm adding the button just like normal, the proper way as far as I know. Why would your mod be killing my icon?

Hi there, I am on a mission to stop mods from trampling the MM cache, and this mod is on my list I love this mod, but it appears to save settings into a config file in the wrong place, which means every time that file gets changed, MM has to do a full rebuild and can't load from cache. Would it be possible please to move the config file for this mod into a "PluginData" directory so that it will be properly ignored by MM? Thanks!

Hey Diazo, Would it be possible to move your config file into a PluginData directory so that it is ignored by MM and thus doesn't thrash the cache? Thanks!

Hi there, I am on a mission to stop mods from trampling the MM cache, and this mod is on my list I love this mod, but it appears to save settings into a config file in the wrong place, which means every time that file gets changed, MM has to do a full rebuild and can't load from cache. Would it be possible please to move the config file for this mod into a "PluginData" directory so that it will be properly ignored by MM? Thanks!

I seem to be having a bit of a problem with this mod, and I don't know if it's because I am being stupid or what. Can I ask please how this mod is supposed to to operate? I click the icon and nothing happens, yet I know there is science to be gathered. Other time, it just automatically pops up the science window and I can click the transmit, sometimes it doesn't. Like I can't find any consistency to how it works. So what is the proper method of using this mod?

It is being looked at. Just working to find the best overall way to deal with the issue rather than hacky hack.

FYI TestFlight is available for KSP 1.1.X, I just haven't yet updated this thread. You can find TestFlight 1.6 on GitHub releases which does support KSP 1.1.2. I'll get this thread updated...soon. I hope.

Ug how very KSP Better to simply have a method that returns the X desired largest units.

Honestly if you wait, you will always be waiting. RO is *years* in the making and basically a perpetual project. 1.1.2 in general makes things better because you can run x64 and not be pushing up against the memory issues we've constantly had to deal with.

If all your parts are non-rp0 then it sounds like you installed incorrectly. Make sure you download from the releases page NOT the repo itself. Look in your GameData/RP0 folder. Is there a tree.cfg file?

This has no dependancies. It was written for RSS but can be used without if desired. Bear in mind it does expect time to be in Earth time though, and dates are based on a epoch of 1/1/1950 at the moment, though that will probably be moved into a config later.

I've submitted a NETKAN to the CKAN guys, so assuming I didn't mess it up somehow, this should be showing up on CKAN soon.

Eventually. I need to get around to setting up the NETKAN stuff, which I will probably do at the same time I set up the automated release system. Needs AVC as well.

Currently the date format uses whatever your defined 'locale' is in your operating system. In the future I am considering building an options UI to allow for manual control over these things, but that probably won't come for a bit.

RSS DateTime Formatter This is a very basic mod with one function, to replace the stock KSP displays of times and dates with an approach better suited for RSS players. This includes things like showing calendar dates rather than awkward formats like "Year 5, Day 200". License: CC-BY-NC-SA Source Code: https://github.com/KSP-RO/RSSTimeFormatter Latest Release: https://github.com/KSP-RO/RSSTimeFormatter/releases/latest