Agathorn

Hi Jiralyah. Very close! Very close. I have a release candidate that I just released on GitHub, though its currently compiled against KSP 1.0, I think it should work on 1.0.2 as well. https://github.com/jwvanderbeck/TestFlight/releases/tag/1.3.0.11

Hey Scientist, yes 1.02 support is coming very soon. But I don't really update this thread anymore. Please move on over to the release thread, which is where TestFlight went once it was well released http://forum.kerbalspaceprogram.com/threads/109901-0-90-TestFlight-v1-2-1-14-Mar-2015-Bring-Flight-Testing-to-KSP%21 Thanks!

Did you install SmokeScreen? I don't know if its still the case, but in the past I had a similar problem with many rockets and that was why. Installing Smokescreen fixed it for me then. If you didn't install it, I would suggest doing so. Worth a try.

There are plans for better integration but until such time as 1) KCT integrates with TF using the API i've supplied, or KCT makes an API that TF can use to integrate with it, there isn't anything I can do. TestFlight provides an API to allow KCT to do that and more, but magico13 never got around to doing any implementation. He has talked about maybe making an API for KCT, and if he does, and that API gives me what I need, then at that time I will look into better integration.

I have posted a 1.3 Experimental release on GitHub: https://github.com/jwvanderbeck/TestFlight/releases/tag/1.3.0.6 This isn't an official release, and in fact it is completely untested, but if anyone wants to give it a go let me know how it works out. That also includes the new build system so you will note three zip files, one for the core plugin which you must get, and then two configs, one for RO and one for Stock. Just grab whichever config you want. The stock is still a work in progress. - - - Updated - - - Ug ignore that release. My new build system still has some bugs. - - - Updated - - - Update: Think I fixed the build. Here you go: https://github.com/jwvanderbeck/TestFlight/releases/tag/1.3.0.7

Burn time in TestFlight means something else. It means how long of a burn time is this engine rated for. Engines get very hot as you can imagine and massive amounts of technology and research goes into finding a way to keep them cooled so that they don't eat themselves up, but eventually they will. Early engines don't have as long of burn times as later engines. As you exceed this burn time, the chance for failure rises dramatically up to several hundred times normal and a failure is virtual certain. So there are two things that could be happening here. The first is yes you are exceeding the burn time, after which a failure will almost always occur pretty quickly, so it might seem to be all around the same altitude assuming you are flying roughly the same profile each time. The other thing it could be is KSP being stupid about random numbers which I have seen happen before. Can you tell me exactly which model LR87 it was and how long you had it running? As an aside, the "A" button means "Acknowledge". It allows you to essentially acknowledge the error, saying "Yes thank you I know it failed, no need to keep showing it to me". It doesn't fix anything, just clears it from your list of part faailures in the compact window settings. - - - Updated - - - Any chance you can reproduce this with TestFlight debugging turned on and get me the log? - - - Updated - - - Hey all, The next release of TestFlight is going to be 1.3 which will be KSP 1.0 compatible. I'm just trying to find and squash the last few bugs in 1.3, as well as migrate to a new build and deployment system that will allow me to separate the core plugin from the configs, so that we can have different config packs for RO and Stock. Shouldn't be much longer, and i'm shooting for this weekend. Probably Sunday as Saturday is my birthday so i'm sure i'll be right lazy then

Yeah I don't see how I could cause that, but the coincidence is alarming.

Thanks for the report! I've tracked down the problem and made a new release, 1.3.0.3 which should fix this issue. Can you give it a try? https://github.com/jwvanderbeck/TestFlight/releases/tag/1.3.0.3

Hey guys, Using the RT API, how can I tell if a specific antenna on the active vessel has a connection to KSC?

Hey all, Some important information about the coming soon v1.3 release. Depending on testing, v1.3 should be out by early next week. This is a major refactoring of the code that will open things up to move forward on some major new features I want to add. v1.3 v1.3 will remove the concept of "scope" from TestFlight. This is the main reason for the refactor as scope was extremely fundamental in the design of TestFlight and had hooks in almost every piece of code, plus the entire data store was based around it. As of v1.3 it will be gone. Also in v1.3 the part configurations will be removed, and TestFlight itself will just be the plugin. You will need a TestFlight config pack installed separately to make use of it. I will continue to release a RealismOverhaul TestFlight pack as a separate release. This separation of Plugin from Configs opens up the ability for other modders to provide config packs as well. I will be setting up a project for Stock configs and a very basic "catch all" config pack for Stock which will hopefully be improved upon by the community. v1.3.1 Once that main refactor is out, my immediate focus moves onto two main new features which are currently planned for v1.3.1 about a week or two after v1.3. These two features are ContractConfigurator support in the form of a Contract Pack for TestFlight, as well as a new R&D feature that will allow you to hire scientists and engineers to work on improving part reliability. In addition once the R&D feature is in place, you will no longer be allowed to do static tests of parts to increase reliability. You will use the R&D system instead, and it will have caps and diminishing returns to encourage you to get out there and fly! To anyone making configs or plugins for TestFlight: Be aware that v1.3 will bring some big changes. On the config side, not too much, but the TestFlightReliability module configs will need some basic changes, as there will no longer be any scopes. On the plugin side, there will be some major API changes, mainly the removal of anything dealing with scope. Any calls you might be making to GetScope and any internal references you have to scope can all simply be deleted. Any calls made to method that generally end in "blahForScope" should be changed to just "blah" and you no longr pass in any scope. Also be aware that all instances of double are being replaced with float due to the fact that KSP has major problems with automatically persisting double data types. Why are you removing scopes?! The decision to remove scope will be lauded by some of you and bemoaned by others. All I can say is that I strongly believe this is the best choice for the project, and will make moving forward on a lot of fun new features possible. While the gameplay elements of scope won't directly be replaced by anything, it will in spirit be replaced with contracts that encourage you to do flight testing of parts in various biomes on various planets. While this won't change the reliability of the parts, it will still encourage you to test them in those places and give you rewards for doing so. Want to help test v1.3? If you want to help test v1.3, you can find the experimental release here: https://github.com/jwvanderbeck/TestFlight/releases/tag/1.3.0.2 Please be sure to read the release notes for proper testing, and be absolutely aware that this is a pre-release development build.

Setting the limiter would just be a way of getting around the throttle limits so, yes, it is disabled as well. If the engine can't throttle then it runs at full power regardless of it you try to cheat or not

Well assuming you don't want to contribute and configure the NON RP-0 parts, bear in mind that RP-0 itself supports only a fraction of the total supported RO mods, so if you have a lot of those installed, and need to save memory you can remove them.

Yes, my only concern is that they *do* reset after. Like I said I know the Stock ones do, I am just not positive that CC ones do as well. They *should* but that isn't a guarantee.

Correct. Hopefully someday down the road both mods will work together, but that is up to magico13 at this point. The only thing I'm concerned with right now, in regards to contracts, is if a contract gets met inside a simulation, does it properly get reset after. I know stock ones do. Anyway I am going to get CC support in here soon, but I need to finish up with quite a large refactor first before I can do that.

Ah damn now I have work to do lol! Thanks for pointing out the releases though Test Flights are still real flights so you can complete contracts just like normal if you complete the requirements of the contract. I'm not sure what you are asking, but feel free to stop by IRC, the TF thread or GitHub (Wouldn't wan to jam up the RP-0 thread with TF stuff).

Fair enough. I'm actually going to be integrating contracts into TestFlight, but waiting on a big new version of ContractConfigurator that is in development.

Note he said "in respect to each other"

Right now only Realism Overhaul is supported. The old config files for stock will not work without modification due to changes in the plugin since those were last made. That said, I am re-organizing things to allow different config packs to be distributed, so soon there will be some choices between RO or Stock, and possibly others.

Do you have a tree.cfg file in your RP-0 directory?

No, that is the repo - IE the code, not the release. https://github.com/KSP-RO/RP-0/releases

Ok if it isn't unlocked then you have a bad install. Did you install Tech Manager and Community Tech Tree? When you started the game did you enable both?

That is the name of the engine, and it uses the stock Squad engines so you definitely have it

Release 1.2 (v1.2.2.0) https://github.com/jwvanderbeck/TestFlight/releases/tag/1.2.2.0 • NEW: UI: New TestFlight window available at Space Center that will contain new features in the future. For now can be used to modify global settings. • FIX: Remember last MET upon reload • FIX: FAILURES: Set initial engine ignition state based on current engine ignition state rather than UNKNOWN • FIX: Persist operatingTime on the part so that loading a game doesn't mess up the timer • FIX: FAILURES: IgnitionFail fallback to 100% baseIgnitionChance if not defined in configs • UI: Reduced logging in Editor scene - - - Updated - - - Sorry for the late reply. I've been distracted lately. That certainly looks correct. Let me test it out.

You shouldn't be even close to any limits for a sounding rocket. Your best starting point is to emulate the WAC-Corporal, the US's first sounding rocket. Tiny Tim with fins for your kick stage, then an Aerobee Sustainer for your sustainer stage. The kick stage is crucial as the very short, very high TWR essentially locks the craft onto its velocity vector to reduce or eliminate tipping as you ascend. 50km is upper atmosphere, 130km is space. - - - Updated - - - While we don't have contracts to emulate this, if you use TestFlight you will find a reason to fly multiple flights to test out components.

ahhh. Well the ignition isn't an error in the code, its an error in your config and TF just isn't falling back to a sane default like it probably should. Your configs aren't defining the ignition chance, and TF is simply assuming 0, in other words 0 chance of ignition which is, well bad At the very least you should define the baseIgnitionChance which is a standard KSP FloatCurve that defines the ignition chance between 0 and 1 (0 being 0% and 1 being 100%) for a given amount of flight data. So the key is the flightData and the value is the ignitionChance. Optionally you can also define a pressureMultiplier that makes it harder to ignite an engine when the dynamic pressure is higher, IE in flight restarts.