TestFlight integration?

[magico13]

I wonder if this would be worth looking into. The TestFlight mod appears to be a part failure mod that has increasing reliability with more use, in specific locations (atmosphere vs space around X).

Simulations could tie in to this, so that time spent in simulation can be applied to enhance reliability (at a reduced rate, or with a maximum), and simulations could be purchased that have 100% reliability for "ideal situation" testing.

Edit: Thought of some more: Limiting the available failure pathways for a particular part (assuming there's more than one failure mode) to only known ones would be pretty cool. Same with the ability to force a failure, for testing abort operations.

Those are just some of the ideas I had. Please feel free to add your own!

[jwvanderbeck]

The first thing that comes to mind for handling reliability in a sim is something like this.

1. KCT starts the sim, and at sim start gets the current FlightData on all parts on the craft from the TestFlight API and stores this somewhere.
2. The sim runs.
3. At the end of the sim, but before reversion, KCT again gets the current FlightData on all parts.
4. KCT notes the difference, giving the total amount of FlightData on each part in each scope (atmosphere, spec, etc).
5. Game reverts to before sim
6. KCT calls TestFlight's API to add back in the FlightData from the sim, optionally modifying the amount of FlightData based on internal KCT logic.

Optionall KCT could also keep track of FlightData gained in sims internally and cap out per part FlightData at a certain level.

Most of this is currently doable in the TestFlight API and some is not, but it is trivial to expand the API to cover it.

[magico13]

Seems simple enough. The logic's mostly on KCT's side, but that's fine by me (but might have issues if you change anything too drastically).

To make my life easier, can there be API options to turn off breakdowns and to trigger a failure? Though the triggering a failure might be something you'd rather handle entirely on your side (so people can perform their own "simulations" using the stock revert buttons without KCT).

I can easily add logic on KCT's side, but it probably makes sense for us to agree on any reductions/limitations I put on it. The current, totally trivial and untested, idea in my mind is capping the maximum reliability you can get to to 75% and cutting the amount you gain in half or more. That way you still get some improvement, but the real flights are where you get the most data. Also, with KCT simulations you can quickly spend a lot of time in orbit around Eeloo if you wanted, which you can't do in the stock game (since you'd need a launcher and travel time).

The total time spent in simulations, including reverting to the beginning, should probably be factored in instead of just the time of the last simulation. I realize that's not what the base mod does with regards to flight reverts but that data is "realistically" not lost when you restart a simulation. Perhaps a better solution is to keep the data acquired from the longest simulation in a particular session, especially since you only pay a one-time fee per session.

[jwvanderbeck]

Yes adding API methods to enable/disable failures or trigger them is doable, as i'm sure a lot more is once I sit down and spend some time thinking on it.

Unfortunately right now i'm dealing with a major bug from KSP spinning up multiple instances of my scenario so all my brain power is on that right now :)

I'll loop back to this once i've fixed this current issue though I promise.

[jwvanderbeck]

As a quick update on this, I have written a first draft of the Public API for TestFlight on my project's Wiki: https://github.com/jwvanderbeck/TestFlight/wiki/TestFlight-API-Reference-Documentation

A lot of this API already exists, but I have completely wrapped the whole thing in a Reflection capable API as well. That is in GitHub now and will be part of the next experimental release.

[jwvanderbeck]

Hi magico13. I have added some more API methods to the interface specifically for you :) I think all of this is doable now, and I will be posting some example code today, also please don't hesitate to riddle me with questions. You can reach me quickest on IRC if you have it, I'm always in the #RO channel, or you can PM me on the forums, or of course here as well.

I linked the documentation in my previous comment. I'm going to work on expanding that today as well as adding in some code examples.

I can easily add logic on KCT's side, but it probably makes sense for us to agree on any reductions/limitations I put on it. The current, totally trivial and untested, idea in my mind is capping the maximum reliability you can get to to 75% and cutting the amount you gain in half or more. That way you still get some improvement, but the real flights are where you get the most data. Also, with KCT simulations you can quickly spend a lot of time in orbit around Eeloo if you wanted, which you can't do in the stock game (since you'd need a launcher and travel time).

Ok so on this. Unfortunately reliability isn't a direct thing, but rather a function of Failure Rate. You really have no direct control over it, so what I would recommend is limiting the total amount of Flight Data that can be accumulated in total over all situations, and limiting the rate at which Flight Data is accumulated during a session. Also what do you think about maybe tying these values to R&D upgrades in KCT? Maybe you can apply upgrade points to allow you to retain more data, or up the maximum?

To make my life easier, can there be API options to turn off breakdowns and to trigger a failure? Though the triggering a failure might be something you'd rather handle entirely on your side (so people can perform their own "simulations" using the stock revert buttons without KCT).

I have added methods to the API that allow you to Enable or Disable specific failures, as well as to trigger specific ones at will.

[magico13]

Awesome, thank you! I'll look into this a bit later and will let you know if I have any questions. The first release to incorporate any of this will do so in a fairly basic way, likely just allowing a reduced amount of flight data recorded. I can definitely tie that into the upgrade system pretty easily.

I'll be honest, my desire to work on KCT has been reduced as of late due to some as of yet secret news, so it might be a while before anything gets put in and tested.

[jwvanderbeck]

I've added samples of using the Interface, as a new project on GitHub. Here is a link to the sample Reflection interface: https://github.com/jwvanderbeck/TestFlightAddon/blob/master/TFReflectionInterfaceExample.cs

I don't know if you have used Reflection or not, its a real nasty piece of work but I have tried to make it as easy as possible by providing a more convenient static wrapper around most of my internal API.

I'll be honest, my desire to work on KCT has been reduced as of late due to some as of yet secret news, so it might be a while before anything gets put in and tested.

Sad news indeed, as I'm sure many like me can't even imagine playing KSP without KCT.

If there is anything I can do to help with the integration just let me know. If I was more familiar with your code base I would just submit a PR, but I would have to spend some time getting a feel for the flow first.

I would however like to get TestFlight out of WIP soon, so hopefully we can get this working before then :)

[magico13]

Ok, I'll try to play around with this during this week, but don't feel like you need to hold off on a release just for KCT.

KCT's code base is a bit of a nightmare at the moment, so I don't expect you to try to learn it at all. I was working on a rewrite recently to make it much more straightforward, but that project got... shifted... The Kerbal Construction Time project as a whole is still being worked on, for sure, but the current version of it is in a bit of stagnation. I am planning at least one more update though, which is part of the way through completion. I'll try to add this stuff into it as well.

E: Also, I've used reflection somewhat, but never for anything too intense. Luckily I shouldn't need to access too much from TestFlight for some basic integration.

[jwvanderbeck]

Just a note -- the code in GitHub right now under the "mtbf" branch is up to date with the latest API changes. However the currently released Experimental does not have them. I will be pushing another update here in a few minutes, which will be v0.4.0e7, and that will have the latest changes.

[magico13]

Ok. I'll be at work for the next 7 hours or so, so take your time. I've got other half-finished things to work on anyway, so I might not be able to get to this today. Thanks for the heads up though, since that might have been an issue otherwise.

[jwvanderbeck]

No worries just wanted to make sure. The new release is out now: https://github.com/jwvanderbeck/TestFlight/releases/tag/v0.4.0e7

[NathanKell]

As a, shall we say, interested party, just wondering if the secret news is you-related or KSP-related...

[fingerboxes]

@NathanKell - A KCT rewrite/successor is going to be showing up in the relatively near future, is the short version. Figured out a few ways to do things better technically, but integrating them into the existing codebase would be... really interesting. Not really ready to talk about it too much, yet, beyond that.

[magico13]

As @fingerboxes stated (enneract on the forums), the secret news is that there's a rewrite being done and I'm not the main developer due to time issues (damn you PhD program!) So I'm not particularly motivated to make big changes to the current code base. We'll have more info when it gets further along, but in short it is a very good thing for the KCT project in general. It'll be much better on the other side.

[NathanKell]

Ah, I see. Thanks for the info! I'll keep mum. :)

[jwvanderbeck]

Hey @magico13 or @fingerboxes , I just wanted to pop in here and see if you guys had a chance to look over the TestFlight API at all, and if so if you have found any deficiencies that I might address.

[magico13]

Sorry, I haven't gotten a chance to yet :(

[magico13]

I feel like I should probably post the progress I had today with this, even though the most interested parties already know about it.

In the latest dev version I added the ability to enable/disable part failures during simulations. Really basic, but potentially the most directly useful thing planned. Eventually this will have to go into HoloDeck when KCT switches over to that for simulations.

An idea for @jwvanderbeck or @fingerboxes (not sure who should do it) might be to have a window or something where people can 1) choose which failures to disable, and 2) force a particular failure (unless you can do that already in TestFlight). I can imagine situations where people will use HoloDeck to try to test various failure situations (a timer or other trigger might be fun, so you could have your engines explode at 5km to test your escape system, for instance). Might make more sense as a TestFlight feature that's available during simulations (and maybe through a debug menu outside of simulations?)

I'll likely play around with TestFlight integration some more so that it's just a matter of porting things to HoloDeck when the time comes, rather than trying to figure things out all at once.

[jwvanderbeck]

I agree on choosing failures both to disable and to trigger, though I was hoping that would happen on your side or the sims side in the case of HoloDeck. There are API methods to do that as you've seen.

Also a note on the concept of letting some data be gained and kept during a sim, there are methods in the API setup for you to do this, see these: https://github.com/jwvanderbeck/TestFlight/blob/dev/TestFlightCore/TestFlightCore/TestFlightInterface.cs#L231 and https://github.com/jwvanderbeck/TestFlight/blob/dev/TestFlightCore/TestFlightCore/TestFlightInterface.cs#L239

Both are float percents (0 being 0%, 1 being 100%)

[magico13]

Awesome, I'll have a play with those tomorrow maybe. I've got some other things I'm working on at the moment.

As for the options for triggering, I'd imagine it'd be easy to add to whatever GUI controls what to disable. I'll leave that up to fingerboxes to think about. I imagine that's a later concern for HoloDeck, since it's still missing some of the more core mechanics. If @fingerboxes wants me to come up with some methods for handling that, I can, and then he can add the GUI later without having to worry about all the API calls?

I suppose there's a question of how general it should be. You could either disable and trigger on a per-part basis, which allows a lot of control but might be a bit troublesome to make straightforward, or you could do a blanket "disable failure X on all parts" and a "force failure X on any (random) part that can fail that way".

If @fingerboxes decides he's not all that interested in doing anything too in-depth, maybe I'll make a small addon for TestFlight that adds these options. I imagine people might want to run their own "simulations" with quicksaving and reverting and could find it useful even without HoloDeck.

[jwvanderbeck]

I imagine people might want to run their own "simulations" with quicksaving and reverting and could find it useful even without HoloDeck.

That is probably true. I guess I was hoping to avoid it because I hate doing UI stuff, but i'll add it to my list.

EDIT: Actually on further thought I'm not so sure. I mean the ability to disable failures outside of an actual sim is essentially cheating. I need to think on it a bit more.

[magico13]

EDIT: Actually on further thought I'm not so sure. I mean the ability to disable failures outside of an actual sim is essentially cheating. I need to think on it a bit more.

That's why I was thinking as a debug menu item outside of simulations, and a normal feature inside simulations.

Why don't we leave it as an external item from TestFlight. Either in HoloDeck or as a separate addon. If I do it separate, I'll make it hidden normally and use HoloDeck's API to (actually, I could do it right now without an API) have it be a normal feature during simulations. We can probably still package it with HoloDeck, but leave it as an option if normal TestFlight users really want it.

I hate UI work too ;)