Agathorn

FYI, TestFlight 1.3 now supports ContractConfigurator and adds a new contract goal for gathering test data for a part. http://forum.kerbalspaceprogram.com/threads/109901-1-0-2-TestFlight-v1-3-1-17-May-2015-Bring-Flight-Testing-to-KSP%21

Release 1.3 (v1.3.1.0) GitHub, or KerbalStuff Highlights KSP v1.0.2 Compatible No more scope As of v1.3, the concept of flight scope has been removed form TestFlight. This means that part reliability and flight data are universal. Removal of scope reduced the complexity of the code, but more importantly opened up things for coming soon features that simply couldn't be done well while scope was there. It made things too complex for the player. ContractConfigurator Support TestFlight now supports ContractConfigurator by adding a new contract goal to gather flight data on a part. This allows contract authors to add flight testing! NOTE: While the support is there, currently no contracts actually use it. Stock Configs This version of TestFlight introduces some basic preliminary config files to support Stock parts for everyone who wanted to play with TestFlight but don't play RealismOverhaul. More fleshed out configs will come later and i'm really hoping I can enlist some community help on these, as I personally don't play stock. TestFlight Plugin, and Config Packs TestFlight is now distributed in pieces consisting of one ZIP file for the core plugin, without any configs, and then separate config packs, currently for RealismOverhaul and Stock. NOTE: Under this new model, you must make sure to download and extract both the core plugin and one config pack. There may be some initial hiccups on CKAN due to this change, as it isn't possible for me to test it 100% before releasing. Any issues I will endeavor to fix as quickly as possible. Please let me know if you run into any problems! Change Log •API: new API stubs for interrogating scenario data store •GAME-PLAY: The concept of '*scope*' no longer applies, and data and reliability is universal. This is a major change that paves the way for newer features coming soon. •CONFIGS - ALL: Updated reliability configs to use noscope format •NEW: ContractConfigurator support. TestFlight now creates a new Contract goal for gaining flight data on a part. This allows contract authors to incorporate flight testing into contracts. •FIX: Fixed data type errors in noscope api changes. Added data overloads for float, int, bool, and double •NEW: Property added to TestFlightCore `startFlightData` that can be used to indicate that a part should start with a given amount of existing flight data •NEW: TestFlightScenario available in all scenes •FIX: ContractConfigurator don’t try to validate part string during initial load, as we won’t have a scenario available then •FIX: ContractConfigurator only display data remaining if some data has been collected •KSP: Updated and compiled for KSP v1.0.0 •NEW: TestFlight now distributed as multiple files, with a core Plugin Only distribution and multiple Config Packs, currently for RealismOverhaul and Stock. •FIX: If TestFlight title property is not defined or blank, use the part's stock title instead •FIX: Fix possible infinite loop when the TestFlightCore had a configuration without query in it •NEW: Allow any module to have a blank or undefined config. In such cases it is considered always active •CONFIGS - STOCK: Added RT5, RT10, BACC, and Kickback solid boosters •CONFIGS - STOCK: Added: LV-T30, LV-T45, LV-909, Poodle, Skipper, Mainsail liquid engines •CONFIGS - RO: WAC-Corporal and XLR11 engines start fully tested •CONFIGS - STOCK: Fixed incorrect configuration tags on stock solid engines •CONFIGS - STOCK: First tier stock liquid and solid engines start at max data already researched •API: Added API to TestFlightManager for persisting arbitrary data for a save game •NEW: Added per save game settings •NEW: Parts can be set to always be at maximum flight data in a specific save game •NEW: TestFlight can be enabled or disabled on a per save game basis •FIX: When part’s start at MaxData they start at properly the maximum data defined by the ReliabilityCurve and not some insane high value. •FIX: NREs caused by save game without existing data store •NEW: Added save game settings to the KSC level TestFlight settings window •FIX: Engines would continue gaining data when shutown. Engines now use finalThrust to determine running state •NEW: Added `maxData` property to TestFlightCore to indicate the maximum amount of flight data the part can obtain. •CONFIGS - STOCK: Added stock resource tank configs •NEW: Flight data caps out at `maxData` as defined by the TestFlightCore. Closes #68 •CONFIGS - STOCK: Add maxData to all the stock engine configs •NEW: Added default savegame settings •API: Updated SaveData API to allow passing a default value to be used in the case where the saved data could not be found or converted to type •CONFIGS - RO: Added proper `maxData` lines to all existing RO engine configs (Thanks @NathanKell!) •CONFIGS - STOCK: Don't treat command pods with resources as resource tanks •FIX: Updated AV .version to KSP 1.0 •NEW: Updated build system to include a version file for configs •NEW: Split core and config packs into separate netkans •FIX: Updated ReducedThrust code to work with FuelFlow (Reducing fuel flow results in loss of thrust) for KSP 1.0 •NEW: Failure_ReducedMaxThrust now supports new KSP 1.0 engines as well as RF EngineSolver engines- Refactored EngineModuleWrapper to no longer split between ModuleEngines and ModuleEnginesFX, and to support new EngineSolverengines such as ModuleEnginesRF •FIX: No longer use FAR (when installed) to get atmospheric density, as KSP 1.0 has proper values now •NEW: Compiled for KS 1.0.2 •NEW: Compiled for ContractorConfigurator 1.0.4 •NEW: Failure_ResourceLeak is now more flexible in how the leak amounts are defined. By default it functions as normal, however you can optionally specify values to be in percent of maximum resource capacity or percent of current resource level. By adding the suffixes %t or %c respectively. •NEW: Added `calculatePerTick` property to Failure_ResourceLeak. If set to `true` then any percent values will be re-calculated each tick. If`false` then they will only be calculated initially at the time of failure. Default values is `false`. •FIX: Leaked resources will no longer pull from other parts! •FIX: Proper lowercase check for failure module names. (Thanks @magico13!) •FIX: Catch situation where TriggerFailure() has no valid failures inthe list. (Thanks @magico13!) •NEW: Core.dataCap is now a float percentage rather than a hard number •NEW: Add API method GetMaximumFlightData() which returns the most amount of flight data possible to be gained on a part •FIX: Parse leak values as en-US format

https://github.com/KSP-RO/RealismOverhaul/issues/250 We're getting there.

Well pretty much what magico13 and I have been discussing on the KCT API issue: https://github.com/magico13/KCT/issues/33 If I can register methods to be called for certain events, like when a simulation starts, when it is restarted, and when it ends, then I can use those event hooks to do things.

Not for me it doesn't. Maybe 50% of the time.

I commented on the bugs on GitHub, but wanted to follow up here as well. Right now your code above is problematic as it isn't the proper way to get the Core on a part. There can be multiple Cores (or any model really) on a part, but only one will be the active one. This is because things like engines in RO for example can have multiple configurations on the same part because of RealFuels. So TestFlight has a Query system that can be used to define multiple modules and which configurations to hook to. Anyway long story short you need to either 1) Use TestFlightInterface and just specify the part, and let it hook to the proper Core, or 2) If you are going to get the Core yourself, you need to call the API to let it get the right one for you. https://github.com/jwvanderbeck/TestFlight/blob/dev/TestFlightAPI/TestFlightAPI/TestFlightAPI.cs#L103

Hmm you know what, those API examples are embarrassingly out of date now, as a lot has changed in the core code. For example, finding the core is very different now due to the query system. The good news is you don't need to worry about it. Things are actually easier now then they were back then The easiest way to do it is to use TestFlightInterface (https://github.com/jwvanderbeck/TestFlight/blob/dev/TestFlightCore/TestFlightCore/TestFlightInterface.cs) which is, essentially an API wrapper around the API Its job is to make it easier to interact with TF through Reflection. Every method in TestFlightInterface is static, so that makes them very simple to call from Reflection. Furthermore any of the methods that deal with a part specifically (which is 99% of them, other than some basics like checking if TF is enabled, etc) take the Part as a param, and then find the core for you internally. I would look at the Interop example code: https://github.com/jwvanderbeck/TestFlightAddon/blob/master/TFInteropExample.cs for a simpler example of how to work with the TestFlightInterface, but in a nutshell: Initial setup: https://github.com/jwvanderbeck/TestFlightAddon/blob/master/TFInteropExample.cs#L11-L26 That will then give you a cached tfInterface handle to the TestFlightInterface which you can use to invoke the various Interface methods. For example: tfInterface.InvokeMember("DisableFailure", tfBindingFlags, null, null, new System.Object[] { this.part, "TestFlightFailure_ResourceLeak" }); Side note, while the API has been very stable, I would verify things as they stand in the "dev" branch just in case. One example is that Scope is going away in 1.3, so all the methods dealing with Scope aren't needed anymore. - - - Updated - - - LOL you got it working faster than I could type up my reply. Is that a sign I made it good?

Sorry man but that isn't reliable unless they sneaked in a fix when I wasn't looking? The problem is that the throttle hits 0 for at least a moment, and depending on your luck that can be enough to trigger EngineIgnitor and you lose it. Hence why I talked to Sarbian about adding an option to not cut throttle when turned off, but just leave it alone.

Excellent enneract! Glad to see this in the public finally! As integration with this and TestFlight is important to me, I will be sure to bombard you with any issues I run into, but first I need to get myself caught up on all that you've done. I'll be back! - - - Updated - - - So I took a *very* quick glance over your code, and sadly I am not seeing any sort of API at the moment to allow integration. Do you have plans for such a thing?

I have made this request of Sarbian but not sure when it will appear.

Logs please?

Where are you looking? IT isn't on the part menu, and this is my bad for not putting more information in the first post. You should have a RealScience toolbar item, and if you click that it opens the RealScience interface, which lists all the experiments on the craft. Is it listed there at all or is that window blank?

Ok so a couple things here. 1) Remove the conditions = Planet,Landed line. You don't need that. It shouldn't break anything, but it isn't used either so just nix it. 2) In the first conditionGroup it should be groupType = and, you have it listed as just type = and which is wrong. 3) In the second group, remove the quotes around "and". You don't need those, and i'm not sure if that causes problems or not. Those are the only errors I see at the moment. If it still doesn't work, remove the second group entirely. It should work, but I have had a few bugs related to the Resource condition, so might still be some left? Also, both the Situation and Body conditions should have mouse overs that will tell you why they fail, so might check that to see if anything silly is happening if all of the above fails. As for what happens if RealScience isn't installed, it would just throw a benign error. However if you want, instead of doing :FIRST (which i'm not sure why you would use that anyway?) you can do something like :AFTER[RealScience] in which case, ModuleManager will completely skip it if RealScience isn't installed.

Sorry I meant to look into your problem last night but I didn't get off work until late. I will try again tonight to see what's up. Its possible my example is just wrong, as I didn't test it.

No science def is needed, since RealScience interacts directly with the underlying R&D system. All you need to do is define the experiment on the part(s) you want to be involved. Here are two examples, one for a very simple one condition experiment, and another for a much more complex multi-condition, multi-part experiment. http://pastebin.com/QSUdGQT3 http://pastebin.com/MBCC0jp0

This is the general idea for phase 2, but that is farther down the road.

Yes I will get some screenshots up soon though bear in mind the UI is really not finished. Well nothing is finished, but the UI really needs more work.

Fair enough. Just giving you another option. Bear in mind however that at this stage RealScience doesn't futz with nodes. That will come later.

When you said multiple data points, I took that to mean multiple flights collecting data. I now see what you mean, and will have to put some thought into how best to support it.

By the way, not that I want to discourage you from using RealScience, but have you looked at TestFlight? It seems more suited to what you describe, in fact it is one of the things it was designed to do. What you can do is configure the advanced reactor part to have a very high failure rate between say 0 and 5,000 data, so that if anyone goes directly to them they are going to fail all the time. Then you configure it so that testing on the NERVA engines transfers to the reactors. What that means is that data gained through flight testing of the NERVA gets applied to the reactors in some percentage as defined. Essentially what you do is make it so that the player has to do some flights with the NERVA first to gain data or else the reactors will just have really high failure rates.

Crew Type is already on my list, see Issue #3 (https://github.com/jwvanderbeck/RealScience/issues/3), and I have added an Issue to add a module property to the Part condition. For the other two, Thermal Heat and Resource Ratio, would those be on the craft in general or on a specific part? Yeah something like that is a good idea, but let me put some thought into how it should work. It got really complicated in TestFlight and I would rather avoid that complexity here if possible. - - - Updated - - - There are plans for this type of research, where basically you will perform research over multiple flights. It isn't done yet, still on the drawing board, but is definitely something I want to do.

In what way? I mean Science doesn't work in Sandbox mode so I'm not sure what you are asking. There isn't necessarily any reason why you couldn't still run RealScience experiments in Sandbox mode, but you wouldn't get any science from doing so. It could completer contracts though I guess (once that is in).

I have been thinking along those lines, and I definitely think its worth doing. I'm not sure right now how that will look, but the short answer is yes

RealScience Say good bye to whack-a-mole style "science", and embrace a more solid research based approach to science I started building RealScience for one main reason; I don't like the way 'science' works in stock KSP. It isn't science in my mind. It is more a game of whack-a-mole where you wait for the right conditions to press a button. They could have called ti anything and the game mechanic would have been the same. I personally wanted something more involved, something that would require you to actually collect research and analyze it in some way. RealScience is what was born from those desires. This has been in development for a bit now, in private and in conjunction with the RO guys in IRC, but i'm now posting it here publicly. This is by no means done, but it is usable. There is still a lot of work to be done but it is mostly in the area of improving the UI, and expanding to provide designers more conditions. First off please be aware that RealScience is just an Add-On that does absolutely nothing by itself. It requires designers to create experiments to use with it. These will be showing up initially in RP-0 soon(ish) but anyone else is also more than welcome to build experiments. What I am trying to say though is here what you will find in this thread for download is just the plugin, no experiments. OVERVIEW You can see the original design as documented at the start of development on the Wiki here: https://github.com/jwvanderbeck/RealScience/wiki/Original-Design In a nutshell RealScience seeks to do two things, only the first of which is being tackled at this point. 1) Remove the whack-a-mole style stock science and replace it with a system that requires the player to collect research under proper conditions, and then analyze that research to complete "the science" 2) Overhaul the stock tech nodes system with something that uses science disciplines or schools, and unlocks parts with some semblance of meaning to the research done. IOW don't unlock engines because someone duck up rocks, and don't unlock rover wheels because someone researched how air flows at high altitudes. By removing a generic science pool and replacing it with various disciplines like say Geology, Meteorology, Astronomy, Physics, etc we can make part unlocks be at least somewhat logical. At this time I am focusing on part 1, and part 2 will come in the future. Part 2 will however always be optional for those who want better experiments, but want to keep the stock tech nodes. CREATING EXPERIMENTS Creating experiments is simply a matter of making standard KSP config files to define the experiment and add it to the desired parts. You can find draft documentation on how to do that on the Wiki: https://github.com/jwvanderbeck/RealScience/wiki/Experiments LICENSE This work is shared under CC BY-NC-SA 4.0 license. SOURCE CODE The source for RealScience is available on GitHub: https://github.com/jwvanderbeck/RealScience RELEASES RealScience is in development, and during that time all releases will be posted to GitHub. Please do not ask about CKAN support. That will not happen until I feel RealScience is ready to move to the Releases forum. GitHub release can be found here: https://github.com/jwvanderbeck/RealScience/releases

Update - I have recompiled against KSP 1.0.2. TestFlight 1.3 Release Candidate 1 is now on GitHub: https://github.com/jwvanderbeck/TestFlight/releases/tag/1.3.0.12 Assuming no one finds any major bugs in this RC, I will be pushing out a full release of 1.3 next weekend.