[1.2.2] TestFlight - v1.8.0 - 01 May 2017 - Bring Flight Testing to KSP!

[diomedea]

Nothing jumps out at me as bad in there. And you've done a good job of noting the differences between versions. One thing I would note is that you should have a "scope = default" reliabilityCurve. That was added after and its basically a fallback and TestFlight can't otherwise find a matching curve. Also TextFlightReliability_EngineCycle no longer needs to have a reliabilityCurve.

Definitely yes. I appreciate the idea of the "default" scope, and my configs will certainly have a section with that.

Thanks about the "TextFlightReliability_EngineCycle", I was still wondering why that worked both with and without the reliabilityCurve data.

That said, those should have nothing to do with the NRE, so its most likely something else. Is it spamming it in the logs, or is it just every now and then? Might be a benign error due to order to things starting up.

I had the section with the NRE to appear in groups of 4 in the log, so not really spamming, but an event while entering flight. Believe the number matches some parts, so could be dependent on the craft used. Have to conduct more tests. Wouldn't be surprised if such NREs were indeed benign, and could just disappear when all parts in a vessel are matched to a TestFlight config. So, I'd like to provide more info when tests show further evidence.

That is certainly odd. So you are saying that if you take the configs from the last Stock version to be released during dev that none of the parts are recognized?

Yes. Odd for me as well, but that is exactly that. I can notice newer config files to be rather "scrambled" (e.g. the FlightDataRecorder module in the end, and TestFlightReliability_EngineCycle defined before the TestFlightReliability proper module), so those are some possible causes (to me) for the oddity of newer files not working. Have not scanned the add-on code, just what written on the dev thread, so my knowledge of things is still pretty scarce.

Of course sorting this issue comes first to me, as I need a solid template before filling data.

EDIT: a piece of info I'd like to find, but couldn't, is about what could be valid for a "scope". "Default", "Kerbin_atmosphere", "Kerbin_space" are those I can find. Would "Jool_atmosphere" work too? Could something like "anything_atmosphere" as well? With other parts (wheels, e.g) an interesting scope could be "Mun_landed", may that be valid too?

Edited February 14, 2015 by diomedea

[Agathorn]

EDIT: a piece of info I'd like to find, but couldn't, is about what could be valid for a "scope". "Default", "Kerbin_atmosphere", "Kerbin_space" are those I can find. Would "Jool_atmosphere" work too? Could something like "anything_atmosphere" as well? With other parts (wheels, e.g) an interesting scope could be "Mun_landed", may that be valid too?

Currently there is *_atmosphere and *_space, as well as a generic "deep_space" that kicks in over a certain extremely high altitude (I forget what it is). You are right though some sort of landed scope might be nice, but I hadn't considered it originally. I'm such a rocket guy

[diomedea]

Agathorn, maybe what shows in the log when I use the Squad_Engines.cfg from TestFlight version 0.4.6.2 (and doesn't show when instead use configs from 0.4.0.e7) could hint at the cause for parts not being recognized.

The whole log is here, what follows is an abstract of it that shows a number of times during loading:

[ModuleManager] Applying node TestFlight/Squad_Engines/@PART

[*]:HAS[@MODULE[ModuleEngines]:HAS[@PROPELLANT[LiquidFuel]]]:FINAL to Squad/Parts/Engine/jetEngineBasic/jetEngineBasic/JetEngine

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

[ModuleManager] Exception while processing node : TestFlight/Squad_Engines/@PART

[*]:HAS[@MODULE[ModuleEngines]:HAS[@PROPELLANT[LiquidFuel]]]:FINAL

System.IndexOutOfRangeException: Array index is out of range.

at ModuleManager.MMPatchLoader.ProcessVariableSearch (System.String value, .ConfigNode node) [0x00000] in <filename unknown>:0

at ModuleManager.MMPatchLoader.ModifyNode (.ConfigNode original, .ConfigNode mod) [0x00000] in <filename unknown>:0

at ModuleManager.MMPatchLoader.ModifyNode (.ConfigNode original, .ConfigNode mod) [0x00000] in <filename unknown>:0

at ModuleManager.MMPatchLoader+<ApplyPatch>c__Iterator1.MoveNext () [0x00000] in <filename unknown>:0

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

and here an abstract of the log showing what appears while entering fligth:

[Part]: PartModule TestFlightCore at liquidEngine, index 4: index exceeds module count as defined in cfg.

Looking for TestFlightCore in other indices...

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

...no TestFlightCore module found on part definition. Skipping...

and the same repeats for all other modules, obviously as all those were not loaded by MM for the exception above.

[Agathorn]

Are you trying both CFGs from the same saved game? If so, try a brand new fresh save with the 0.4.6.2 configs. During development I often found issues when I made large changes and still tried to use the same saved game. The error you are seeing is very similar to the issues I was seeing. The problem is if KSP detects ANY changes in the part modules loaded vs what was saved on the craft, it attempts to rebuild the craft with the new part modules, and often fails to do so properly causing some part modules to be dropped. When I was having this problem, several of the TestFlight modules were being dropped causing it to break. Starting a new saved game and rebuilding my craft fixed it.

Since that is an easy thing to check try that first. Just use the 0.4.6.2 stock configs on a fresh saved game and see what happens.

As for the ModuleManager error above that does look interesting, so i'll take a look. I've tracked down the NRE you reported earlier. It is indeed benign, just some things happening before others are started up, but I put in a possible fix for next release.

[diomedea]

Are you trying both CFGs from the same saved game? If so, try a brand new fresh save with the 0.4.6.2 configs

...

You're right, I was using the same savegame while switching configs. Did another test with only the config files from 0.4.6.2 and a brand new game, (output_log.txt here), and the first Exception above (tied to MM) still shows, not the second as (IMHO) the craft parts effectively are missing the TestFlight modules.

[Agathorn]

You're right, I was using the same savegame while switching configs. Did another test with only the config files from 0.4.6.2 and a brand new game, (output_log.txt here), and the first Exception above (tied to MM) still shows, not the second as (IMHO) the craft parts effectively are missing the TestFlight modules.

OK the problem with the 0.4.6.2 configs is the "configuration =" line. In a few places there is a blank configuration line which is breaking MM. Just delete those lines and it will work fine.

[diomedea]

OK the problem with the 0.4.6.2 configs is the "configuration =" line. In a few places there is a blank configuration line which is breaking MM. Just delete those lines and it will work fine.

Nice, tested after removing that line, and all works (and sure no more exception logged). Issue Scratched .

Question. I see "du" gained under one scope have no effect with other scopes (intended for what I guess). That means parts abruptly change MTBF due to du change when transitioning from one scope to another, e.g. from X_atmosphere to X_space. But the transition is effectively smooth in reality. Even more smooth would be a transition from X_space to Y_space (changing SoI), but the amount of du gained while in space can be pretty high so the change is really sharp in TestFlight (of course, if both X_space and Y_space are defined, though one may be substituted with the "default" scope).

Can't see if a mechanic to address smooth changes in scope is already present. If not, I would allow some "transfer" of du to adjacent scopes (similar to what exists for similar parts). Or, would try a different approach, e.g. from atmosphere to space as a function of current altitude, or of pressure; from one to another SoI based on distance and ratio of the bodies GM (gravitational parameter).

[Agathorn]

Hey all just a quick update on "Why so long till another version!?"

I've been working on a fairly comprehensive revamp of how parts get attached inside TestFlight which will open the doors for seamless interoperability with other mods that implement "dynamic" parts, such as RealFuels, Procedural Parts, TweakScale, etc. This has taken a lot of work and a lot of testing, but I think I can see the finish line ahead. In addition however, due to these changes, I need to coordinate the next release along with a release of RealFuels so that existing functionality isn't lost.

So good stuff is coming, soon, I just don't know exactly when yet. It will be worth the wait though!

[lextacy]

Hey all just a quick update on "Why so long till another version!?"

I've been working on a fairly comprehensive revamp of how parts get attached inside TestFlight which will open the doors for seamless interoperability with other mods that implement "dynamic" parts, such as RealFuels, Procedural Parts, TweakScale, etc. This has taken a lot of work and a lot of testing, but I think I can see the finish line ahead. In addition however, due to these changes, I need to coordinate the next release along with a release of RealFuels so that existing functionality isn't lost.

So good stuff is coming, soon, I just don't know exactly when yet. It will be worth the wait though!

I hope youll give these recommendations a shot for next release?

1. Can you turn down the failure rates? I dont like the rates as you have them set for a 1% failure chance per second of engine fire. I think to be parallel to real world MTBF its around .5 % per minute of engine fire.

2. Give us the option to have only 1 scope? I dont like the idea that Duna or Mun space is all the sudden deadly to engines that have been tested.

[Agathorn]

I hope youll give these recommendations a shot for next release?

1. Can you turn down the failure rates? I dont like the rates as you have them set for a 1% failure chance per second of engine fire. I think to be parallel to real world MTBF its around .5 % per minute of engine fire.

2. Give us the option to have only 1 scope? I dont like the idea that Duna or Mun space is all the sudden deadly to engines that have been tested.

1. Failure rates are unique per engine and all based on extensive research into their real world counterparts. I'm very hesitant to change anything without good reference to show I have it wrong. In most cases the failure rate is far below even 0.5% chance per second.

2. This would take a very extensive overhaul to achieve, and really goes against the entire point. If there was only one scope, then you would just run it on the engine stand until its good and call it a day. What's the point then?

[lextacy]

2. This would take a very extensive overhaul to achieve, and really goes against the entire point. If there was only one scope, then you would just run it on the engine stand until its good and call it a day. What's the point then?

I really dont agree with that, no offence. Do you think NASA runs out to Mars real quick and constructs an engine testing facility then runs some static fire on the old SSME for the upcoming SLS vehicles? Or does Elon Musk hop on over to the moon and have the Super Dracos tested on a rack before ever thinking of going to the moon with them? Thats creates a catch 22 paradox for the purposes of testing. For the most part engine reliability is in terms of atmospheric testing because thats the harshest of environments for an engine. Its also the time the engine works at its hardest due to lower surface TWR. I feel this could be a great mod if you would see an open mind on this. This mod could even be injected into the stock game if done with care. Right now im finding my self babysitting the code to death just to keep engines from blowing a gasket. I thought the idea of a mod was to have some fun with it rather than writing a 1000 line config to actually use it? I pray that this mod can improve.

Nasa's very own Charles Bolden , chief of operations has a famous quote, "But if it has an engine on it, nothing goes to space without going through Mississippi."

[Agathorn]

I really dont agree with that, no offence. Do you think NASA runs out to Mars real quick and constructs an engine testing facility then runs some static fire on the old SSME for the upcoming SLS vehicles? Or does Elon Musk hop on over to the moon and have the Super Dracos tested on a rack before ever thinking of going to the moon with them? Thats creates a catch 22 paradox for the purposes of testing. For the most part engine reliability is in terms of atmospheric testing because thats the harshest of environments for an engine. Its also the time the engine works at its hardest due to lower surface TWR. I feel this could be a great mod if you would see an open mind on this. This mod could even be injected into the stock game if done with care. Right now im finding my self babysitting the code to death just to keep engines from blowing a gasket. I thought the idea of a mod was to have some fun with it rather than writing a 1000 line config to actually use it? I pray that this mod can improve.

Nasa's very own Charles Bolden , chief of operations has a famous quote, "But if it has an engine on it, nothing goes to space without going through Mississippi."

No it isn't real, but its hard to simulate reality of this depth in KSP. In real life engines and other parts are engineered using knowledge gained by observation, probes, and experiments, etc. We don't really have that in KSP. Originally it was expected that KCT was going to integrate into TestFlight and then you could do sims on other planets and gain at least some data that way, but that hasn't panned out yet.

Its a balance between making the system trivial and making it too hard. If you only have one scope, then you will max out your reliability very quickly, and then what? Already most of the 1965+ engines has failure rates so low they're are pretty unlikely to fail. As is real of course.

That said, I will think on this a a bit. Whether *I* it or not, the fact still remains that it isn't a trivial thing to change, as scopes are about as low level in the code as you can get. I *think* I can make them configurable, but I need to think about it and make sure I do it right.

[lextacy]

No it isn't real, but its hard to simulate reality of this depth in KSP. In real life engines and other parts are engineered using knowledge gained by observation, probes, and experiments, etc. We don't really have that in KSP. Originally it was expected that KCT was going to integrate into TestFlight and then you could do sims on other planets and gain at least some data that way, but that hasn't panned out yet.

Its a balance between making the system trivial and making it too hard. If you only have one scope, then you will max out your reliability very quickly, and then what? Already most of the 1965+ engines has failure rates so low they're are pretty unlikely to fail. As is real of course.

That said, I will think on this a a bit. Whether *I* it or not, the fact still remains that it isn't a trivial thing to change, as scopes are about as low level in the code as you can get. I *think* I can make them configurable, but I need to think about it and make sure I do it right.

I can only hope ! Hey I did come up with some sort of alternative solution you could use. I do agree with you and that we shouldn’t max out reliability on the testing racks. Is it possible to make a global scope , but base it off a exponential curve ? You can test your engine to a 97% max reliabilty on the ground for say 10,000 units, but you have to take flights to achieve the remaining 2.5% ? And we can leave .5 % as a final cut off point for reliability. And the kicker is you have to take LOTS of flights to get that 2.5% gain. Maybe hmmm 300,000 units? Just a thought

[Subcidal]

No it isn't real, but its hard to simulate reality of this depth in KSP. In real life engines and other parts are engineered using knowledge gained by observation, probes, and experiments, etc. We don't really have that in KSP. Originally it was expected that KCT was going to integrate into TestFlight and then you could do sims on other planets and gain at least some data that way, but that hasn't panned out yet.

Its a balance between making the system trivial and making it too hard. If you only have one scope, then you will max out your reliability very quickly, and then what? Already most of the 1965+ engines has failure rates so low they're are pretty unlikely to fail. As is real of course.

That said, I will think on this a a bit. Whether *I* it or not, the fact still remains that it isn't a trivial thing to change, as scopes are about as low level in the code as you can get. I *think* I can make them configurable, but I need to think about it and make sure I do it right.

Personally I agree with him on the scopes, Seems silly to have to do it over and over again. It just turns into a grind after a certain point. As for maxing out your reliability very quickly with one scope, That's where you need to let the tech tree do it's job in limiting the types of engines you have. Then lower tier engines are more reliable until you pretty much max out your tech tree, at which point all engines should be fairly reliable anyways, because you're in the end game (if you're using a decent tech tree, stock doesn't really do this all that well....)

[Agathorn]

Next version will allow you to use a single scope for everything. I still want to make them actually configurable, but for now enabling an option to simply use a single scope is doable.

- - - Updated - - -

I can only hope ! Hey I did come up with some sort of alternative solution you could use. I do agree with you and that we shouldn’t max out reliability on the testing racks. Is it possible to make a global scope , but base it off a exponential curve ? You can test your engine to a 97% max reliabilty on the ground for say 10,000 units, but you have to take flights to achieve the remaining 2.5% ? And we can leave .5 % as a final cut off point for reliability. And the kicker is you have to take LOTS of flights to get that 2.5% gain. Maybe hmmm 300,000 units? Just a thought

You can define the curves as anything so yeah you could do that. Right now they aren't that severe though, and they all max out at 10,000 data units.

- - - Updated - - -

Personally I agree with him on the scopes, Seems silly to have to do it over and over again. It just turns into a grind after a certain point. As for maxing out your reliability very quickly with one scope, That's where you need to let the tech tree do it's job in limiting the types of engines you have. Then lower tier engines are more reliable until you pretty much max out your tech tree, at which point all engines should be fairly reliable anyways, because you're in the end game (if you're using a decent tech tree, stock doesn't really do this all that well....)

I was more referring to just maxing out a single engine. You are right though that there is an overall progression with later tech engines being more reliable, and that is already done. If you play through RP-0 with the TestFlight supported engines you will see a progression in reliability.

[Subcidal]

If you play through RP-0 with the TestFlight supported engines you will see a progression in reliability.

Actually kind of waiting on you to release the next version so i can see if I can make a config for normal KSP, Speaking of which your last alpha (beta?) release had a stock .cfg with it, Is it fairly safe to copy and paste that as a start? Or is it outdated?

[lextacy]

YAY! i thank you many times!

[karamazovnew]

KCT simulations should be regarded as a "software simulation". Thus, no parts should fail during simulations, and no test data should be given for such flights. Anyway, I love the idea of this mod, but could you intergrate it with other damage mods like Dang It?

[Agathorn]

Actually kind of waiting on you to release the next version so i can see if I can make a config for normal KSP, Speaking of which your last alpha (beta?) release had a stock .cfg with it, Is it fairly safe to copy and paste that as a start? Or is it outdated?

Yes, though they will lack some of the newer features they should work just fine with one fix. You need to delete all the empty "configuration =" lines as they will break ModuleManager

- - - Updated - - -

KCT simulations should be regarded as a "software simulation". Thus, no parts should fail during simulations, and no test data should be given for such flights. Anyway, I love the idea of this mod, but could you intergrate it with other damage mods like Dang It?

Integration with KCT requires work on their side unfortunately. I've provided an interface to make it possible, just waiting on magico13 to have the free time to do it.

As for integration with DangIt it honestly makes no sense to me to do that, or even how you would envision such a thing happening? We both do similar things in completely opposite ways.

[Agathorn]

*Hoping* for a release tomorrow. If possible. Sorry for the delay but it is difficult coordinating the multitude of mods that all need to be released at once for this. RO, RP-0, RF, and TF all need to release at the same time for this next release

[Agathorn]

Release 1.2 (v1.2.0.0)

https://github.com/jwvanderbeck/TestFlight/releases/tag/1.2.0.0

Highlights

This version of TestFlight includes some major changes including a brand new Interop API that allows mods that have dynamic parts to work with TestFlight. In addition there are many config changes to sync up with the latest versions of Realism Overhaul and RP-0.

**VERY IMPORTANT:** If you use RealFuels, RealismOverhaul, or RP-0 you **will** need to get the latest versions of those mods, being released in sync with this version of TestFlight, to ensure continued proper operation. If you do not, TestFlight will not properly attach to parts.

Change Log

•

If using RealFuels, this release requires RF version 8.4 or higher

•

If using Realism Overhaul, this release requires RO version 8.1.0 or higher

• New Interop API allows mods that make dynamic parts, such as RealFuels and Procedural Parts, to connect with TestFlight and provide data that identifies parts by those dynamic properties.

• Totally reworked configs pre-processor makes it easier to update and add new part configs

• New Query System allows for far more control in configs as to what modules apply to what

• Support for failure modules to operate on specific engines in a part when a part has more than one engine module.

• You can now see the rated burn time on engines in the VAB

• Fixed some benign NREs

• Possible fix for the TestFlight MSD sometimes going blank and taking half the UI with it for a few seconds

• Updates to several engine configs including LR-89, LR-105, and AJ10 series engines to match current configs in RealismOverhaul/RP-0

• Fixed a bug that sometimes prevented TestFlight from properly determining state change of an engine from NOT_IGNITED to IGNITED

• Fix bug in settings window where your last view settings page was not properly restored upon loading the window

• EngineModuleWrapper and all Engine based Failure Modules now support two ways of addressing specific ModuleEngines and ModuleEnginesFX on a part; Index and engineID

• Added new Difficulty Setting to make all parts operate under a Single Scope rather than distinct scopes based on craft location & situation

• If a part uses the TestFlightReliability_Engine module, the rated burn time for the engine as well as the burn through time and penalty is now listed in the part's "Info" window in the VAB.

• New part aliasing feature allows configs to change without loss of flight data in most cases. Also allows multiple parts to be treated as the same part.

[Agathorn]

Hey all. Apparently i'm a total moron and when I released 1.2, I forgot to update the mod on KerbalStuff. If you downloaded it from Github you are good, but if you downloaded form KerbalStuff then you got the old 1.1 version. So sorry! I have updated KerbalStuff now, and it should be good.

[Eagle21221]

Just wondering what you would think about adding a feature that with time and experience points would allow you to upgrade isp, thrust, maybe gimble, alternator, energy storage, solar panel efficiency?

[Agathorn]

Just wondering what you would think about adding a feature that with time and experience points would allow you to upgrade isp, thrust, maybe gimble, alternator, energy storage, solar panel efficiency?

Rather outside the scope of this mod I think.

[undercoveryankee]

Just wondering what you would think about adding a feature that with time and experience points would allow you to upgrade isp, thrust, maybe gimble, alternator, energy storage, solar panel efficiency?

If RealFuels is present, most engines will have a choice of RF tech levels, and better versions will be available as you enable more tech levels through the tech tree. I could see requiring a minimum level of testing before an engine could be deployed at the highest unlocked tech level, or even giving a very-well-tested engine early access to the next tech level.

But the obvious way to do that would require RealFuels to know about TestFlight, and that would have the potential to annoy people who want to use RF without TestFlight. Probably better to keep reliability and performance separate, maybe with some way to turn surplus flight data into science once a part has reached its max reliability.