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

[lextacy]

still havnt tried the new version, ill get on it soon!

[karamazovnew]

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.

Woops, sorry for the late reply. What I meant was that your mod so far only deals with engines. But it would be cool to have other types of parts affected: decouplers, solar panels, antenna deployment or range, battery failure, food spoilage, water freezing, etc. etc. As Dangit already works with those and has a good MeanTimeBeforeFailure mechanic, I thought this mod might make a cool and simple extension of that, with testing and repeated usage making those parts more reliable (longer MTBF and a weighted curve, to enforce more predictable reliability figures).

Now, just in case this mod starts to include other parts, it would be nice to have a "per class" and "per part" progression of reliability. For example, improving the reliability of one particular decoupler, would slightly increase it in all decouplers (including ones you haven't researched yet).

BTW, kudos, this is a great idea for realism Keep it up.

[Agathorn]

Woops, sorry for the late reply. What I meant was that your mod so far only deals with engines. But it would be cool to have other types of parts affected: decouplers, solar panels, antenna deployment or range, battery failure, food spoilage, water freezing, etc. etc. As Dangit already works with those and has a good MeanTimeBeforeFailure mechanic, I thought this mod might make a cool and simple extension of that, with testing and repeated usage making those parts more reliable (longer MTBF and a weighted curve, to enforce more predictable reliability figures).

Now, just in case this mod starts to include other parts, it would be nice to have a "per class" and "per part" progression of reliability. For example, improving the reliability of one particular decoupler, would slightly increase it in all decouplers (including ones you haven't researched yet).

BTW, kudos, this is a great idea for realism Keep it up.

Again your asking for integration with a mod that does the same thing in different ways, they just don't jive

As for engines only, that is only because I haven't expanded it yet. TestFlight establishes a very solid underlying system that can be used for simulating a wide range of failures, but those failures need to be made and then parts configured, an that just takes time. We'll get there, faster if others help, but eventually we'll get there I started with engines because they are probably the biggest part of the equation, plus finding realistic data on failure rates is easier. But I will be expanding things to cover other parts as well.

[karamazovnew]

Cool. You know , looking through the config files... seems like this is gonna be a very big job to add it to every single part in the game. Is it possible to make the MM simply add a single module ( and then let the dll take care of generic curves and such? The dll could just read specific values of the part (mass, cost, thrust, fuel type) and provide automatic variation. One single config file could provide global variables. It should make adding the mod to all possible modded parts a breeze.

On top of that, you could make specific tweak to specific parts by adding more parameters to those parts (pretty much as you're doing now). If not, the generic options and formulas would be respected. This would mean that we'd get all parts from all mods done in one go, and only need to tweak the parts that seem wrong.

Soon it might be a good idea to post a list of proposed parts/failure types in the OP. So people can start to bring in ideas to make the process faster. For example, for engines I'd add "cooling failure", forcing you to prematurely throttle back (or, in RO, shutdown). Cheers.

[Agathorn]

Adding configs is already really easy due to my pre-processor. Plus a lot of things have defaults, i'm just choosing to be specific in my configs. What takes time is researching the history of parts to determine accurate realistic parameters to use. In the case of Stock, or another situation where you care less about realism, it would be very fast to setup blanket configs.

If no one picks up the gauntlet of providing alternate configs, then eventually I probably will provide at least some basic Stock-alike configs. I'm still working out how best I can do that easily without making things more difficult on myself and RO users. Specifically i'm referring to how I manage the project and create releases. What I may do in the future is make it so that you download the core TestFlight Plugin by itself and then download a config pack to go with it for whichever type of game you are playing.

[Agathorn]

Release 1.2 (v1.2.1.0)

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

•

FIX: UI

: Fixed Master Status Display getting into a bad UI state when failed parts where removed from the vessel, which caused other Non-TF Windows to get temporarily broken

•

CONFIGS

: Restore ignition charges on the pad but not in the air

•

FAILURES

: IgnitionFail: Don't apply pressureCurve if it evaluates to 0

•

FAILURES

: IgnitionFail: Always restore ignition charge if in PRELAUNCH situation

•

UI

: Updated timestamp on FlightLogger to better match stock KSP entries

•

CONFIG

: Updated all engines with new pressure based IgnitionFail configs

•

CONFIG

: Updated FloatCurve tangents on all configured parts

•

CONFIG

: The KW part representing 2xRL10 engines now records data at twice the rate

•

UI

: Tighter GUI popping to hopefuly reduce clashes between mods

•

FIX

: #53 OneShot failures weren't being triggered

•

CONFIG

: Restore ignition charge on all IgnitionFail failures

•

FAILURES

: Allow IgnitionFail to scale based on dynamic pressure

•

UI

: Add failures to F3 Flight Log along with MET timestamp

•

CONFIG

: Add low tech transfer from Aerobee line to AJ10 Early line

[lextacy]

Tried new release , here are a few take always......

1. engines now fail 100% at ignition 100% of the time with exception of solid boosters

*if using engine clusters for example 6 RD-33K engines, all 6 will fail at ignition. This means the failure mechanics are broke.

2. DU broken , does not count up anymore

[Agathorn]

Tried new release , here are a few take always......

1. engines now fail 100% at ignition 100% of the time with exception of solid boosters

*if using engine clusters for example 6 RD-33K engines, all 6 will fail at ignition. This means the failure mechanics are broke.

2. DU broken , does not count up anymore

Can you turn on debugging and give me logs please? I am definitely NOT seeing this. Also please be absolutely sure you have the latest version, as at one point I had the links bad and they gave the old version.

[lextacy]

Can you turn on debugging and give me logs please? I am definitely NOT seeing this. Also please be absolutely sure you have the latest version, as at one point I had the links bad and they gave the old version.

ill do that when I get home, also the new exception thrower mod is listing yours alot during the VAB and staging of launch. Ill post a screenie of what the thrower is logging

[Agathorn]

ill do that when I get home, also the new exception thrower mod is listing yours alot during the VAB and staging of launch. Ill post a screenie of what the thrower is logging

Not familiar with that mod, but yes TF does throw a few benign exceptions during startup due to the unpredictable order in which KSP starts things up.

[lextacy]

here is the situation

I press spacebar to launch..........

Pressing space ALOT to launch.....still no go

Our great friend.....NULL REFERENCE EXCEPTION..............idk even know what that is but I know its probably responsible

[Agathorn]

Yes most likely, but I need to see the logs to know for sure And if you can go into the TF settings window and turn on debug logging that will help a lot. But you are right that does look bad, especially given the method it is throwing on. Is this with my configs, or your own?

[lextacy]

its with my configs , dammit i keep forgetting that you have your own debugging built in......stay tuned!

[Agathorn]

its with my configs , dammit i keep forgetting that you have your own debugging built in......stay tuned!

Ok in that case i'm almost 100% sure I know what your problem is. Can you post your configs for me?

[lextacy]

Both logs that I found, hope this helps

https://www.dropbox.com/s/e1u45y14f50s1t0/KSP.log?dl=0

https://www.dropbox.com/s/4efhi8625dj6gas/Player.log?dl=0

[Agathorn]

Both logs that I found, hope this helps

https://www.dropbox.com/s/e1u45y14f50s1t0/KSP.log?dl=0

https://www.dropbox.com/s/4efhi8625dj6gas/Player.log?dl=0

Can I see the configs you made? I think I know what the issue is but I need to see your TestFlight configs, since you said you made your own.

Edited March 6, 2015 by Agathorn

[Agathorn]

Ok so in fact it looks like the problem is not what I thought. Let me do some testing with your configs and see what I can figure out.

[lextacy]

okay!

[Agathorn]

@lextacy, I am unable to reproduce the issue you are experiencing. I also can't find any evidence of the exceptions in the logs you provided. At this point I have to suspect that maybe you are using an older version? If you look in the TestFlight directory, you will see a file named TestFlight.version. Can you post the contents of that file please?

[lextacy]

{"NAME": "TestFlight", "URL": "http://ksp-avc.cybutek.net/version.php?id=118", "CHANGE_LOG_URL": "https://github.com/jwvanderbeck/TestFlight/releases/tag/1.2.1.0", "KSP_VERSION": {"MAJOR": 0, "MINOR": 90, "PATCH": 0}, "VERSION": {"MAJOR": 1, "BUILD": 0, "MINOR": 2, "PATCH": 1}, "DOWNLOAD": "https://github.com/jwvanderbeck/TestFlight/releases/download/1.2.1.0/TestFlight-1.2.1.0.zip"}

[Agathorn]

Ok that all looks correct so now i'm really confused. Let me look through your logs again, but I didn't see any exceptions in there the first time. One thing I did note was that you are defining IgnitionFail modules engines without specifying the ignition chance, so every engine just fails to ignite.

Which part(s) where you using when you originally saw the exceptions?

[Black-Talon]

Adding configs is already really easy due to my pre-processor. Plus a lot of things have defaults, i'm just choosing to be specific in my configs. What takes time is researching the history of parts to determine accurate realistic parameters to use. In the case of Stock, or another situation where you care less about realism, it would be very fast to setup blanket configs.

If no one picks up the gauntlet of providing alternate configs, then eventually I probably will provide at least some basic Stock-alike configs. I'm still working out how best I can do that easily without making things more difficult on myself and RO users. Specifically i'm referring to how I manage the project and create releases. What I may do in the future is make it so that you download the core TestFlight Plugin by itself and then download a config pack to go with it for whichever type of game you are playing.

Definitely looks interesting and well done.

I'm interested in helping here (for stock play) but manually writing the configs is quite a bit of work and based on the quoted information above it would be easier and more valuable to the project if I could contribute to the pre-processor version of the configs. But it appears that isn't documented yet? I took a look at your pre-processor scripts but I didn't come up with an obvious guess on what you're using to easily drive that. If you and others are already working on stock then I'll volunteer as a tester.

As for the separate "config packs" I would think this could be handled by the :NEEDS[RealismOverhaul] and :NEEDS[!RealismOverhaul] ModuleManager options and thus not requiring separate downloads. Maybe that won't work?

[Agathorn]

Definitely looks interesting and well done.

I'm interested in helping here (for stock play) but manually writing the configs is quite a bit of work and based on the quoted information above it would be easier and more valuable to the project if I could contribute to the pre-processor version of the configs. But it appears that isn't documented yet? I took a look at your pre-processor scripts but I didn't come up with an obvious guess on what you're using to easily drive that. If you and others are already working on stock then I'll volunteer as a tester.

As for the separate "config packs" I would think this could be handled by the :NEEDS[RealismOverhaul] and :NEEDS[!RealismOverhaul] ModuleManager options and thus not requiring separate downloads. Maybe that won't work?

Documentation is by far my weak point right now. I apologize. Writing it is just so darn boring though!

Using NEEDS tags might work, but I am not sure I want to go that route for a couple reasons:

1. It gets complicated fast

2. You end up with tons of configs that aren't actually being applied but still need to be processed by ModuleManager, which takes time (Every single PART has to run through the whole game database, even if it determines it doesn't apply)

3. There is a small fear that a condition might arise where it just doesn't work, though I admit that is only a small fear and I can't cite any specific example for it.

If you and others do seriously want to start working on Stock configs, then I think the best thing for me to do is spend a bit of time in maintenance mode and split things off into a core plugin for TestFlight and then separate config packs. And documentation, though I fear that will be rough at first. On that note though feel free to ask me ANYTHING that isn't clear or understood, or things that just aren't documented at all and I will do my best to answer and explain. Either in PM, here, or on IRC where I can be found in the #RO and #TestFlight channels.

Let me put some thought into the best way to reorganize things.

[lextacy]

mostly CHaka engines like the RD-68 , SLS booster core, Nerva II , and some Laztek engines

[Agathorn]

mostly CHaka engines like the RD-68 , SLS booster core, Nerva II , and some Laztek engines

Well i'm not sure what to say. I setup a testing instance of KSP with just CMES, TestFlight, and ModuleManager, and your configs. I have no problems with any of your configured engines, with the exception of the ignition issue I mentioned, but that is easily fixed in the configs. No exceptions at all.