BlkBltChemie

Please excuse me if this has been discussed previously - I've skimmed through several pages at the beginning and end of the thread but may have overlooked a discussion on this in the middle of the thread. I noticed that as of Sounding Rockets Version 0.4.3.0, the ISP for the 3 solid rockets dropped quite tremendously to 75 in atmosphere and 100 in vacuum (from 140 and 165 respectively back to Version 0.3.0.0). My hope, and admittedly I just started using this mod, was to be able to achieve a suborbital trajectory with sounding rockets alone in 2-3 stages, but that seems very difficult with the current parameters. Is this a reasonable expectation or should I be looking to the LFO sounding rocket and aerospike? I was also wondering about the 1st and 2nd stage solid rockets which have had identical ISP values since Version 0.2.0.0? The only differences between the two now are amount of fuel, thrust, and obviously mass, but otherwise I'm not seeing an advantage of one over the other contrary to the part descriptions. Thanks for a great series of mods RoverDude and all of your work on stock; really looking forward to the telemetry system!

I'd like to revisit a suggestion posted a couple times back in 2014 (Alshain and DeafFrog) for a map view/tracking station icon to pinpoint the location of the KSC. (Yes, I can spot the KSC peninsula from space no problem; I am aware of the flag trick and have used it many times; and I know you can use Waypoint Manager to place a marker.) Benefits of a Unique Icon: Overcome specific shortcomings of the aforementioned tricks: For people who use cloud mods and cannot necessarily see the peninsula from orbit For early career mode when flag planting is not available For people who don't use the Waypoint Manager mod Setting icon as a target for landing/reentry Setting icon as a target for positioning a geostationary satellite directly over the KSC

One of the things I really like (and this is how I actually started out back in 0.21 before career mode was introduced) is following the "community-developed wikipedia campaign." It is basically a sequence of historically inspired/futuristic missions from first orbit through the moon race and on into shuttles, stations, interplanetary exploration, and even Minmus and Mun bases. In my opinion, the historical sequencing gives the milestone goals you are looking for and helps your program grow throughout the entire system. It is fairly incomplete and I think focuses only on probes for the interplanetary missions, but I just added what I felt were the next logical steps regarding manned exploration. Overall though, it does give more of a program-driven feel instead of one-shot projects. It has been a while and I have since abandoned the save due to new features, but this was in a Sandbox playthrough, although I am kind of interested now in trying this in a heavily adjusted career along the lines of what regex and Geschosskopf suggested. As for mods, you may want to take a look at Strategia which is a program-based overhaul of the Administration Building. I haven't tried it personally because I don't really want to start a new career at this point so I can't really comment on it but I think someone is writing up a playthrough in the Mission Reports subforum. (I'm waiting for the upcoming stock antenna system and then plan on restarting with Strategia, USI-LS, Engineering Tech Tree, and Kerbal Construction Time.)

Do you already have the ship set as the target? If not and you can see the marker or label in flight view - not map view - you should be able to double click the marker to set it as target. (Just a note, the ship labels and markers are toggled by F4 in case you ever don't see them when you think you should.) If you do already have it set as target, you can change the navball setting by left-clicking in the box with the velocity. I'm guessing it currently says "orbital" in the box above the navball with the velocity. That will let you cycle between "orbital," "surface," and "target."

Interesting question. There are a few different ways to answer it in my opinion and I'm sure someone else will come along later with even better ideas. In terms of computing power (this is from the KSP Wiki Community-Developed Campaigns - "Kerbals in Space") the altitude affects timewarp capability as well as graphics. Directly from that link: A station at 120km has a 50x timewarp available, at 160km the graphics for Kerbin downgrades helping to improve resolution and video processing, and at 240km the 100x timewarp is available. Let's think physics now in terms of subsequent rendezvous and docking. Unless you are spot on with your launch, you will need to optimize your closest approach by orbiting faster (lower) than the station if behind or slower (higher) than the station if ahead. If the station is right at 70 km, you don't really have room to go lower so you have to go higher. This could lead to longer times required for intercept and more deltaV expended (since you push you Ap above the station and then have to bring it back down). At the same time, you don't want to go too high since it takes more deltaV to get there in the first place. As for what is optimal, I hope someone else will be able to chime in with more details. In my current save, I have a refuelling station at 80 km so my ships use less deltaV achieving orbit and a "research" station at 120 km for the timewarp.

This is a very good point. I currently have Patents Licensing (science to funds) at 85% and Leadership Initiative at 60%. I actually lose science when I complete a contract now. Not a big deal since the tech tree is complete and I'm just exploring anyway at this point. I'm really only able to profit on contracts (in terms of funds) because I have the Patents Licensing active. So as Streetwind said, if you commit heavily to this, contracts can become burdensome and you really have to focus on the self-driven exploration. (By the way, FlyingPete, I really liked your analogy of this strategy being an allocation to the space program for exploration!) EDIT: I also wanted to add that having Leadership Initiative active conflicts with Aggressive Negotiations - you can't have both active at the same time.

Glad to hear it worked for you; happy to help!

I think you may need to do Fn+Alt+F12 then. Some computer manufacturers have different configurations for the f-keys. For example, F10 can increase the volume, while FN+F10 accesses the F10 function, if that makes sense. (This is most likely the case for yours based on your description. I also had this setup on my HP giving the same problem accessing the debug menu.) In other cases it is reversed where F10 gives the F10 function, while FN+F10 increases the volume. As I said, I had a similar problem with my HP. However, I never could get Fn+Alt+F12 to work to open the debug menu. If that is the case, you can invert the setup from the system bios which I ultimately did. This link gives instruction for how to do this on an HP computer, but it should be similar for most manufacturers. Basically you want to switch the state of the "Action Keys Mode." (So just to explain, with your example FN+F12 currently gives the aerodynamic overlay. If you invert the action keys, you only have to do F12 to give the overlay.)

Thank you both very much. This certainly explains why many of my landers have been over-specification for the mission at hand. Kind of interesting, picking a value everyone already knows in order to use as an arbitrary constant - makes sense when you think about it; thanks for the background.

Just a sanity check so hopefully pretty straightforward: When using the rocket equation to calculate deltaV, the KSP wiki gives deltaV = ln(mass full/mass empty) * Isp * 9.81 m/s^2. The 9.81 m/s^2 corresponds to the surface gravity on Kerbin. For calculations in other SOI's do we need to substitute the local gravity acceleration constant instead? (This is my assumption and it sort of makes sense, but this means the available deltaV changes per celestial body which I am having a hard time wrapping my head around - for example, the same ship would have less deltaV at the Mun than at Kerbin.)

I think this is a good idea and a good solution to the limited number of contract slots available, but I am going to play Devil's Advocate a little bit. You don't have to launch at the transfer window - it is only the optimal time to launch. There is no in-game information regarding optimal transfer windows so having contracts tied to launch windows creates a black box scenario where you can't see why something is happening. (Granted, this may change - and I hope it does - with the KSPedia or perhaps with mission planning tools in future updates.) If you go in order of launch windows, your first (and most frequent) contracts will be for Moho, which is not where you want a beginner to plan their first interplanetary mission. With the new contextual contracts, you'd need an exception to still allow contracts to generate outside transfer windows. (This sounds like a nightmare to program although I know nothing about coding.) Personally, I would like to see all of the "Explore" contracts available at the start of the game - this is sort of solved with the milestones which allow you to sort of ignore contracts. I think that your suggestion though may be a good idea for satellite or related contracts. The bigger thing, however, is that I really think this needs to be coupled with some sort of mission planning tool to help players know why optimal transfer window is approaching.

I really like the idea of a budgeted financial system as discussed here and elsewhere, but this is the first time I've seen a suggestion for the budget being tied to a specific mission. Personally I think it is a fantastic idea, and it seems like a good compromise between having contract only funding versus a full-on time-based system with a periodic program budget.

Still getting used to the new format, but I have to say I really like the Kerbal Space Program logo white on blue in the banner across the top. I think I may actually like it a little more than the original red text on white background! I also liked the white on black for the 1.0 release and the white on planet for 1.0.5 more too!

This is a really cool idea! I especially like the suggested bonuses for making it more worthwhile, in particular the additional reputation for visiting sites not in the original itinerary (which would be very useful for the multi-tourist missions where each one wants to go somewhere else).

Good thoughts here Kergarin. I have to say I really like the new milestones system especially the breadth of opportunities; I'm always disappointed when I miss a World's First contract. It also really gives more flexibility to your space program and returns to the sandbox feel of KSP which is why I got into it in the first place - every save can be whatever you want. Overall I agree and would like to see the World's First contracts merged into milestones; however, the milestones should absolutely be more visible as suggested here and in a couple other threads. It makes me think back to when the World's Firsts contracts were first introduced alongside the "Explore" contracts. So, for example, you could have the 4-part "Explore the Mun" contract and alongside you get a series of World's Firsts to flyby, orbit, return, land, etc. It felt really redundant to me because you were essentially getting paid twice, which is very similar to the milestones and World's Firsts now. (Side note: Are the "Explore" contracts still in 1.0.5? I haven't upgraded my career save.) Now that I think about it more, however, the World's First contracts do give more of a targeted progression while milestones are more in the background (currently). Standard contracts are generally stand-alone (this is less of the case now with contextual contracts), but the World's First give more long term objectives to guide the player. Maybe an expanded version of the "Explore" contract with all of the corresponding milestones grouped together...hmm this almost sounds like a 180 from what I said in the first paragraph. (Maybe just having the milestones more visible will satisfy this role of long-term progress.)

-------------------------------- Interim Report C – Gravity Turn -------------------------------- Things are really starting to come together in the launch optimization process and I finally have a code that I (mostly) like for a true gravity turn! This also incorporates the staging and throttle control from the previous interim reports. In Missions 01 and 02, I used a sequence of WHEN/THEN triggers to turn over x degrees at y altitude; however, with the 1.0 aerodynamics, I wanted to use a true gravity turn without locking steering. The basic profile is to launch with steering locked vertically – I use (0,90) to keep the launch orientation, then (90,90) to rotate once it clears the launch clamps. At 50 m/s, I lock the steering to (90,85), allow a few seconds to stabilize, and then unlock steering for the rest of the flight. [spoiler=] CLEARSCREEN. //Setup SET SHIP:CONTROL:PILOTMAINTHROTTLE TO 0. //Thanks to Steven Mading on the KSP forum for this override of the default 50% throttle on launch SET twr to 1.6. //Change as needed depending on vessel design LIST ENGINES IN MyList. PRINT "All systems go for launch!". PRINT " ". WAIT 2. SET runmode to 1. //Flight Control UNTIL runmode = 0 //Runmode format based on code found at https://gist.github.com/KK4TEE/c41b4fb789a01cef6122 { FOR eng IN MyList { IF eng:flameout { LOCK THROTTLE TO 0. LOCK STEERING TO SHIP:FACING. //May not be needed depending on craft design PRINT "Decoupling Stage " + stage:number. PRINT " ". STAGE. WAIT 1. STAGE. LIST ENGINES in MyList. PRINT "Stage " + stage:number + " activated!". PRINT " ". UNLOCK STEERING. } } IF runmode = 1 //Launch Sequence { STAGE. FOR eng IN MyList { SET tmax to eng:maxthrust. } SET g to KERBIN:MU / ((KERBIN:RADIUS + SHIP:ALTITUDE)*(KERBIN:RADIUS + SHIP:ALTITUDE)). SET t to twr*(SHIP:MASS*g). LOCK THROTTLE TO t/tmax. LOCK STEERING TO HEADING(0, 90). PRINT "Main engine ignition!". PRINT " ". WAIT 2. STAGE. PRINT "Launch clamps disengaged!". PRINT "WE HAVE LIFTOFF!!!". PRINT " ". WAIT 2. LOCK STEERING TO HEADING(90, 90). //Potentially add a wait here for large vessels with less control authority (SAS/RCS) SET runmode to 2. } ELSE IF runmode = 2 //Gravity turn { IF SHIP:VERTICALSPEED > 50 //Change as needed depending on vessel design { LOCK STEERING TO HEADING(90, 85). PRINT "Commencing gravity turn.". PRINT " ". WAIT 3. UNLOCK STEERING. SET runmode to 3. } } ELSE IF runmode = 3 //Throttle control { FOR eng IN MyList { IF eng:ignition AND NOT eng:flameout //Need this because stowed/flameout give maxthrust = 0 { SET tmax to eng:maxthrust. } } SET g to KERBIN:MU / ((KERBIN:RADIUS + SHIP:ALTITUDE)*(KERBIN:RADIUS + SHIP:ALTITUDE)). SET p to VECTORANGLE(ship:facing:vector, ship:up:vector). //90-p = angle above horizon, p = angle from straight up; Formula from https://github.com/KSP-KOS/KOS/issues/664 SET teff to twr*(SHIP:MASS*g). SET t to teff / COS(p). LOCK THROTTLE TO t/tmax. //Change as needed depending on vessel design (or omit??) WHEN SHIP:ALTITUDE > 12000 THEN //11.5 km -> 0.1 atm { SET twr to 1.3. } WHEN SHIP:ALTITUDE > 24000 THEN //23 km -> 0.01 atm { SET twr to 1.0. } IF SHIP:APOAPSIS > 100000 { LOCK THROTTLE TO 0. LOCK STEERING TO PROGRADE. PRINT "Suborbital trajectory achieved.". PRINT "Current AP: " + round(SHIP:APOAPSIS). PRINT " ". SET runmode to 0. } } } SET SHIP:CONTROL:PILOTMAINTHROTTLE TO 0. WAIT UNTIL SHIP:ALTITUDE > 70000. Challenge 1 was adjusting the throttle control because as the rocket pitches over, not all of the thrust goes to counteracting gravity. The effective thrust then, can be calculated by thrust(eff) = thrust * cosine(pitch angle). The real challenge was calling the pitch angle because SHIP: PITCH returns something else because of the original kOS design. Fortunately, I found a command that computes the angle between the SHIP:FACING and SHIP:UP vectors, which corresponds to the pitch from vertical. So with thrust(eff) = twr*(mass*g), where g is a function of altitude, and thrust = thrust(eff)/cos(angle), I can still adjust the throttle by thrust/maxthrust. Now it is a function of both altitude and angle. (Essentially, it throttles down with increasing altitude and up with increasing angle.) I’m not sure if I like this but I included a couple triggers to change the desired twr at 12 km and 24 km which correspond to 1/10 and 1/100 sea level pressure. It does give a shallower trajectory once leaving the thickest part of the atmosphere and also avoids temperature indicators appearing. I’m still experimenting with this part of the code. Challenge 2 was dealing with staging which gave me a lot of trouble – (a) when an engine is stowed or out of fuel, it returns a maxthrust of 0 meaning I was trying to divide by 0 for throttle = thrust/maxthrust which breaks the code. This was easy to fix by adding an if loop to only set tmax to maxthrust if the engine had been activated and was not flameout. ( Harder to fix was the rocket flipping out during staging. I locked throttle to 0 during staging so it wasn’t trying to use the last throttle from the launch stage. I also played around with a temporary steering lock and then unlocking again after the engine ignited. Unfortunately, without fins on the upper stage, the craft always flipped out. After adding fins, I actually didn’t have to add the temporary steering lock for the 1.25 m design. If locked to SHIP: PROGRADE, the craft actually started flipping again, but SHIP:FACING or SHIP:HEADING kept the upper stage on course. For the 2.5 m design, I did have to lock the steering, and SHIP:FACING worked best. The images below using SHIP:FACING for both designs. I think it is interesting how different the final trajectories are in map mode as well as when different events occurred. I may still need some more optimizations to improve the general applicability.Another big change was changing to a runmode format to separate the steps of the mission. I adapted the basic outline from a and the corresponding code.Next Up: Optimizing orbital circularization using some suggestions given previously. I’m really looking forward to comparing the efficiency of the launch to the Mission 02 code. Since this will return to an ordinary mission report, I’ve uploaded the code and craft files from the interim reports to Dropbox. (I have a separate save for the optimization testing from my standard missions - to explain any inconsistencies with file naming.) Code and Craft Files: Interim A-C

Ah, great question! 50 m/s is when I start my gravity turn on Kerbin. I was thinking ahead to my next optimization step. It is actually going well so far - still in need of some polishing though. (Preview: I have set up a TWR 2 launch until I get to 50 m/s then drop the TWR to 1.5 as I start the gravity turn and begin taking into account pitch angle. At least for the craft I'm currently testing, with steering unlocked after an initial 5 degree pitch over it hits 45 degrees right at 20,000 m.) Also, I am not planning on using this particular code for takeoff from every celestial - mainly because I call the planet's mu, radius, etc to calculate g. Sorry, not sure I followed this - the staging stops when the ship is out of fuel. I see the no fuel at all primarily as a limitation for potential refuelling missions - I don't want to stage if I have a tanker ready to rendezvous and refuel. As for parachutes (and fairings for that matter), I'm leaning more towards using action groups. I may not be reading this correctly, but I think I am having the engine tell me its thrust (well max thrust) at a given altitude/pressure. The thrust I'm calculating is the thrust I need to obtain my target TWR. But like I said, maybe I am misreading/misunderstanding something here.

------------------------------------ Interim Report B: Throttle Control ------------------------------------ The next step, after having worked out a better method for staging, is to start improving launch efficiency by controlling the throttle. Working on this was kind of fun for me as a chemist, because I never really delved that deeply into physics or orbital mechanics. The basic idea is to control the throttle by keeping a constant thrust-to-weight ratio. TWR = thrust/(mass*gravity) -> thrust = TWR*(mass*gravity) A few things to keep in mind: Ship mass changes as fuel is burned TWR increases (mass decreases) [*]Gravitational acceleration changes with altitude TWR increases (gravity decreases) [*]Post KSP 1.0, engine thrust changes with altitude TWR increases (thrust increases, usually) [*]In a gravity turn, not all of the thrust is used to counter gravity so the TWR is defined by the effective thrust. (I will not get into this for current report and will save it for next time.) TWR decreases (more thrust is horizontal so less fights gravity) To do this, I need to loop calculations of mass, gravity, and thrust. At 100% throttle, the thrust = max thrust of the engine so if I have a target TWR in mind, I calculate the thrust needed (above) and the ratio of thrust/max thrust gives me the throttle setting I need. The math and resulting code are below: Universal Law of Gravitation: F = G(m1m2)/r2 When one body is much larger: g = -GM/r2ȓ (vector) Standard Gravitational Parameter: μ = GM r = radius + altitude Magnitude of g = μ/(radius + altitude)2 We can either use this formula at each altitude or we can use: gh=g0 (r/(r+h))2 LIST ENGINES IN MyLIST. FOR eng IN MyList { SET tmax to eng:maxthrust. } UNTIL SHIP:LIQUIDFUEL < 0.1 { IF SHIP:VERTICALSPEED > 50 { SET g to KERBIN:MU / ((KERBIN:RADIUS + SHIP:ALTITUDE)*(KERBIN:RADIUS + SHIP:ALTITUDE)). SET t to 2*(SHIP:MASS*g). //Change 2 to desired TWR LOCK THROTTLE TO t/tmax. SET twr to t/(SHIP:MASS*g). PRINT "maxthrust = " + round(tmax) + ", thrust = " + round(t) + ", TWR = " + round(twr,2) + ", Throttle = " + round(throttle,2). PRINT " ". } } WAIT 5. The big question, for me anyway was will this work for different designs, and the answer is yes! Ok, so where I had the most trouble was tying in my code for staging - the problem was that when I staged, the maxthrust was reported as 0 so throttle = t/tmax was trying to divide by 0 which doesn’t work so I went back to relisting the engines after I staged. I have something that finally works but feedback here would definitely be great (particularly if there is an alternative to using the two FOR loops), because it does not seem very optimal to me, but then again, I’m still pretty new at this. LIST ENGINES IN MyLIST. UNTIL SHIP:LIQUIDFUEL < 0.1 { FOR eng IN MyList { IF eng:flameout { PRINT "Decoupling Stage " + stage:number. PRINT " ". STAGE. WAIT 1. STAGE. LIST ENGINES IN MyLIST. PRINT "Stage " + stage:number + " activated!". PRINT " ". WAIT 1. } } FOR eng IN MyLIST { SET tmax to eng:maxthrust. PRINT eng:name + ", " + round(eng:maxthrust). PRINT " ". } IF SHIP:VERTICALSPEED > 50 { SET g to KERBIN:MU / ((KERBIN:RADIUS + SHIP:ALTITUDE)*(KERBIN:RADIUS + SHIP:ALTITUDE)). SET t to 2*(SHIP:MASS*g). //Change 2 to desired TWR LOCK THROTTLE TO t/tmax. SET twr to t/(SHIP:MASS*g). PRINT "maxthrust = " + round(tmax) + ", thrust = " + round(t) + ", TWR = " + round(twr,2) + ", Throttle = " + round(throttle,2). PRINT " ". WAIT 1. } } WAIT 5. Next up: Gravity turn! (I’m hoping to do a true gravity turn where I do an initial pitch over and then unlock the steering and let gravity and throttle control do the rest. I’m really curious to see how well the code I’ve written here works especially after I modify it to account for the effective thrust.)

Thanks for the tip! I had originally tried using if "eng:flameout" in Mission 02, but it did not work which is why I added "= true" here. I just ran a test without "= true" and this new script worked just fine. Unfortunately I don't have a copy of the older code that did not work so there must have been something else wrong. I wonder...I don't think I put the "if" loop inside an "until" loop so maybe it was just checking once and then done since it was false. Anyway, it works now so thanks! Next up: I almost have throttle control worked out and will probably do another interim report for that as well.

--------------------------- Interim Report A: Staging --------------------------- The last few evenings, I have been working on optimizing the staging code I used in Mission 02. In that program, I used: [spoiler=] WAIT UNTIL SHIP:LIQUIDFUEL < 90.1. PRINT " ". PRINT "...Stage 1 exhausted, activating Stage 2.". LOCK THROTTLE TO 0.0. WAIT 0.5. STAGE. PRINT "...Stage 1 separation complete.". WAIT 0.5. LOCK THROTTLE TO 0.6. WAIT 0.5. STAGE. PRINT "...2nd stage ignition successful!". PRINT " ". Since the WAIT UNTIL command is a sequential design, it could potentially be disastrous if placed in the wrong part of the overall code. This drastically limits its applicability to different designs. From the kOS documentation on design patterns, two alternatives are setting up loops either for condition checking (IF/ELSE) or for triggers (WHEN/THEN). I have seen several examples using both types of loops for autostaging based on parameters like fuel level, change in maxthrust, and engine status. I generally like to separate my decoupler and engine activation into two stages with a small time delay between. Since you can’t WAIT in a WHEN/THEN loop, I focused on using an IF loop to check for conditions. Fuel levels are occasionally unreliable for STAGE:RESOURCE (sometimes KSP and consequently kOS adds the fuel of the next stage), so I really wanted to use engine status. As I said in the Mission 02 post, I actually tried using a check for engine flameout, but couldn’t get it to work. The (partial) code was: [spoiler=] LIST ENGINES IN MyList. FOR eng IN MyList { IF eng:flameout {[INDENT] . . . } [/INDENT] I defined the parameter to check but forgot to state what condition I want it to check – ENG:FLAMEOUT can be true or false. After much trial and error I finally have a staging code I am pretty happy with based on when the engine cuts out: [spoiler=] LIST ENGINES IN MyList. UNTIL STAGE:NUMBER = 0 { FOR eng IN MyList { IF eng:flameout = true { PRINT "Decoupling Stage " + stage:number. PRINT " ". STAGE. WAIT 1. STAGE. PRINT "Stage " + stage:number + " activated!". LIST ENGINES IN MyList. WAIT 1. } } } (Note: Right now, I am only working with a single, central stack – if I use boosters or asparagus staging, I’m sure I will need to adjust this.) In addition to actually setting the ENG:FLAMEOUT check condition, it took me a while to figure out that I needed to relist the engines after staging within the loop. (I thought I remembered reading somewhere that the engine was automatically removed from the list after being decoupled?) If it is not included in the IF loop, the program uses the original list and will continue to stage since ENG:FLAMEOUT is still true for the decoupled engine. I am actually kind of proud about how I did the troubleshooting to discover that by printing ENG:IGNITION and ENG:FLAMEOUT each loop (not included in the above code). I’m not entirely sure about the condition I have for the UNTIL loop. Let’s consider two cases: Case 1 = a satellite that decouples without an engine (i.e. Stage 0 is just a decoupler). Case 2 = a Mun lander (i.e. Stage 0 is a decoupler + engine). If the second engine cuts out in Case 1, it automatically decouples the satellite, which is something I don’t really want – I would rather do that on my own. I can simply change to: [spoiler=] UNTIL STAGE:NUMBER = 1 { . . . } This works but isn’t general enough for any design, but only changing 1 character isn’t too bad. I also tried testing for when the ship is out of fuel: [spoiler=] UNTIL SHIP:LIQUIDFUEL < 0.1 { . . . } This does not automatically detach the satellite and works for both the probe and Mun lander cases! However, if the ship never runs out of fuel (leftover fuel after achieving orbit/landing) the loop will never end. (I suppose this is also true for the IF loop as the engine would never flameout either.) So with either UNTIL condition, I need to go back and add a BREAK condition to exit the loop. For the BREAK condition (landed/in orbit), my instinct is saying that it needs to be part of the UNTIL loop (not the IF or FOR loops), right? In Case 1 for the satellite, I may want to stay in the loop until I finish orbital maneuvers…is it ok to just let a small loop keep running indefinitely? If, later in the code, I manually decouple the satellite after finalizing the orbit, will the loop automatically end since it the longer has engines attached or will it throw an error? If an error, is there a way to say IF MyList = empty {break.}? (Sorry for the pseudo-code.) [*]At this point, I am not sure which (if either) condition for the UNTIL loop is better? ----------------------- UPDATE (9/23/2015): ----------------------- I just discovered that if I move LIST ENGINES IN MyList into the UNTIL loop, that I do not have to relist the engines as part of the IF loop! [spoiler=] UNTIL STAGE:NUMBER = 0 { LIST ENGINES IN MyList. FOR eng IN MyList { IF eng:flameout { PRINT "Decoupling Stage " + stage:number. PRINT " ". STAGE. WAIT 1. STAGE. PRINT "Stage " + stage:number + " activated!". WAIT 1. } } IF SHIP:APOAPSIS > 200000 { BREAK. } } And I was also right - the BREAK condition worked in the parent UNTIL loop!

Thanks! I can see how taking an iterative approach to a set tolerance can cause the code to blow up. I really appreciate the comments explaining what the example code is doing. I understand how "trueanomaly" specifies the angle before/after Pe when I looked through some of the kOS documentation after reading this post. I'm a little confused though as to the "obt" part of the call. Is that just shorthand for "orbit?" That also sounds like a useful way to warp to a specific point in the orbit. You could set trueanomaly to the desired value and use an until loop to warp there, correct? This actually sounds pretty similar to some examples I have seen that rely on a change in the maxthrust, particularly for asparagus staging. I've been working on my staging script the last couple evenings. I think I almost have it so I will post an interim report a little later after some more testing tonight.

Thanks! Definitely a pretty steep learning curve, but I'm having fun! And the help is definitely appreciated! Great idea! I had completely forgotten about the fuel routing change. I ran a test for oxidizer yesterday, but it ran into the same problems, unfortunately. I need to look at some more recent examples for a good approach to auto-staging. Aha, I was wondering when the rocket science would come into play! Thanks for the excellent explanation and general overview - I'll give this a few more read-throughs, take a look at some examples, and then give it a shot! I've been delving some more into the kOS documentation and it looks like there is actually a command to call for the orbital period so this should be pretty easy! (I just didn't know where to start.) Thanks again for the great suggestions and explanations! I think I should be able to sort out circularization and orbiting now and have looked at quite a few examples for gravity turns. Now if only I can smooth out the staging...

------------------------------- Mission 02: Orbital Test Probe ------------------------------- Objective: Launch a two-stage, liquid-fueled rocket to deploy a probe in a stable orbit. Report: I made a couple modifications to the craft used in the previous mission by adding a second stage with an LV-909 engine. I also remembered to add a reaction wheel to keep the Stayputnik probe oriented after I decouple it. The launch was pretty much the same (although I did add the line of code from Steven Mading to sort out the default throttle issue). The first stage was decoupled at 32 km. Orbital insertion was started 8 seconds before apoapsis at full throttle and gave a final orbit of 81 km x 85 km. Finally I had the probe timewarp until its electric charge was expended (the probe doesn’t have any solar panels) – did not quite make a full orbit. Analysis: Because I really wanted to try to achieve orbit, I used the same launch code I had programmed for the previous mission instead of working on any optimizations. I had a lot of trouble getting the conditional statements right for staging (see below). The circularization code required a lot of trial and error and I’m not really happy with how it ended up. My first try was to lock heading to prograde and burn 5 seconds before apoapsis, but that gave me a highly elliptic orbit and I ran out of fuel before the periapsis was high enough. I played around with when I started the burn – various times between 5 adn 15 seconds before apoapsis – and ultimately settled on 8 sec which gave a fairly circular orbit. This isn’t a very good solution, in my opinion, since it will only work for this craft and required a lot of trial and error. (I really want to get to the point of making my code more generally applicable to different designs and knowing it will work at launch instead of relying on trial and error.) Room for Improvement: Since I used more or less the same code as for the suborbital mission, and as r_rolo1 commented above, there is definitely room for improvement in the (not really a) gravity turn sequence. The plan is to try to use an if-else if loop to vary the throttle while keeping a constant TWR after an initial pitch over once speed is greater than 50 m/s. Specifically for this mission I want to work on the code for staging and circularization (see below). What I used worked, but like I said above only for this ship. Questions: So...staging. I know there are some issues if the decoupler and engine are in the same stage – you can’t use STAGE:LIQUIDFUEL<0.1 because KSP for some reason adds the fuel that is in the next stage up. (I did try with them in the same stage as well as in separate stages; neither worked.) It will work with STAGE:LIQUIDFUEL < 90.1 (for this craft), but I went with SHIP:LIQUIDFUEL instead just because. I tried using LIST ENGINES to check for FLAMEOUT – not sure if I wrote the code incorrectly or what but I just could not get that to work. (I also could not get an IF loop to work and ended up using WAIT UNTIL, which is really unreliable.) Any suggestions? (Related, when do I need to use PRESERVE?) Next, what is the best way to circularize such that Ap and Pe have minimal deviation? There are several variables – when you start the burn, how much thrust you use, and where you aim. When I manually burn in my stock save, I start aiming below the horizon (before Ap), move to prograde at the apoapsis, and then continue above the horizon (after Ap). Is there a way to write a code for this (or another option for precision circularization)? Finally, is there a good way to code something like “warp ahead this many complete orbits?†Code and Craft File: Mission 02 Next Mission: Optimization! (This one will probably be a little while in the making since it will take some more research and lots of testing on my part.)

Good point and very true! So yeah in 1.0.0 I had no trouble manually pitching over about 5-10 degrees at 50 m/s, turning off SAS and letting my rocket fly itself to orbit with throttle adjustments. Not so much in 1.0.2/1.0.4. I've had to use SAS more again and input a lot more manual control authority. I'm not sure if it is something to do with drag being increased (as I recall) in 1.0.2. You were also spot on, with the step function. The prograde marker generally lagged about 5-10 degrees behind the pitch angle. The gravity turn is definitely something I want to work on. A lot of examples I've looked over are using a variety of different loops: mostly if-else if. I really want to try to tie it to throttle instead of altitude/pitch angle as that will resolve both problems in one go - the gravity turn and the TWR issues - and make the code more generally applicable instead of just working for this craft. Yep, I think there are a few of us here! All science majors had to take one computer science class at my undergrad and since I was a double major of Chemistry and Math, I had to take a second one for the Math. The most fun was the final where we had to use a pseudo-random number generator to code paper-rock-scissors and be able to "play" against the computer. I think one of my calculus classes used Matlab and another one used Maple. Never really liked either. For PChem we used Mathematica which was by far my favorite.

Fantastic! Thanks for the tip and explanation of how it works! I certainly agree - not sure what the motivation was behind setting the default throttle on launch to 50%.