Agathorn

No worries, and sorry also if I came off harsh. I was really excited to use this, but between the timeouts due to download speed and the above issue, it was just a mess that left me depressed

Ok so two quick questions. 1) Is there an existing mineable resource (Using Regolith I guess that is?) that is an analogue to Oil? 2) Obviously I can just use this and add my own custom configs on top, but if I want to give back and submit resources for the pack to be used what is the procedure for that? My end goal is to provide resource configs for various powered metals and plastic, as well as the ability to use a mod to allow the player to mine base resources that can be converted to powdered metals and plastics.

Oh sorry. I just assumed that the DEV thread was the most up to date.

You sure about that? It always feels to me like the other way around. Once the chute is deployed, the ship itself often changes orientation to be correct with the chute. Not to mention that you can very easily force rotate your vessel to not be along the vector of the chute.

I'm going to be making some changes to the Failure interface. As I have started working on implementing repair systems for the failures, I have come to the conclusion that I don't like the interface as it stands. The current interface was designed mainly to offload most of the "verification" work to the TestFlightCore. The theory being the more TestFlight itself could handle, the less the mod author has to handle and that is always a good thing. Unfortunately the system as designed this way is not flexible enough to my liking and while it does make it easier on the mod authors, it also stifles creativity. So I am going to be re-working the failure interface a bit. It will now be the responsibility of the failure module to determine for itself if the repair requirements have been met or not, and communicate that back to TestFlight. I will update the documentation once I am done.

Ok I am sorry to be a stupid poster, but I want to integrate properly with CRS and ORS with my new mod TestFlight. I want to have resources for the powdered metals and plastics, like you use with a 3D printer. I looked at the CRS document but it lists a lot of resources from a lot of sources but I am unclear on exactly which resources are actually part of CRS, and if there is anything there I can use or not. If there isn't, which I think it likely, how would I got about submitting them for approval and addition?

My problem may have been due to outages, but it is irrelevant really. The *real* problem is that it started erroring out halfway through downloads, so *some* mods actually got installed by CKAN and some didn't. And all the ones it *did* install, it didn't even recognize that it itself installed them because it marked them as AD. I'm sure you will agree that a mod manager should never, ever, leave the installs in an invalid state. It should either properly install everything, or completely roll back.

Ok well I got a bunch of 403 errors when installing, and now CKAN has installed some mods, not others, and several of the ones it itself installed are marked as AD. So CKAN seems to have gotten itself into a totally invalid state, which really should never happen. I'm just going to wipe GameData and install by hand I guess.

Ok so after reading through tons of pages here and checking the issue tracker I see that my problem is due to the download taking too long and there is nothing I can do to solve it Someone mentioned using the CLI instead and I am trying that now, but I can't figure out how to select the optionals like in the GUI so I might end up with a mess. At this point I think it would have been easier to just install everything by hand like in the past But I really want to see this thing work so I am sticking it out. It certainly has potential.

So for the next release I am working on getting as much of the core functionality in place as possible. By that I mean as many included modules for things like Failures and Reliability as I can, so with nothing but a base install of TestFlight you have a solid experience without any required additional mods. I am also working on improving the UI and introducing requirements for part repairs.

Really dig that battery design in your sketches.

So this is neat. Coming back to KSP after a while away and thought I would try this to get me up and running. Frankly I am surprised it took so long for a KSP packager to appear since these types of programs are quite common in other games that have heavy mod support. Anyway so I grabbed the latest version and went to use it to try and install RSS/RO but it just errors out saying TACLS isn't installed. TACLS doesn't appear anywhere in CKANs list either. So I installed TACLS manually, and then went to try and install RSS/RO through CKAN again and still get the error about TACLS not being installed. How do I get CKAN to recognize that I installed it manually? Ok managed to get through that by just not installing anything that depends on TACLS. But now I can't get anything actually installed because at some, random, point in the download the program crashes with the following exception: System.Transactions.TransactionException: Failed to roll back: System.IO.IOEXception: The process cannot access the file ****\AppData\Local\Temp\CdFileMgr\37492486-b3fb-4f.tmp because it is being used by another process. And yes I only have one running instance of CKAN.

Part Configs In order to add the TestFlight system to a part, you simply need to make an appropriate config for the part, just like with many other mods using ModuleManager. An example config with documentation is given below. If you have any questions, please let me know. Sample Part Config @PART[liquidEngine]:AFTER[Squad] { // The TestFlightCore module is, well, the core of the entire system and controls all the other pieces // Every part that uses TestFlight *must* have a TestFlightCore module or it won't connect to the // overall system. // There should only ever be a SINGLE TestFlightCore module on a part. MODULE { name = TestFlightCore // By leaving these two frequencies at 0, we simply let the global frequency take over // We could however make this one part poll, or check for failures, LESS often by setting higher values here pollingInterval = 0 failureCheckFrequency = 0 } // The TestFlightRecorder module is the second module required by the system. This module is responsible // for collecting flight data, and thus the system is pretty useless without it. This module defines // how the part gains flight data over time. // There are different types of FlightRecorder modules, and mods can add new ones. // There should only ever be a SINGLE TestFlightRecorder module on a part. MODULE { name = FlightDataRecorder_Engine // The data multiplier indicates, ROUGHLY, how many points of Flight Data // is accumulated per second of Mission Elapsed Time flightDataMultiplier = 10 // The data engineer modifier is a bonus per level of engineer skill available in the vessel's crew flightDataEngineerModifier = 0.25 } // The TestFlightReliability module is responsible for calculating the reliability of the part based // on flight data and given scope. Again, there can be multiple of these modules, each canculating // reliability differently. // You can have MULTIPLE Reliability modules on a single part. MODULE { name = TestFlightReliability // factor and multiplier control the difficulty curve of the realiabilty value // reliability = (flightData * realiabilityMultiplier) ^ (1/reliabilityFactor) reliabilityFactor = 2 reliabilityMultipler = 3 // The module can have one or more RELIABILITY_BODY nodes. Each defines the min and max reliability // for a given "Scope". RELIABILITY_BODY { scope = kerbin_atmosphere minReliability = 50 maxReliability = 98 } RELIABILITY_BODY { scope = kerbin_space minReliability = 35 maxReliability = 95 } } // The TestFlightFailure module is the last type of module in the system. Each TestFlightFailure module // defines a specific type of failure that can occur, and is responsible for causing that failure when // told to, and for repairing the failure when told to. MODULE { name = TestFlightFailure_ShutdownEngine // User friendly name to identify the failure in the MSD. Maximum of 25 characters! failureTitle = Engine Shutdown // Failure type can be either "mechanical" or "software". // Mechanical failures are physical failures of parts and require a Kerbal on site to repair it // Software failures are electrical or software glitches and can be repaired remotely failureType = mechanical // Severity of the failure: minor, failure, major // As a rule of thumb, minor failures should only hinder a vessel or mission, but not directly put it in danger severity = major // ** PLEASE USE ONLY THESE WEIGHTS ** // The weight of the failure is how likely it is to occur RELATIVE to other failures defined on the same part // 2 = Rare, 4 = Seldom, 8 = Average, 16 = Often, 32 = Common weight = 4 // If the failure can be repaired, then a REPAIR node mst be defined // If no FAILURE node is defined then hte failure can not be repaired REPAIR { // For PHYSICAL failures canBeRepairedOnLanded = True canBeRepairedOnSplashed = False canBeRepairedInFlight = True requiresEVA = False sparePartsRequired = 10 // For SOFTWARE failures // canBeRepairedByRemote // dataScale // dataSize // For all failures repairChance = 100 } } }

Extending TestFlight - A Guide for Modders TestFlight is a mod for KSP, but TestFlight itself is designed to be moddable as well. This allows other modders the ability to extend the TestFlight system by adding new modules for Data Recording, Reliability checks, and Failure Modes. This documentation is geared towards modders who want to extend the TestFlight system in some way. Core Architecture TestFlight works on a per-part basis and is comprised of four basic modules. TestFlight Core The core module which runs the entire system for that part. TestFlightCore can not be extended. FlightDataRecorder In a nutshell, TestFlight is a system whereby you fly parts and they record data. The FlightDataRecorder module is what handles recording of the flight data. If you want to control how data is recorded, then you can extend FlightDataRecorder to make your own recorder. The base module is very simple, and simply records data as long as the part is enabled. TestFlightReliability This module is responsible for determining the part's reliability. The base TestFlightReliability module simply determines reliability based on the collected flight data. By creating your own Reliability module, you can add to or remove from this base reliability based on other criteria. For example maybe you want a part to become less reliable as it gets hotter. There can be multiple Reliability modules on a part, and the TestFlightCore simply polls them all, and adds up the reported reliability from each into a total reliability. TestFlightFailure The module most likely to be extended, the TestFlightFailure module defines a specific failure that can occur on a part. Maybe the part explodes, or leaks fuels, or shuts down. Whatever you want to happen as a possible failure on the part, you can do it by making a Failure module. Writing Your Own Modules Writing your own modules to extend TestFlight is very easy. Simply make a standard KSP PartModule, and Implement the required TestFlightAPI Interface for the TestFlight module you want to make. IFlightDataRecorder, ITestFlightReliability, or ITestFlightFailure. To make things even easier, you can inherit from the base TestFlight module for each, where most of the work to interface with the overall system will be handled for you, and you just need to implement the specific logic for your module. Common Data Structures TestFlightData public struct TestFlightData { // Scope is a combination of the current SOI and the Situation, always lowercase. // EG "kerbin_atmosphere" or "mun_space" // The one exception is "deep-space" which applies regardless of the SOI if you are deep enough into space public string scope; // The total accumulated flight data for the part public float flightData; // The specific flight time, in seconds, of this part instance public int flightTime; } The TestFlightData structure is used to move flight data around between modules. TestFlightFailureDetails public struct TestFlightFailureDetails { // Human friendly title to display in the MSD for the failure. 25 characters max public string failureTitle; // "minor", "failure", or "major" used to indicate the severity of the failure to the player public string severity; // chances of the failure occuring relative to other failure modules on the same part // This should never be anything except: // 2 = Rare, 4 = Seldom, 8 = Average, 16 = Often, 32 = Common public int weight; // "mechanical" indicates a physical failure that requires physical repair // "software" indicates a software or electric failure that might be fixed remotely by code public string failureType; // Indicates in broad sense, is it ever possible to attempt a repair under some condition? public bool canBeRepaired; // Repair details // Time required to complete repairs. Not currently supported. public int repairTimeRequired; // For mechanical failures // Does the repair require that a Kerbal be EVA to repair the part? public bool requiresEVA; // Can the part be repaired while the vessel is in flight? public bool canBeRepairedInFlight; // Can the part be repaired when the vessel is landed on the surface? public bool canBeRepairedOnLanded; // Can the part be repaired when the vessel is splashed down in the water? public bool canBeRepairedOnSplashed; // How many spare parts does it take to attempt repair? public int sparePartsRequired; // For software failures // Can the part be repaired by remote? public bool canBeRepairedByRemote; } This structure closely, but not exactly, mimics the variables contained in the config module for a failure. It is used to allow communication of failure details between modules that need it. Interfaces IFlightDataRecorder public interface IFlightDataRecorder { /// <summary> /// Called frequently by TestFlightCore to ask the module for the current flight data. /// The module should only return the currently active scope's data, and should return the most up /// to date data it has. /// This method should only RETURN the current flight data, not calculate it. Calculation /// should be done in DoFlightUpdate() /// </summary> /// <returns>The current flight data.</returns> TestFlightData GetCurrentFlightData(); /// <summary> /// Initializes the flight data on a newly instanced part from the stored persistent flight data. /// This data should only be accepted the first time ever. /// </summary> /// <param name="allFlightData">A list of all TestFlightData stored for the part, once for each known scope</param> void InitializeFlightData(List<TestFlightData> allFlightData); /// <summary> /// Called to set what is considered "deep-space" altitude /// </summary> /// <param name="newThreshold">New threshold.</param> void SetDeepSpaceThreshold(double newThreshold); /// <summary> /// Called frequently by TestFlightCore to let the DataRecorder do an update cycle to calulate the current flight data. /// This is where the calculation of current data based on paremeters (such as elapsed MET) should occur. /// Generally this will be called immediately prior to GetcurrentFlightData() so that the DataRecorder /// can be up to date. /// </summary> /// <param name="missionStartTime">Mission start time in seconds.</param> /// <param name="flightDataMultiplier">Global Flight data multiplier. A user setting which should modify the internal collection rate. Amount of collected data should be multiplied against this. Base is 1.0 IE no modification.</param> /// <param name="flightDataEngineerMultiplier">Flight data engineer multiplier. A user setting mutiplier that makes the engineer bonus more or less. 1.0 is base.</param> void DoFlightUpdate(double missionStartTime, double flightDataMultiplier, double flightDataEngineerMultiplier); /// <summary> /// Returns the current data situation, "atmosphere", "space", or "deep-space" /// </summary> /// <returns>The Situation of the current data scope</returns> string GetDataSituation(); /// <summary> /// Returns current SOI /// </summary> /// <returns>The current SOI for the data scope</returns> string GetDataBody(); } ITestFlightReliability public interface ITestFlightReliability { /// <summary> /// Gets the current reliability of the part as calculated based on the given flightData /// </summary> /// <returns>The current reliability. Can be negative in order to reduce overall reliability from other Reliability modules.</returns> /// <param name="flightData">Flight data on which to calculate reliability.</param> float GetCurrentReliability(TestFlightData flightData); } ITestFlightFailure public interface ITestFlightFailure { /// <summary> /// Gets the details of the failure encapsulated by this module. In most cases you can let the base class take care of this unless oyu need to do somethign special /// </summary> /// <returns>The failure details.</returns> TestFlightFailureDetails GetFailureDetails(); /// <summary> /// Triggers the failure controlled by the failure module /// </summary> void DoFailure(); /// <summary> /// Asks the repair module if all condtions have been met for the player to attempt repair of the failure. Here the module can verify things such as the conditions (landed, eva, splashed), parts requirements, etc /// </summary> /// <returns><c>true</c> if this instance can attempt repair; otherwise, <c>false</c>.</returns> bool CanAttemptRepair(); /// <summary> /// Trigger a repair ATTEMPT of the module's failure. It is the module's responsability to take care of any consumable resources, data transmission, etc required to perform the repair /// </summary> /// <returns>Should return true if the failure was repaired, false otherwise</returns> bool AttemptRepair(); } Project Setup - Compiling Against DLLs, etc At the current time I haven't exactly worked out how to deal with requiring a mod to compile against the TestFlightAPI DLL or how to handle versioning etc. I am open to any suggestions and help on this anyone can give. I'm not too knowledgeable in this area. Since it works through interfaces, in theory you should not even need to compile against the DLL at all. As long as you implement the proper interfaces, you should be good. However compiling against the DLL is probably easier, and it lets you use the base classes that do most of the work for you rather than having to implement them yourself. Again, thoughts and suggestion on this are most appreciated. The intention is to through various alpha tests, get the API to a stable spot whereby it will change only infrequently, so it won't be a burden to anyone to keep up with it.

Probably because on the flip side there is no clean way to make a single upgrade either since they ARE distinct buildings.

First alpha version of TestFlight has now been released! You can find v0.1.0 on the GitHub page, as linked in the Original Post, and below. v0.1.0 Alpha https://github.com/jwvanderbeck/TestFlight/releases/tag/v0.1.0 Please, please, note that this is an initial alpha release and is no doubt buggy as hell. Don't use it in any save game that you care about, and fully expect newer versions to break your saves. This initial release only contains a few failure modules for engines and fuel tanks. I plan to expand the system in the future. I welcome any ideas on failure types people would like to see implemented. I have done major edits to the original post to summarize all the information, and what not. Please take a moment to look it over. Any feedback, questions, etc please post. Thanks!

How would you later remove the highlight? I assume you simply destroy the component you previously added, but I can't seem to figure out the proper syntax to do so. EDIT This code is working for me to remove it: Destroy(this.part.FindModelTransform("model").gameObject.GetComponent(typeof(HighlightingSystem.Highlighter))); One thing I would note on using the new highlighters is remember that it isn't guaranteed to be enabled. The user can turn it off or on in the settings, so probably best to use both the old and new at the same time just in case. For example on my Mac I have to turn it off because it doesn't work properly. Instead of getting a Highlight I get random corrupt textures on the screen instead. This is a bug I guess in 0.90 as it happens with the default stage highlighting as well if the new system is enabled.

Thanks, so it looks like I am on the right track, I just need to figure out how to get the proper camera. Like you said in Flight mode its easy, but not sure about the other scenes. Guess I have some API digging ahead of me. For now I'm just going to cop out and use a fixed position relative to the corner of the screen I think.

I want to get the screen space coordinates of my button in the app launcher so that I can position the open window relative to the button just like the stock GUI does. However I can't seem to figure out how to do this. I can grab the button's transform, but that appears to be in world 3d space, and I can't figure out how to get the proper camera to translate them, I tried this code, but it just throws NRE's all over the place. internal void CalculateWindowBounds() { if (appLauncherButton == null) return; Transform buttonTransform = appLauncherButton.transform; Debug.Log("TestFlight MasterStatusDisplay: buttonTransform = " + buttonTransform.localPosition); Vector3 buttonCoords = HighLogic.fetch.camera.WorldToScreenPoint(buttonTransform.localPosition); Debug.Log("TestFlight MasterStatusDisplay: buttonCoords = " + buttonCoords); }

My plan is to make the first alpha release sometime today, assuming I can figure out how to get a toolbar button loaded and operational.

Thanks! I have put together a proper introduction video the the mod. Enjoy!

Ok the answer is I am just an idiot. Coroutines don't do any special magic to keep them looping. I thought they did.

I really don't know anything about coroutines. Never used them before. But I am trying to now, and having problems. I wrote this code based on the Unity docs. The coroutine starts, but only executes once, whereas it is supposed to continue indefinitely until told to stop. using System; using System.Collections; using System.Collections.Generic; using System.Linq; using UnityEngine; using KSPPluginFramework; using TestFlightAPI; namespace TestFlight { public class TestFlightFailure_FuelLeak : TestFlightFailureBase { /// <summary> /// Triggers the failure controlled by the failure module /// </summary> public override void DoFailure() { Debug.Log("TestFlightFailure_FuelLeak: Failing part"); this.part.RequestResource("LiquidFuel", 50); StartCoroutine("LeakFuel"); } internal IEnumerator LeakFuel() { this.part.RequestResource("LiquidFuel", 5); yield return new WaitForSeconds(1f); } /// <summary> /// Asks the repair module if all condtions have been met for the player to attempt repair of the failure. Here the module can verify things such as the conditions (landed, eva, splashed), parts requirements, etc /// </summary> /// <returns><c>true</c> if this instance can attempt repair; otherwise, <c>false</c>.</returns> public override bool CanAttemptRepair() { return true; } /// <summary> /// Trigger a repair ATTEMPT of the module's failure. It is the module's responsability to take care of any consumable resources, data transmission, etc required to perform the repair /// </summary> /// <returns>Should return true if the failure was repaired, false otherwise</returns> public override bool AttemptRepair() { StopCoroutine("LeakFuel"); return true; } } }

Introducing the TestFlight Master Status Display (MSD). The MSD is how you track the status of TestFlight enabled parts on your vessel. It lets you see, at a glance, the status of all the parts, their accumulated flight data, and any failures that have occurred.

Getting ready to push out a release. The OP has been edited to show a sample part config to define all the pieces of TestFlight on a part.