baloan

I tried it. It exists for all bodies, like Kerbin, Mun, .... Apologies for the inaccuracy. No SHIP:POSITION and no VESSEL:POSITION.

I'd like to claim 3 points for a Kerbin orbit for the Kerbal Robotic Mission Project. After polishing the LaunchToOrbit, Atmosphere script we now are able to accurately and reliably launch to low Kerbin orbits. In a historic mission Orbiter 3 launched to orbit. Enclosed find proof of the endeavor. The LaunchToOrbit script and the mission toolkit v2 has been published on the kOS wiki.

Yep, if you are in Kerbin orbit and print SHIP:POSITION:MAG it should be equal to Kerbin's radius + ALTITUDE. And by "You can move the origin" I mean that you subtract SHIP:POSITION from all BODY:POSITION vectors. That way you end up with position vectors relative to Kerbin then being at V(0,0,0).

There is also a BODY:POSITION vector for every body and vessel. The origin V(0,0,0) is your ship and all POSITION vectors are relative to the origin. You can move the origin to Kerbin or Kerbol in order to calculate angles between bodies. Btw, Mun has no inclination relative to Kerbin equator so it pretty easy. Inclination is little bit more difficult.

Misunderstanding on my side: I thought warp was not allowed in scripts.

Strange bug. I am locking steering using this script - and sometimes it works, sometimes not. Is there any known workaround? Can the "usual suspects" reproduce this and open a bug ticket? declare parameter ya,pi,ro. // rotate ship to yaw, pitch, roll and wait print "T+" + round(missiontime) + " Turning to expose solar panels...". print "T+" + round(missiontime) + " Set steering to R(" + ya + "," + pi + "," + ro + ")". print "". print "". print "". print "". print "". sas off. lock steering to R(ya,pi,ro). print "Steering: " + steering. until abs(sin(steering:pitch) - sin(facing:pitch)) < 0.01 and abs(sin(steering:yaw) - sin(facing:yaw)) < 0.01 { print "Prograde: " + prograde at (0,31). print " Facing: " + facing at (0,32). print "Steering: " + steering at (0,33). } unlock steering. sas on. print "T+" + round(missiontime) + " Done.". EDIT: This seems to work lock fset to R(ya,pi,ro). lock steering to fset.

because I'd like to submit my ltoa (launch to orbit, atmosphere) script. The script uses various subroutines from my mission toolkit - is that an issue? and claim 3 points: Establish a stable orbit around any body (excluding Kerbol) for reaching an orbit around Kerbin.

The challenge is a Great Idea! Question: 1. How do I submit a candidate? Post the code? Post screenshots? Comment: 2. Interplanetary transfers are dependent on the timing and where the planets are. I am not sure how planets and moons are located in a new game but to make sure the script does not rely on those externally given timings I'd ask all contenstants' scripts to start only after a wait random(sidereal rotation period of the target planet/moon), random(...) providing a number between 1 and the argument. That way the target body will be in an arbitrary position on its orbit when the script starts. 3. I disagree on the use of warp when its only use is to bridge thrustless time between two maneuver burns. As long as it is transparent to Kerbal engineers whether a wait passes the time or actually warps there. In my scripts you could replace warpfor(dt) by wait dt and the behavior wouldn't change - just the real time to get there. 4. Does it make sense to add a "Docking" challenge?

encounter works in conjunction with a NODE. IMHO it makes sense to have SHIP:ENCOUNTER and NODE:ENCOUNTER, SHIP:ENCOUNTER: PERIAPSIS and NODE:ENCOUNTER: PERIAPSIS, SHIP:ENCOUNTER: PERIAPSIS:ETA and NODE:ENCOUNTER: PERIAPSIS:ETA to fine tune injection maneuvers while being out of SOI of the target body. Easy for Mun equatorial injections, I am wondering what else is need to control a polar orbit injection (or arbitrary inclination injections). [is there any way to avoid : P to be converted to a in this editor?]

I have upgraded the warp script but found something strange. When assigning warp to a variable oldwp and later comparing warp to oldwp kOS throws an error. Not all warp levels are allowed according to this table. You can find out when checking warp which shows the actual warp level. So if you run this script in a 200km orbit you should see level 4 instead of level 6. declare parameter t1. // warp (0:1) (1:5) (2:10) (3:50) (4:100) (5:1000) (6:10000) (7:100000) // min alt atmo atmo atmo 120k 240k 480k 600k set dt to t1 - time:seconds. if dt < 0 { print "T+" + round(missiontime) + " Warning: wait time " + round(dt) + " is in the past.". } if dt >= 21600 { print "T+" + round(missiontime) + " Waiting for " + round(dt/21600) + "d" + mod(round(dt),21600) + "s". print "T+" + round(missiontime) + " Wait start @ " + time:calendar + ", " + time:clock. } set oldwp to "0". until time:seconds >= t1 { set rt to t1 - time:seconds. // remaining time set wp to 0. if rt > 5 { set wp to 1. } if rt > 30 { set wp to 2. } if rt > 300 { set wp to 3. } if rt > 600 { set wp to 4. } if rt > 6000 { set wp to 5. } if rt > 60000 { set wp to 6. } if rt > 600000 { set wp to 7. } set warp to wp. if warp != oldwp { print "T+" + round(missiontime) + " Warp " + warp + ", remaining wait " + round(rt) + "s". set oldwp to warp. } wait 0.5. } if dt >= 21600 { print "T+" + round(missiontime) + " Wait complete @ " + time:calendar + ", " + time:clock. } First time into the loop warp is compared to "0" -> works fine. Second time into the loop warp is compated to oldpw -> error. I'd expect to be able to compare oldwp to warp. Bug or am I missing something? Note: warpfor calls warpto.

I like the video. The altitude issue seems to be a little fuzzy. To make sure the script could orbit over the landing site defined by longitude and latitude and record altitude and alt:radar. Deorbit burn and landing to be done on the next pass - now ground level altitude is known as a fact. This adds aiming for a landing site as a complication, especially if the landing site is not at the equator, though.

I am trying to run a master script for my mission. // mission control script // prepare kOS storage switch to 1. copy bdp.txt from 0. copy far4.txt from 0. copy per1.txt from 0. // switch to 2. copy apo1.txt from 0. copy nod1.txt from 0. copy warp.txt from 0. // conduct mission run far4. run per1(mun:altitude). run nod1. but I get: Missing feature or am I missing something?

Updated bdp.txt on the wiki to correct rb. The original naming was for Kerbin (rk) but I extended the script to work with other bodies as well. Consequently it is no longer radius of Kerbin rk but radius of body rb. The warp script is not fully symmetric but it should work. I saved the effort of cloning the initial warp factor setting for warp 1 to 3.

I've uploaded the maneuvering scripts to the kOS wiki. Features: 1. add maneuver node at periapsis for changing apopsis altitude (more fuel efficient) run per1(mun:altitude). 2. add maneuver node at apoapsis for changing perapsis altitude, for example to cirularize an orbit: run apo1(apoapsis). 3. node execution script. The script will â—¾ turn the ship to node:deltav (and it has a nice workaround to detect when done) â—¾ warp to the maneuver node â—¾ burn full throttle, then â—¾ for accurate deltav throttle down nearing burn end. run nod1. Uses these helper subroutines: 4. Wait for dt seconds. Warps automatically. Covering warp levels up to 5 (3000 seconds). run warp(dt). 5. Sets a body's properties global variables: â—¾ Gravitational parameter mu â—¾ body radius rb currently works for Kerbin, Mun and Minmus. The constants are used in the apo1 and per1 scripts. run bdp(Kerbin).

Just found out the script only works when starting from a circular orbit. I didn't notice because I circularized for orbit insertion. Let me check whether I can generalize it for arbitrary orbits. The problem is that r and velocity:orbit:mag must correspond to calculate energy. In a circular orbit that is true throughout - and I used that in the formula. Bear with me. Apologies for the inconvenience caused. EDIT: Try this apoapsis maneuver node creator. Need yet to clone for periapsis maneuvers. I've also created a warping node chaser which I will upload to kos wiki shortly. Run it with the desire altitude, for example to create a circular orbit node: run apo(apoapsis). declare parameter alt. // create apoapsis maneuver node print "T+" + round(missiontime) + " Apoapsis maneuver, orbiting " + body. print "T+" + round(missiontime) + " Apoapsis: " + round(apoapsis/1000) + "km.". print "T+" + round(missiontime) + " Periapsis: " + round(periapsis/1000) + "km" + " -> " + round(alt/1000) + "km". // constants set mu to 3.5316000*10^12. // mu = G mk, mk: mass of Kerbin set rk to 600000. // radius of Kerbin set rm to 200000. // radius of Mun // present orbit properties set vom to velocity:orbit:mag. // actual velocity set r to rk + altitude. // actual distance to body set ra to rk + apoapsis. // radius in apoapsis set va to sqrt( vom^2 + 2*mu*(1/ra - 1/r) ). // velocity in apoapsis set a to (periapsis + 2*rk + apoapsis)/2. // semi major axis present orbit // future orbit properties set r2 to rk + apoapsis. // distance after burn at apoapsis set a2 to (alt + 2*rk + apoapsis)/2. // semi major axis target orbit set v2 to sqrt( vom^2 + (mu * (2/r2 - 2/r + 1/a - 1/a2 ) ) ). // setup node set deltav to v2 - va. print "T+" + round(missiontime) + " Apoapsis burn: " + round(va) + ", dv:" + round(deltav) + " -> " + round(v2) + "m/s". set x to node(time:seconds + eta:apoapsis, 0, 0, deltav). add x. print "T+" + round(missiontime) + " Node created.". // workaround for scientic numbers bug on load set mu to 0.

Works for me: print "Currently in sphere of " + body. // find deltav to move apoapsis target altitude // use energy invariance to calculate deltav // by changing vp to vp' the semi major axis changes from a to a' // 0.5*vp^2 - mu/r + 0.5*mu/a = 0.5*vp'^2 - mu/r + 0.5*mu/a' // vp'^2 = vp^2 + mu( 1/a - 1/a' ) set mu to 3.5316000*10^12. // mu = G mk, mk: mass of Kerbin set rk to 600000. // radius of Kerbin set rm to 200000. // radius of Mun set r to rk + periapsis. set a to rk + apoapsis. // semi major axis current orbit // set a2 to (r + rk + mun:altitude)/2. // semi major axis target orbit set a2 to (r + rk + 2868750)/2. // semi major axis target orbit set vom to velocity:orbit:mag. set v2 to sqrt( vom^2 + (mu * (1/a - 1/a2) ) ). set deltav to v2 - vom. print "v2: " + round(v2). print "deltav: " + round(deltav). set x to node(time:seconds + eta:periapsis, 0, 0, deltav). add x. // workaround for scientic numbers bug on load set mu to 0. There is a 1% error in altitude compared to the inputs. This might be caused by the script or the way maneuver node system works. Btw, vom^2 + (mu * (1/a - 1/a2) ) should only ever become small when a2 is close to 0. In physics terms a2 does never get smaller than (rk+altitude)/2 that is when periapsis gets close to the center of earth and your radial velocity vp' gets close to 0 (no more kinetic energy). The major axis then extends from your ship to the center of kerbin then, i.e. rk+altitude.

Just worked out how to calculate deltav for changing orbit altitudes. So if your issue is calculating deltav from an existing orbit try this: // find deltav to move apoapsis target altitude // use energy invariance to calculate deltav // by changing vp to vp' the semi major axis changes from a to a' // 0.5*vp^2 - mu/r + 0.5*mu/a = 0.5*vp'^2 - mu/r + 0.5*mu/a' // vp'^2 = vp^2 + mu( 1/a - 1/a' ) set mu to 3.5316000*10^12. // mu = G mk, mk: mass of Kerbin set rk to 600000. // radius of Kerbin set rm to 200000. // radius of Mun set r to rk + periapsis. set a to rk + apoapsis. // semi major axis current orbit set a2 to (r + rk + mun:altitude)/2. // semi major axis target orbit set vom to velocity:orbit:mag. set v2 to sqrt( vom^2 + (mu * (1/a - 1/a2) ) ). set deltav to v2 - vom. print "v2: " + round(v2). print "deltav: " + round(deltav). set x to node(time:seconds + eta:periapsis, 0, 0, deltav). add x. // workaround for scientic numbers bug on load set mu to 0. Replace mun:altitude by your target altitude. When using a 100km orbit, 90km target altitude I get a -11.8m/s burn, and the maneuver node calculator estimates an 87.5km periapsis. That is 3% error in altitude, much smaller when looking at the semi axis (~687km instead of 690km). Not sure at what accuracy you want to hit your altitude. Btw, my node chaser script has not been tested (i.e. will not work) with changes of deltav < 2 maxthrust/mass.

@willow: Thanks for your hint which got me thinking about the steps to be taken: node chaser: that is part of the ascent script that I uploaded to the kOS wikia (here). Now that subroutine programs are available I should be able to refactor a standalone module. circularization: Needs to find the correct place for maneuver nodes in arbitrary orbits. Something like: establish_orbit(periapsis, apoapsis)and establish_circular_orbit(altitude). And yes, the script should find a solution with good fuel economy. docking: you want to be able to combine parts for an interplanetary transfer. Currently no rcs thruster support for translation (forward, backward, etc. see here) Hohman transfer: Changing orbit to Mun is easy: establish_orbit(ship:periapsis, rk + mun:altitude). The difficult part is to hit the launch window for the burn so that Mun is actually there when I arrive at apoapsis. I am playing around to find those for a Kerbin Mun transfer. The only way to find an "encounter" seems to be to brute force traverse node times. This might be feasible for Kerbin-Mun, but not for interplanetary transfers where searching for an encounter will take much longer - or will be impossible due to inclination (which is currently not supported. see here). interplanetary transfers: without planetary positions relative to their "parent" body, i.e. Kerbol for planets or Kerbin for Mun/Minmus, I cannot calculate transfer windows (relative body positions are currently not supported). As mentioned above, playing around with a node parameters until finding an encounter seems unrealistic - no wonder, space is mostly void and empty; very empty.

@Mossman: You are of course right. But I am using burntime/2 to determine when to start the burn. The error introduced by not exactly centering the burn around the maneuver node should be small. (Incorrectly calculated) burn time in my configuration is ~ 40sec. It'd be interesting to see what the error is - and what effect this has on orbit configuration (apoapsis vs periapsis error). And to mess timing up: I throttle my engine during the last few seconds to be able to shutdown accurately and exactly hit deltav. That extends burn time and wrecks any calculation assuming full thrust all the time.

WHEN BCount < 99 THEN PRINT BCount + “ bottles of beer on the wallâ€Â. Check whether all when statements have a "then". Regards, Andreas

Which might look like this: // calculate maneuver properties // Errors in calculation: a) velocity points upward, traveling to apoapsis // causes horizont to turn "down". Calculation is correct only at apoapsis. // Thus burn parameters are adjusted while travelling to apoapsis. set maxda to maxthrust/mass. print "T+" + round(missiontime) + " Max DeltaA for engine: " + maxda. set vom to velocity:orbit:mag. set dv to (ov - vom). set tfb to dv/maxda. print "T+" + round(missiontime) + " DeltaV for final burn: " + dv. print "T+" + round(missiontime) + " Duration of final burn: " + tfb. set x to node(time:seconds + eta:apoapsis, 0, 0, dv). add x. // warp only when alt:radar > 50000 then { set warp to 2. } when eta:apoapsis < tfb/2 + 30 then { set warp to 0. } lock steering to x. // iteratively correct burn parameters until eta:apoapsis < tfb/2 { set vom to velocity:orbit:mag. set dv to ov - vom. set tfb to dv/maxda. set x:prograde to dv. print "DeltaV for final burn: " + dv at (0,29). print "Duration of final burn: " + tfb at (0,30). wait 1. } print "T+" + round(missiontime) + " DeltaV for final burn: " + dv. print "T+" + round(missiontime) + " Duration of final burn: " + tfb. // lock steering to node:prograde which wanders off at small deltav when x:deltav:mag < 2 * maxda then { print "T+" + round(missiontime) + " Reducing throttle, fuel:" + stage:liquidfuel. // continue to accelerate x:prograde unlock steering. sas on. } print "T+" + round(missiontime) + " Orbital burn start " + round(eta:apoapsis) + " s before apoapsis.". set th to 1. lock throttle to th. until velocity:orbit:mag > ov { set thrust to maxthrust * throttle. set da to thrust/mass. set newth to x:deltav:mag * mass / maxthrust. if x:deltav:mag < 2 * da and newth > 0.2 { set th to newth. } print "Thrust: " + thrust at (0,28). print "DeltaA: " + da at (0,29). print "Node DeltaV: " + x:deltav:mag at (0,30). } lock throttle to 0. remove x. print "T+" + round(missiontime) + " Orbit complete, apoapsis: " + apoapsis + ", periapsis: " + periapsis.

@willow: Actually I was collecting which modules might be worth implementing: 1. create kOS modules a) ascent w/ (Kerbin) w/o atmosphere (Mun) c) orbit circularisation d) descent & landing w/ and w/o atmosphere e) Mun transfer f) interplanetary transfers g) docking and then there are some kOS challenges: 2. send satellites to each planet & moon 3. land rovers on each planet & moon 4. land & return manned missions but also some problems which are currently unsolved: 5. how to operate rcs for maneuvering? 6. how to align for interplanetary transfers? (requires planetary coordinates relative to the sun)? 7. how to run multiple missions simultaneously? Autonomous engine burns? Can kOS run in the background? 5. to 7. are feature requests. Regards, Andreas KSP 0.22.0 with kOS 0.9.1 - nothing else.

@Stiggles: I get repeatable circular orbits with 1% error. My recipe works by designing your burn to exactly reach the orbital velocity for the orbit. Then the maneuver node and the burn must exactly provide deltav up to the orbital velocity. Step by step: 1. calculate orbital velocity: set ov to (G * mk / r)^0.5. with G: gravitational constant, mk: Kerbin mass, r: radius of orbit, r = 600000 + apoapsis 2. There is no good way to determine your velocity at apoapsis while coasting there. I continuously recalculate velocity:orbit:mag - ov until the burn starts. 3. When does the burn start? Well, half of the burn time before apoapsis so you distribute your deltav around apoapsis evenly. 4. How long is your burn? You know your deltav and the acceleration your engine(s) provide (which is deltav per second). Engine acceleration a is F/m (force by mass), set maxA to maxthrust/mass, and then set burnduration to deltav / maxA. 5. During the end of the burn the node target indicator will wander off as deltav gets close to 0. In order to avoid uncontrolled gearing I unlock steering and turn on sas to keep the ship stable. I uploaded my script and craft to kOS Wiki for reference. Regards, Andreas far2.txt orbiter2.craft PS: There is an issue with unlocking steering in the end. The script retains the NODE locked earlier while on the console it can be unlocked. Any workaround?

I am having issues with setting up a new node some time in the future. With previous versions it was like this: set x to node(time+60,0,0,1000). to define a maneuver node 60s in the future with a 1000m/s prograde burn. Now I get Supplied parameter 'time+60' is not a number.. Did 0.9.1 mess up with types? Regards, Andreas