Agathorn

Pretty much.

Wow you took this so much farther than I did. Awesome job!

The Flight HUD only shows parts that have failed, so if nothing has failed it indeed will just be a small empty square. Its purpose is to be as unobtrusive as possible while still conveying the most important information (IE what has broken).

This thread is self-defeating because it is self entitled attitudes like this that make me want to vanish and leave you with nothing. Being polite, showing appreciation, those are the things that encourage modders to be more active and thus avoid the problem you are complaining about. The opposite, IE this post, discourages modders.

Sorry I didn't see this post, but FYI this is also fixed in 1.5.4.3 and 1.5.4.4 which are both for KSP 1.0.5

The point is for some of us it is so much easier to make a nice looking UI using the standard Unity editor, like a normal dev would do, and then export that and import it into KSP. That is different from the old method of having to make the entire UI directly via code.

What is KSPEvent using under the hood? My understanding is that PartMessage was made to avoid the crappy Unity SendMessage system. Which I can certainly understand. Is KSPEvent using the new UnityEvents system?

Pretty sure @sarbian intentionally doesn't check for the year. After all it is April Fools on 1April every year.

It is very simple. Start Unity and create a project. Or open one of you have n existing one. Then unzip the PartTools. In it you will see a another zip file and a unity package. Double click the Unity package. This will then switch to Unity with an import dialogue. Click import all and you are good. for that part. Next unzip that second zip, its like legacy tools or something. Instead of a unity package it will just be a folder structure. Find your Unity project on disk and copy that folder structure to the "Assets" folder in your project. Switch back to Unity and it will detect the change in import them.

Got my AssetBundle loading after adding the .ksp extension. Thanks @TriggerAu. I swear I tried that before but who knows. It loads now. My canvas isn't showing up, but i'm at least one step forward and just need to figure out how to work with it once loaded, so thanks @sarbian for the GCMonitor code, i'm sure that will help a lot. Is your prefab just a Canvas and its children or is there more to it than that?

Import it into the game is where i'm hung up right now But my point was that i've worked with these same UIs in my own Unity project without difficulty so i'm confused as to why it would be such an issue in KSP unless it has something to do with the KSP side? Anxious to hear what Sarbian has to say since you said he worked it out.

If you can make it a Prefab then yes should be doable. Really it opens up some amazing doors. I"ve got an AssetBundle exported, but can't seem to get it loaded into KSP. It just keeps erroring saying it can't be found: AssetLoader: Cannot find bundle definition with name 'TestFlight/AssetBundles/testflight' I notice in Sarbian's original post he mentions the AssetBundle should have an extension of .ksp, but the one created by PartTools has no extension. Not sure which is correct. The error doesn't have an extension either so I assume the no extension is correct. I've copied over both the AssetDatabase and the xml but no joy so far. That doesn't make any sense. I mean after all modders in KSP are only one step removed from just a normal Unity developer unless KSP itself is mucking around with things. Even if it is harder from a code perspective, for me it is most likely worth it to be able to design NICE looking UIs using a proper editor.

Did that work for you? Because that is what I tried to do but it wouldn't actually go away.

Immediate Mode GUI still exists in Unity 5, so beyond those changes and maybe some minor changes your GUI should still work. I can't confirm that but that should be the case. That said IMGUI is slow, and hard to work with, therefore there is definite benefit in diving into the new Unity 5 GUI stuff if you have the desire. It will let you produce much better UIs with less work.

Ok still working on this but after blindly groping around i finally found something. 1. Select a prefab. 2. Look in the properties panel, and look at the very bottom. You will see a section named "Asset Labels" and you will see a property AssetBundle. 3. It will say None. Click that and you can create a new bundle. 4. In the AssetCompiler, click Update All and your new bundle will show up. One thing I can't find is a way to delete one though.

Has anyone figured out how to use the new PartTools to build an AssetBundle? I have it loaded and working Unity but I can't figure out how to take a prefab i've made and make a bundle out of it.

There is a sticky right in this very forum.

Thanks for this Sarbian!

TestFlight 1.5.4.0 Highlights The TestFlight R&D System is finally here! It has been teased forever by the nonfunctional R&D tab seen in the TestFlight window in the KSC screen, but now it is finally implemented. The R&D system is an optional feature that allows you to spend funds and time to increase part reliability without actually flying them and risking bad things happening. Gaining data through flight will still often be quicker, but not as safe. R&D will be safer but slower and cost funds. The choice is yours. Parts do have maximum R&D limits however, so while engineers can get you to a better reliability before flight testing, they won't get you all the way. R&D can be assigned to any supported part while in the editor constructing your vessel. Simply right click on the part and click the R&D Window button to toggle the R&D window. Here you can assign one of several teams to begin researching that part. Choose the one that works for you, balancing time and cost. Every research cycle, which defaults to one day but may be changed by other mods, your part will receive flight data assigned to it by the research team, and funds will be subtracted. You can stop/pause/resume research at any time either in the editor or as a shortcut by using the R&D tab in the main KSC screen. Research will also auto stop if the part reaches its maximum R&D level. In addition to the R&D system, I also took this time to redo how TestFlight information is displayed in the editor. The old TF window in the editor is now gone, and is replaced by the new R&D window for assigning research and a new "Info Overlay" window which can give you detailed TestFlight information on any placed part with a simple Middle Click. Upgrade Notes Upgrading from 1.5.3.0 release to 1.5.4.0 release should not cause any issues. If you are upgrading from a dev or beta version of 1.5.4.0, it is suggested that you first stop all R&D teams before upgrading. Changes FIX: Fix editor info window not hiding properly FIX: Fix editor info window not shrinking in size when changing parts or hiding the window NEW: EngineCycle module now displays information on idle decayand thrust modifiers if applicable in the info window FIX: Fixed a possible NRE in TestFlightRNDScenario load, as wellas making that code a bit more robust in the case of unexpected data. FIX: Apply rndRate and rndCost to display in R&D window. Fixes #136 FIX: Fixed internal burn time handling on TestFlightReliability_EngineCycle FIX: Fixed major bug that was causing time handling to be truncated, causing part updates to happen less and less frequently the longer your save went on FIX: Moved TestFlight settings file to PluginData so that it doesn't cause ModuleManager recaching when settings change. Important Note: TestFlight will automatically migrate the settings file for you the first time, but it won't be able to clean up the old file. Once migration happens you can freely delete the old file if desired. FIX: Fixed to RND Teams getting reset due to a race condition during RND scenario load. FIX: Fixed Editor R&D Window position not being properly read from settings on initial load. NEW: Parts no longer can gain data while in the PRELAUNCH situation. This means no more static test firing. The new R&D system should be used instead if you don't want to risk parts on an actual flight. NEW: Expanded Info window data for Core and Reliability modules FIX: Major bug fix that was preventing pretty much all modules from properly attaching! NEW: Placed parts in Editor now have a quick info overlay window that can be accessed by right clicking on the place part. This info window will display TestFlight information on the part. NEW-API: TestFlight modules now all have an interface method for GetTestFlightInfo which is used to return data the module desires to be displayed in the Editor Info window NEW-API: Interop changes now fire an event on the active Core module allowing for reactions to the change. FIX: Fix duplicate R&D Window buttons showing up in editor tweakables. NEW: R&D Window in Editor now displays information on how the system works, how much teams cost and how many points they contribute NEW: R&D settings can no be configured by other mods using Confignodes. Place all settings in a node named “TFRNDSETTINGS”.updateFrequency is a double indicating how often the R&D teams tick. Value is in seconds and the default is 86400 or 1 day. NEW: R&D Teams can be configured by mods using a Config node. For each desired team add a node named “TEAM” under the main “TFRNDSETTINGS” node with the following properties: points indicates the amount of research points (directly mapped to data units) generated by the team per update. Default is 100. costFactor indicates the cost per point of the research team. Defaults to 1. Added ConfigNodeExtensions from @stupid_chris with license information. NEW: TestFlight supported parts in the Editor now have a right click menu button R&D Windowwhich allows you to quickly open up a window to control research team allocation for the part. NEW: TestFlight now has a new Research and Development feature. This R&D System is optional, but allows you to trade off time and funds for increased part reliability. Rather than risking failures during a mission with low reliability parts, you can instead assign engineering teams to work on the parts over time, slowly increasing the part reliability without risk. NEW-CONFIG: New property added to ITestFlightCore to support R&D: rndMaxData defines the maximum amount of flight data that can be obtain by using engineering teams. This is defined in absolute units and if not present, R&D ill cap out at 75% of the part's maximum data NEW-CONFIG: New property added to ITestFlightCore to support R&D: rndRate defines the speed at which the part is research by engineering teams. This is a multiplier against the number of points generated by a team each cycle and defaults to 1, IE no modification. NEW-CONFIG: New property added to ITestFlightCore to support R&D: rndCost defines the cost at which the part is research by engineering teams. This is a multiplier against the cost of the team each cycle and defaults to 1, IE no modification. FIX: The following failures will re-apply themselves on loading a game: EnginePerformanceLoss, LockGimbal, ReducedMaxThrust, ResourceLeak NEW: TestFlightReliability_EngineCycle can now optionally modify accumulated burn time based on the actual thrust output of the engine. This is defined as a modifier curve using the FloatCurve thrustModifier NEW: TestFlightReliability_EngineCycle can now optionally decaythe used burn time on an engine when the engine is turned off. Can bedefined by using the property idleDecayRate. This value is directlysubtracted from the engine's current burn time each second, so a valueof 1 would be an approximate 1:1 time decay. This can optionally allowengines to have extended usage when shut off during coast periods.Note that this only kicks in if the engine is shut off (not ignited). NEW: TestFlightFailure_IgnitionFail can now apply an additional modifier to the chance of ignition based on the number of previous ignitions used. Use the FloatCurve ingitionUseMultiplier. This is a straight multiplier and thus values below 1 will lower the chance of the engine igniting and values above 1 will increase the chances. NEW: TestFlightFailure_IgnitionFail can now cause an additionalfailure to occur if the ignition fails. The chance of this occurringcan be set in the property additionalFailChance and is a value 0-1f,with default of 0. If this additional failure triggers then theengine will receive one of the existing random failures assigned to thepart. NEW-API: Add new property Failed to ITestFlightFailure interface. FIX: Persist the failed state on a part NEW: Add EngineModuleWrapper method to set the number of ignitions directly. NEW: ShutdownEngine failure now also removes all ignitions from the engine. They are restored is the failure is repaired. NEW-API: Add method to EngineModuleWrapper to return the current number of ignitions on an engine. int GetIgnitionCount() NEW-API: Added new functions to EngineModuleWrapper to Add and Remove ignitions from compatible engines. void AddIgnitions(int numIgnitions) and void RemoveIgnitions(int numIgnitions) Passing < 0 to RemoveIgnitions will remove all ignitions on the engine.

The new version, about to be released, makes it easier to see this data.

Hi @Shadowmage I really like SSTU and was wondering if you might welcome some help? I am very keen on getting the probe/satellite parts working and instead of just bugging you on it thought it would be more beneficial to offer to help I can do pretty much everything, modeling, texturing, and coding, I would just need some help understanding how you have things set up for this amazing modular/procedural stuff

TestFlight 1.5.3.0 NEW: New Failure module EnginePerformanceLoss causes the engine's Isp to degrade by an amount specified in the config property ispMultiplier. A second property ispMultiplierJitter can be used to add some small extra random variance to the degredation NEW: TestFlightInterop now adds an intervop value named kspPartName which is the internal KSP name of the underlying part. This does not change. Can be used in config queries and should be used instead of blank queries or queries with just part names. config = kspPartName = squadFoo. CHANGE: Internally, any empty configuration string is coerced into kspPartname = squadFoousing the new interop value and the parsed part name. FIX: If a part has starting flight data from the config, add that to the scenario data store when first initializing it. Should fix issue with needing to record past the startFlightData before it would stick. NEW-API: Added TestFlightPartData.AddValue and overloaded versions for int, float, and double that do what it says on the tin. NEW-API: Added TestFlightPartData.ToggleValue for bools NEW-API: AddedTestFlightManagerScenario.AddFlightDataForPartName helper function to add to existing flight data for a part. CHANGE-API: Renamed TestFlightPartData.AddValue to TestFlightPartData.SetValuefollowing in accordance with the previous similar change to TestFlightManagerScenario which wraps these for convenience. CHANGE: Removed persistence from TestFlightCore.startFlightDataas it is not dynamic. CHANGE: TestFlightFailure_ResourceLeak - Use System.Random from TestFlightCore instead of Unity's broken random. CHANGE: All RealismOverhaul configs have been removed from TestFlight and are now managed and provided by Realism Overhaul directly. CHANGE: TestFlight Realism Overhaul Config pack is no longer built or provided by TestFlight. CHANGE: Removed Aerobee engine line from RealismOverhaul configs, as these configs now live in the RO project NEW: Reliability modules for SkinTemperature and InternalTemperature

This hasn't really been the case for me. I have a 6gb card but i've never seen KSP use more than about 3.5gb of the VRAM, regardless of mode and mod count.

@Shadowmage Just want to say this is one of the most amazing mods I have ever seen in KSP. I was introduced to it last night and I must it is absolutely brilliant! Exactly what I have been wanting for years.

Sorry you are finding it a struggle. I’m afraid this is really a consequence of the fact that I don’t play stock, ever. I am a Realism Overhaul player, so that is all I know. The “missing download” you mention is the RO configs On the stock side things aren’t so good and I acnkowledge that but sadly there isn’t much I can do about it What would the TestFlightReliability_SkinTemperature (or InternalTemperature) curves look like? It says "1.0 is normal, higher fails more" so for a 10% failure rate at 0 data...? temperatureCurve { key = 0 0.9 key = 10000 1.0 } I looked through the entire Stock Config and RO config, and nowhere are these curves used, so I don't have any examples to go by (and up till now, I never knew what these "curves" even were!). Ok so first the curves are what is known as a FloatCurve and is a standard KSP thing. You can google them, but essentially it is a list of key value pairs that describe a curve if plotted on a 2D plane. There is also a KSP plugin for Unity that will let you see and create them visually in the Unity editor which is great. Now when it comes to Reliability modules, first off it is important to understand that there are essentially two different types of Reliability modules. The first is the basic module which provides a Base Failure Rate to TestFlight. This Base Failure Rate or BFR decreases as more data is accumulated on the part. You must always have one (and only one!) of these modules on a part. The second type is a essentially a modifier. These Reliability modules work on top of the base modules and provide a Momentary Failure Rate or MFR to the part based on moment to moment conditions. Skin Temperature in the case of this module. This MFR is a multipler applied against the BFR. The MFR does not change based on data but on conditions. Since it is a multiplier, a value of 1.0 essentially means no effect. A value less than 1.0 would actually make the part have a lower than base failure rate and a value greater than 1.0 would make the part have a higher than base failure rate. So essentially in this case you could make the part more likely to fail as its skin temperature increases. Now the curve in the config, as mentioned is a FloatCurve. Specifically in this case the key (first value) is the temperature and the value is the MFR applied for that temperature. The curve you quoted above would make the part slightly less likely than normal to fail when it has a skin temp of 0, and then it would linearly increase until at 10,000 degrees it has a normal failure rate. I’m fairly certain that isn’t what you wanted, but hopefully you now have the information to do what you want. If you haven’t already, you can read more about MFR and BFR in the TestFlight Quick Start guide on the Wiki. duRepair = 50 duFail = 100 What does this mean? If I remember correctly, "du" is the data unit, correct? I thought it might be the minimum data required to repair, which might make sense, but having a minimum required to fail doesn't really. These give the part a specified amount of data units when a part fails or is repaired. Think about it like this; If a part fails during a flight you learn from that, so this gives you a bonus chunk of data when that occurs. Failure Rates: I feel like I should know this already, but are failure rates solely determined by the curve, and then the type of failure it determined based on the weight assigned to it? The failure rate of a part at any given moment is Base Failure Rate * Momentary Failure Rate. Additionally there is a slight modifier based on operating time, because all things being equal a part is more likely to fail as its operating time approaches its MTBF. When a part fails as part of the normal survival checks each tick, then a random failure is picked based on weight. That said some failures can work outside the system and trigger themself based on conditions, and will not be triggered with random failures. TestFlightFailure_IgnitionFail is an example of this. TestFlightReliability_EngineCycle -------> ratedBurnTime What are the units on this? My guess is seconds? Yes, in seconds. Repair Module: canBeRepairedInFlight Does this mean in the "Flight Scene" (as in while you have the vessel actively selected) or while the vessel is "In Flight", as in engines burning, flying. It has to be the former, but it's late, I'm tired and I need clarity:lol:. I have a great mental picture of the latter, though. canBeRepairedByRemote The opposite of above I'm guessing (assuming the former is correct)? canBeRepairedInFlight means can the part be repaird while the craft is actually flying, and has nothing to do with the scene. canBeRepairedByRemote means can the craft be repaired wthout any crew, like a software update sent over the comm. The repair side of TF really never got fleshed out as much as I wanted, but originally there was the intention of making it so some repairs would require crew to EVA to the part to fix it.