CoriW

Oh, that makes a lot of sense actually! Thanks for the info.

Hello, So I've been having a strange issue with trying to get any information at all about the engines on my ship... I've tried the following code which I got from the documentation, but for some reason it always returns 0. It will properly create the list with the proper number of engines in it and it will print the values in the FOR loop, however it just says that all of the engines ISP are 0, which obviously wouldn't be the case. LIST ENGINES IN myVariable. FOR eng IN myVariable { print "An engine exists with ISP = " + eng:ISP. }.

So I've read through this thread and I think I have a proper understanding of this, but I'll ask just to be sure. With SSRW, if I were to set the bleed rate to 0, then the reaction wheels would function reasonably realistically? Correct?

That's correct. Basically I just need the number once to tell TestFlight when the engine will start losing reliability/fail. EDIT: Just re-reading this, I've realized it could be interpreted incorrectly.. When I said "That's correct", I meant "That's correct, I don't expect this value to change when the fuel gets consumed and only need the calculation to be done once when starting KSP and not continuously during flight"

Alright, thank you. Slight change in the calculation as it didn't occur to me that SRB's don't have a mentioned total mass, just dry mass. Since SolidFuel weighs in at 7.5kg / unit we can just use that accompanied with fuel amount, located here: So amount * 7.5 will give us the fuel mass, then we'll also need the Newtons of thrust, as well as the Isp, both of which are located here: Now the maxThrust is listed in kN, so we'll have to multiply it by 1000 in order to convert to N, so maxThrust * 1000. As for the Isp, that can be located in the first key in the atmosphereCurve... I'm not sure how you'd go about reading that key so for sake of putting together a reference calculation I'll just call it "key" for now. Alright so with all of that we now have our calculation, which is referencing parts of the config. (amount * 7.5) / ((maxThrust * 1000) / (key * 9.81)) , in this case it would be (140 * 7.5) / ((192 * 1000) / (165 * 9.81)) = 8.8519921875 and I would need that key to be put into a floatCurve as a key value. For clarity sake, I'll also provide the part of the cfg where I need the calculation to be placed. MODULE { name = TestFlightReliability_EngineCycle ratedBurnTime = (CALCULATION)*1.5 cycle { key = 0 15.0 key = 5 1.0 -0.8 0 key = ((CALCULATION)*1.5)+5 1.0 0 0 key = (((CALCULATION)*1.5)+5)*1.5 100 0 0 } }

How complex can math get in ModuleManage configs? I'd like to use this equation in an SRB config to input the burn time for the SRB, but I just want to make sure that first of all MM can do these kinds of equations in configs and secondly I'm unsure how exactly to convert this equation into something MM will understand. (As it'll need to check several of the properties of the SRB in order to do the calculation) (TotalMass - DryMass) / (N / (Isp * 9.81)) Also assuming that this can be done, I would like the output to be put into a floatCurve in the config... Can you do calculations in floatCurve keys? Or somehow output the result of a calculation into a floatCurve key?

@Agathorn Ah alright, thank you. Also a question that's a bit less related to the configs and more related to rockets in general... I'm not sure how well you'll be able to answer, but since you've created this mod I'm hoping that you'll have some general ideas on the subject. 1) Do SRB's tend to fail more or less often than Liquid Fuel Engines? 2) Would a larger SRB be more or less stable than a smaller SRB? (Stable in terms of failure rate) 3) Would a larger Liquid Fuel Engine be more or less stable than a smaller Liquid Fuel Engine? Actually on second thought I do also have another question about the configs. 4) Do you think it would be possible to make some sort of engine config that could blanket, for example, all of an engine type? (say SRB's for example) Using calculations in the config based on stats of the engine in order to determine things such as the reliabilityCurve, EngineCycle, IgnitionFail pressureCurve, etc? The reason I'm asking is because if it would be possible, then not only would these configs work with stock engines, but also modded engines as well. I got to thinking about this because I've noticed just how many engines there are in the base game, let alone the several mods I have that add new engines. (Basically don't feel like having to do entire new configs for every mod I install that adds news engines.) EDIT: Oh also, how do the techTransfer and techTransferMax properties work? EDIT: Could I propose a change to TestFlightFailure_ResourseLeak? I've been working on these configs for about 2 days now and the one thing I keep finding myself coming back to is the fuel tank config... The problem I see with how it is currently implemented, is that any fuel tank is basically guaranteed to start leaking eventually no matter what the reliability is and even if it's just out in space where I would imagine very little if any degradation would happen to the tank. My proposal is to make TestFlightFailure_ResourceLeak into something that checks a pressureCurve and temperatureCurve and applies a modifier to the failure chance instead of the current generic MTBF system. This would prevent the issue of a tank that's been just floating in space from randomly springing a leak for no apparent reason. Actually for that matter, I think that engine failures should follow a similar principle as well.. Have things fail due to certain conditions, not because of some arbitrary time factor. I mean, if the tank or engine is inside of an atmosphere, then it makes sense for there to be some kind of degradation over time and that could be defined using a pressureCurve and temperatureCurve as well. Aside from degradation, tank failures could be made more frequent while the engines on a ship are firing, potentially using a floatCurve to define a higher momentary failure rate during high G-Force load. Back to the subject of engine failures, currently there is TestFlightFailure_IgnitionFail which I believe works very well as it takes into account a base reliability in the baseIgnitionChance and then also takes into consideration the external environment in the form of the pressureCurve, though one thing I may suggest here as well is also introducing a temperatureCurve as well. As for the other types of engine failures, such as ShutdownEngine, EnginePerformanceLoss, ReducedMaxThrust, etc, I feel that these should only be induced by certain conditions as well. Maybe you could still have a generic MTBF that would increase the failure chance over time, but only allow failures to occur during the actual operation of the engine.

1) For the pressureCurve keys, what unit exactly is "pressure" measured in? I'd assume it's not barometric pressure, as the numbers in your example seem much too high for that to be the case.. Is it altitude? Also the value appears to be measured between 0 and 1, how exactly is that modifier applied against ignition chance? 2) So if the reliability was at 0.0005 then 1/0.0005 = 2000, what unit would that be? Seconds, Minutes, Hours?

Oh, yeah I suppose that'd make more sense than using "and" due to the issue @Sigma88 mentioned. So by using | I'll be able to edit multiple parts at the same time in the "...do stuff..." part of that, correct?

Quick question, would this work? @PART[part1,part2,part3] { ...do stuff... }

@Agathorn Hey so I've been pretty busy lately and haven't had the chance to look at the configs until now. Just had a few questions that I'm unsure about. 1) What is the deepSpaceThreshold property for the TestFlightCore module? 2) How exactly do the keys in the TestFlightReliability reliabilityCurve effect failure rate? 3) In the TestFlightFailure_IgnitionFail module, how do the keys in the pressureCurve work? 4) I've noticed in several of the keys in your example, there are 2 numbers, where as in other keys there are 4? What is the difference and where do you get the second two numbers from? EDIT: I've just noticed that I forgot to check the posts you've linked.. I'm removing questions from this post as I find the answers to them. EDIT: The one part I'm having the most trouble with, is how do I translate the numbers entered into the reliabilityCurve into a time duration. If the reliability is 0.00015, what would that make the MTBF? EDIT: I've found a very useful post that explains #4 very well.. EDIT: New question, in the TestFlightFailure_ReducedMaxThrust module; If thrustReduction is not specified is the percentage of thrust reduction randomized? I'm just asking because I notice this property mentioned in the documentation, but in the engine config example you've provided above I don't see that property specified.

Ah I see, so kOS doesn't like FAR fins then.. Well that's unfortunate. As far as the stability issues you were seeing in stock, I've played with FAR for a long time and it doesn't seem to have that issue.

@hvacengi Alright so I've done a couple things, I've added the "WAIT 0." line to the end of the until loop and I've also added "PRINT "STEER ERR: " + steeringmanager:angleerror AT (20,1)." into the loop as well. (I've also renamed "currRoll" to "currPitch" as the variable is meant to deal with pitch as you assumed, not roll. Aside from that yes I'm applying the separate 90° roll in order to prevent the rocket from rolling during ascent. Anyways, after changing the script it now looks like this. CLEARSCREEN. SET desAlt TO 55000. SET currPitch TO 0. SET mySteer TO R(0,0,-90) + HEADING(90,90 - currPitch). LOCK STEERING TO mySteer. LOCK THROTTLE TO 1.0. PRINT "Counting Down:". FROM {LOCAL countdown IS 5.} UNTIL countdown = 0 STEP {SET countdown TO countdown - 1.} DO { PRINT "..." + countdown. WAIT 1. } WHEN STAGE:LIQUIDFUEL < 0.1 THEN { PRINT "STAGE.". STAGE. PRESERVE. } WAIT UNTIL SHIP:VELOCITY:SURFACE:MAG > 100. UNTIL SHIP:APOAPSIS > 75000 { IF SHIP:ALTITUDE <= desAlt AND SHIP:ALTITUDE > (desAlt / 90) * currPitch AND currPitch < 90 { SET currPitch TO currPitch + 1. SET mySteer TO R(0,0,-90) + HEADING(90,90 - currPitch). } PRINT "ROLL PROGRAM: " + (90 - currPitch) + "°" AT (20,0). PRINT "STEER ERR: " + steeringmanager:angleerror AT (20,1). WAIT 0. } Upon testing the launch program again using the modified script shown above I've found that when the rocket stops obeying the "currPitch" variable, there IS steering error which means that "currPitch" is being applied to the steering correctly, but the rocket is making no attempt to correct.. I've also used Ctrl+C to abort the program when this happens, only to find that manual control shows that the rocket does have enough control authority to correct the steering error. Here is a link to the craft file: Download Also I'll note that yes, I do use FAR.

Alright I've checked and the controls aren't even trying to move to the new heading... They just seem to stop in a fixed direction for awhile, and then they resume at some point later. The "currRoll" variable is updating correctly, which means the problem has to be something with the steering locking to the "currRoll" variable. I'll try setting the heading in the loop instead of locking it as @Jim DiGriz suggested, and report back.

Oh also another important bit of information.. When the rocket locks the steering, if I end the script and try to turn manually.. It turns just fine. So unfortunately that can't be the problem.

Hello, so I went through the quickstart on the kOS documentation page (here) and have been messing around with modifying the launch script and I've been having a strange problem with it. The rocket I've been using is fairly simple, the center stack has 2 stages (bottom stage has a swivel engine, top stage has a terrier engine) then there are 2 liquid fuel boosters (with reliant engines) on the sides. (no fuel lines, haven't unlocked them yet) The staging is setup to have the boosters lift the vessel until they run out of fuel, and then when the boosters decouple the center stack (swivel) ignites. (Note: The rocket also has winglets so it has steering authority when just the boosters are firing) Alright so first I'll show the script, then I'll explain the problem. CLEARSCREEN. SET desAlt TO 55000. SET currRoll TO 0. SET mysteer TO R(0,0,-90) + HEADING(90,90 - currRoll). LOCK STEERING TO mysteer. LOCK THROTTLE TO 1.0. PRINT "Counting Down:". FROM {LOCAL countdown IS 5.} UNTIL countdown = 0 STEP {SET countdown TO countdown - 1.} DO { PRINT "..." + countdown. WAIT 1. } WHEN STAGE:LIQUIDFUEL < 0.1 THEN { PRINT "STAGE.". STAGE. PRESERVE. } WAIT UNTIL SHIP:VELOCITY:SURFACE:MAG > 100. UNTIL SHIP:APOAPSIS > 75000 { IF SHIP:ALTITUDE <= desAlt AND SHIP:ALTITUDE > (desAlt / 90) * currRoll AND currRoll < 90 { SET currRoll TO currRoll + 1. SET mysteer TO R(0,0,-90) + HEADING(90,90 - currRoll). } PRINT "ROLL PROGRAM " + (90 - currRoll) AT (20,0). } The problem: Alright so as you can see from the script, I use an equation in order to setup various altitudes at which the pitch of the rocket will decrease by 1 degree, in order to create a smooth gravity turn which ends at the "desAlt" value. However what ends up happening is the rocket will go straight up until it stages and the boosters decouple, at which point it will rapidly pitch down until it reaches the pitch angle which matches the "currRoll" value specified in the script. The first thing I though was happening was that the "currRoll" variable wasn't being updated correctly, so I told it to print what the current "currRoll" value was to the console and sure enough, it was updating correctly as the altitude increased. Once I determined the script was updating correctly, and that the rocket simply wasn't doing what it should have been, I thought that I should try replacing the reliant engines on the booster with swivel engines. This of course would make the thrust to weight ratio for the boosters not strong enough to lift the rocket so I had to make the booster tanks a bit smaller. After doing this, the rocket started to obey the "currRoll" variable set in the script and steer accordingly (which doesn't make sense because the winglets should have provided enough steering control when the boosters had reliants on them.) So anyways, at this point the rocket seemed to follow the script perfectly... until it staged the boosters, at which point it just seemed to lock the steering to the point it was at when the staging event happened. After about 10 or 15 seconds suddenly pitched down to match the current "currRoll" variable, and continued to follow it after this point. To be honest I don't understand why this is happening, because the variables that the steering is locked to "mysteer" is properly being updated, but at points the rocket just doesn't seem to want to obey what the script is telling it to do, and just locks to whatever it is currently set to until either the rocket stages, or for some questionably defined period of time after staging.

@Agathorn Alright so in my rush I accidentally grabbed the beta build when testing on stock KSP with just TestFlight installed, but based on my testing I think it's safe to assume that this is also occuring on the current release build as that's what I was using on my main install when I experienced this issue as well. So I'm providing my test save below, there is one ship in orbit with a whole lot of batteries on it.. When you load it up, timewarp for a bit until you see some batteries leaking, then quicksave and quickload and what you'll find is that suddenly the leaking batteries are no longer appearing in the TestFlight window. As a bit of a side note, while testing I found that this would also happen by simply switching away from the vessel (back to the space center) and then back to the vessel. Edit: Almost forgot the link https://dl.dropboxusercontent.com/u/74725194/KSP/TEST.rar

Yes, the minor failures (leaks) existed when I quicksaved and upon reloading that quicksave the TestFlight window no longer showed the failures, though the effects from the failures were still present. Unfortunately I don't have the save file on hand, and I had also removed TestFlight from my install yesterday before I decided to re-write the configs.. Now that I'm thinking about it as well, I'm using a heavily modded install (currently running 96 mods/plugins) so I'm unsure if this could be a conflict of some sort. I suppose what I could do though is start up an unmodded game with just TestFlight installed and see if I can replicate the problem, then I'll get back to you. Actually I'll do that right now so I should have the results within the next half hour or so.

@Agathorn Awesome, thank you for the clarification on the configs as well as the example you've provided. This will definitely help me with re-writing the stock configs to something more usable. As for the batteries your assumption is absolutely correct, TestFlight appears to treat them just the same as fuel tanks. During my flights I've noticed that not only will batteries fail in an explosion, but they can also be afflicted with "leaking" as well. Aside from that, I've found that everything fails very quickly even when I had reached full data units on various parts. The "failureRateModifier" will come in extremely useful when it comes to putting together some configs that don't result in this rapid failure of everything during longer term missions. There was one other thing I noticed as well when I was playing with TestFlight yesterday. After having a particularly catastrophic failure on my vessel, I decided to load the last quicksave and upon doing so I found that the various minor failures that were listed in the TestFlight window before I had made the quicksave seemed to be missing from the display, while the effects from the failures (Leaks and such) were still present on the vessel. Is this a known issue with TestFlight and quicksaving/quickloading?

Oh I see, that'd probably explain why it looks so confusing then. Does anyone know where I would find the patched version of the TestFlight config for RealismOverhaul? It would be immensely helpful so that I can see what exactly the differences are between the Stock and RealismOverhaul configs. EDIT: I think the first thing I'll have to do is either remove or significantly alter the stock configs for fuel tanks... As I've already seen what kind of problems that can cause with my whole exploding batteries issue.

On the note of the configs.. Am I right to assume that "TestFlight_Generic_Engines.cfg" is the TestFlight config file in the RealismOverhaul download? I'm willing to take a shot at re-doing the stock configs, but just looking at the aforementioned file in the RealismOverhaul download for reference I'm super confused. I can see what you mean by the stock ones being crap in comparison. What sort of behavior does the mod have in RealismOverhaul? Based on what you've said, I'm imagining that my issue of batteries exploding left and right is something that shouldn't really be happening; Or wouldn't happen in RealismOverhaul? How hard would you say it'd be to bring the Stock configs up to par? EDIT: Also is the information provided HERE outdated, or am I just missing something? I really do want to try my hand at getting these configs into a better state, as I really would like to use the mod.

What would the general thoughts be on installing this mod on an already existing save? I'm not very far into the save as I've just finished setting up full relay coverage of the Kerbin system (I use RemoteTech) but I've setup this same relay network about 4 times already as I keep finding new mods that warrant a save restart and I'm just sort of getting bored of setting up the same relay network over and over again. If I were to install this into an already existing save what would happen to the satellites that are already in orbit? If anything? EDIT: Alright I've restarted my save just in case and I'm also experiencing the TestFlight button duplication that @Temeter is experiencing, I'm also noticing that the game seems a bit more laggy as well, especially on transitions. (Note the right side of the image) EDIT: Alright so I've found that going back to the last release (version 1.6.0.3) has fixed the issue with the duplicating buttons and lag on transitions, so I think something in the latest release is causing the issues. On a side note I've been playing with this mod all day and while I love the idea of this mod... I've found that unfortunately I just can't do it. I'm the type of person who compulsively reverts/quickloads the moment something goes wrong, as it optimizes my time spent in-game and as you could imagine that type of playstyle mixed with a mod that intentionally makes things go wrong just doesn't really mix that well, as I end up just sort of getting nowhere. Earlier today I got stuck at a sort of roadblock while trying to setup my RemoteTech relay network, as all of my batteries were constantly blowing up due to the large timescales involved with keo-stationary orbits, along with a lack of part testing as I much prefer to go unmanned instead of manned. (Which meant I needed the relay network very early) So with all that being said, as much as I want to use this mod, I'll sadly have to drop it as it doesn't fit my playstyle. I do love the concept of the mod though and hope to see it's continued development in the future. Who knows, maybe eventually my playstyle will change enough that I'll give this mod another go, but for now it's a no go. @Agathorn you're doing a great job with the mod, keep up the good work!

Just wondering, is anybody else having problems getting the kOS button to show up on Blizzy's Toolbar? I tell it to use Blizzy's Toolbar, but it doesn't show up in the "Configure Visible Buttons" list on the toolbar.

@Nils277 Just a heads up that the link to TAC LS has been changed once again, the current link you have in the OP goes to the development thread. Here's the link to the release thread.

Probably a good idea to state that in the OP near the download button, it'll probably save you from having to mention it repeatedly. I'll usually read the last few pages of a mod before I install it, but I know that some people don't and if I hadn't looked then I'd probably end up thinking that something was broken after installing.