Nadrek

Correct; that is data that shows at least one fuel bug. After 0.17 comes out, anyone who wants can install Mechjeb [for long enough] to run it, and see if there are other, less blatantly obvious fuel bugs affecting particular rockets. Regrettably, my current technique is very simple, and only works in space. You can do it yourself, if you wish: Circularize your orbit. Bring your rocket to x% thrust; give it some time to be there. Deactivate staging. Measure the amount of orbital velocity change and starting and ending mass over an amount of time. Do math.

To expand a little on Peewee's absolutely correct "run it in a coroutine" message (and do look at the example he provided! Coroutines in lua are essentially a separate execution thread - they're a routine (function) that, in the simplest form, you tell to go off and start asynchronously, and it does whatever it wants while you continue to do whatever you want - you don't wait for it (much like starting a program in *nix with & afterwards - it runs in a separate process). So, if you want a constantly updated gauge or meter, a coroutine is great. If you want to have a light blink on and off forever, or based on something, a coroutine is great. If you want to interact with the code in the coroutine bidirectionally... not so simple. Now, when you get your Autom8 lua window, whatever you do there is done _in the main game process_. So if you say "wait()", then the entire game waits. If you put the wait() in a coroutine, then that coroutine spawns a new process/thread, and that thread waits... but since you didn't wait for the coroutine, you don't see any wait. Therefore, whatever you're waiting for needs to wait for the wait() (i.e. be synchronous with it, be in the same process/thread)... and to not stall out the game, that _entire package_ needs to be executed asynchronously with the game, i.e. in a coroutine. So, we have: function DoStuffDriver stuff wait() stuff end function coDoStuff .. end And in the main Autom8 window, you'll call coDoStuff(), and you'll see the results of any print() statements, but you can't really control it anymore without a lot more work - you kick it off and let it run. If it goes wild, get out to the main Start Game screen and go back in. Note that my SimpleSKPOrbitalOperations Isp finding coroutine is also an example, but less clear.

My condolences on Jeb. Once the family is done grieving, talk to his brother Jeb, also an excellent pilot. And thank you for the applause; the experimental measurements have three major advantages over the parts file. First, they allow those who look at the code to see the actual math involved. Second, they don't care how many engines of what specific impulses you have on rocket. Third, they are _actually_ accurate within a reasonable margin of error... unlike the Parts file in 0.16, which lies! For example, an LV-T45 on a rocket starting the test at approximately 13.3 tons: At thrust: 10% Isp is: 3490.6740910247 Used 0.407934188842773 kg fuel, for 1.05126962080158 DeltaV, or 2.57705691151756 DeltaV per kg fuel and 1.40169282773544 DeltaV per second At thrust: 20% Isp is: 1797.90199416966 Used 1.45530700683594 kg fuel, for 1.9319236255069 DeltaV, or 1.32750245579261 DeltaV per kg fuel and 2.57589816734253 DeltaV per second At thrust: 30% Isp is: 1215.11984362804 Used 3.66973876953125 kg fuel, for 3.29362980189717 DeltaV, or 0.897510697285376 DeltaV per kg fuel and 4.39150640252956 DeltaV per second At thrust: 40% Isp is: 903.884828955461 Used 6.70003890991211 kg fuel, for 4.47590106928692 DeltaV, or 0.668041056099723 DeltaV per kg fuel and 5.96786809238256 DeltaV per second At thrust: 50% Isp is: 725.654721031727 Used 10.1935863494873 kg fuel, for 5.47232665973979 DeltaV, or 0.536840173038317 DeltaV per kg fuel and 7.29643554631972 DeltaV per second At thrust: 60% Isp is: 608.021967457222 Used 14.2822265625 kg fuel, for 6.43367939469454 DeltaV, or 0.450467535054168 DeltaV per kg fuel and 8.57823919292605 DeltaV per second At thrust: 70% Isp is: 521.458302751379 Used 20.519495010376 kg fuel, for 7.94516284354404 DeltaV, or 0.387200700578959 DeltaV per kg fuel and 10.5935504580587 DeltaV per second At thrust: 80% Isp is: 460.325639631327 Used 26.8013477325439 kg fuel, for 9.1855244198191 DeltaV, or 0.342726213304021 DeltaV per kg fuel and 12.2473658930921 DeltaV per second At thrust: 90% Isp is: 410.633801563746 Used 33.0276489257813 kg fuel, for 10.1319807593941 DeltaV, or 0.306772691636706 DeltaV per kg fuel and 13.5093076791921 DeltaV per second At thrust: 100% Isp is: 370.224071690755 Used 41.8767929077148 kg fuel, for 11.6319489877646 DeltaV, or 0.277765993527688 DeltaV per kg fuel and 15.5092653170195 DeltaV per second

To do these tests, you'll want to set Mechjeb Auto-throttle off and your throttle to 100%, go back to 0.15.2, or just wait for 0.17, since the 0.16 fuel bug (25% fuel at 50% thrust, 1% fuel at 10% thrust, etc.) will really do a number on any attempts at efficiency tests.

For pictures, please don't upload then in a Microsoft Excel format (much less an Excel 2007+ format) - .jpg or another picture format would be better. Remember, not everyone has Excel or something good to read them, and Excel is expensive. For spreadsheets, Libreoffice (http://www.libreoffice.org/) is at least free and available for Windows, Mac, and Linux.

I've used SVN to a small extent; if a reference for basic check in/out, making copies, and doing so based on label name (not tip) in git is linked to, I'd be more than happy to use it as well as pastebin. I don't have any real preference between source control repositories - for a selection of individual scripts like these, with one or maybe two authors apiece, there's no compelling reason to choose one modern source control method over another. I would say make sure there are Windows, Mac, and Linux instructions.

Excellent work, Peewee - you're definitely ahead of me for this area; I'll catch up at some point, though I have a lot of other functions to write first. For everyone that's interested, below is a newer lua/Autom8 function from my SimpleKSPOrbitalMechanics script that will print out a large portion of the information available to us from any of the Orbit classes (the vessel.orbit* references still exist, but if you like, you can replace vessel.orbit with <your orbital object>, which I'm going to do myself for my report* function, because then you can use it for your own vessel (as this does), or any target vessel or body, or even a specific body or vessel not being targetted. Grand Lander, the basic steps in simply using Autom8 are easy. If you want to see basic vessel control, the FlyMeToTheMun script from the first page of this thread is an excellent, simple starting point. Start KSP, and get a Mun lander with Mechjeb ready on the launchpad. Either copy and paste the contents of that script into the Autom8 window's bottom text bar, or save it in %KSP%\PluginData\mumechlib as "FlyMeToTheMun.lua" and then type in that same bottom Autom8 text bar: require "FlyMeToTheMun" Then type in that bottom Autom8 text bar: FlyMeToTheMun(30,30) And read through the "print()" statements in the script as it runs; you can then start to figure out the code controlling your rocket. If you want something more detailed and to learn more about lua, some of the other scripts in this thread are better - you can start with SimpleOrbitalMechanics for pure Autom8 math, or SimpleOrbitalOperations for pure operational use (Molniya style orbits, for example). That's post #53 in this thread (http://kerbalspaceprogram.com/forum/showthread.php/16503-MechJeb-Autom8-Scripts-Megathread?p=238962&viewfull=1#post238962) function printSkomKSPCurrentOrbitalElements() -- returns nothing. --[[ Ex. printSkomKSPCurrentOrbitalElements() ]] print("name string " .. mechjeb.core.part.vessel.name) print("orbitApA meters " .. vessel.orbitApA) print("orbitApR meters " .. mechjeb.core.part.orbit.ApR) print("orbitPeA meters " .. vessel.orbitPeA) print("orbitPeR meters " .. mechjeb.core.part.orbit.PeR) print("orbitPeriod seconds " .. vessel.orbitPeriod) print("orbitTimeToAp seconds " .. vessel.orbitTimeToAp) print("orbitTimeToPe seconds " .. vessel.orbitTimeToPe) print("orbitLAN (RA/Long of Ascending Node) degrees " .. vessel.orbitLAN) print("LAN degrees " .. mechjeb.core.part.orbit.LAN) print("orbitArgumentOfPeriapsis (APe) degrees " .. vessel.orbitArgumentOfPeriapsis) print("orbitLongitudeOfPeriapsis (LPe) degrees " .. calcSomLpeFromLanApe(vessel.orbitLAN, vessel.orbitArgumentOfPeriapsis)) print("orbitInclination degrees " .. vessel.orbitInclination) print("orbitEccentricity (e) " .. vessel.orbitEccentricity) print("orbitSemiMajorAxis (a) meters " .. vessel.orbitSemiMajorAxis) print("meanAnomaly radians 0 to 2pi " .. mechjeb.core.part.vessel.orbit.meanAnomaly) print("meanAnomalyAtEpoch radians (KSP 0.16 BUGGED == meanAnomaly) 0 to 2pi " .. mechjeb.core.part.vessel.orbit.meanAnomalyAtEpoch) print("epoch seconds " .. mechjeb.core.part.orbit.epoch) print("time seconds " .. vessel.time) print("StartUT seconds " .. mechjeb.core.part.orbit.StartUT) print("GetUniversalTime seconds " .. script.call("Planetarium.GetUniversalTime")) print("trueAnomaly degrees 0 to 360 " .. mechjeb.core.part.orbit.trueAnomaly) print("eccentricAnomaly radians 0 to 2pi " .. mechjeb.core.part.orbit.eccentricAnomaly) print("pos[1] position vector ?x? ?? " .. mechjeb.core.part.orbit.pos[1]) print("pos[2] position vector ?x? ?? " .. mechjeb.core.part.orbit.pos[2]) print("pos[3] position vector ?x? ?? " .. mechjeb.core.part.orbit.pos[3]) print("vel[1] velocity vector ?x? ?? " .. mechjeb.core.part.orbit.vel[1]) print("vel[2] velocity vector ?x? ?? " .. mechjeb.core.part.orbit.vel[2]) print("vel[3] velocity vector ?x? ?? " .. mechjeb.core.part.orbit.vel[3]) print("semiMinorAxis meters " .. mechjeb.core.part.vessel.orbit.semiMinorAxis) print("semiLatusRectum meters " .. mechjeb.core.part.vessel.orbit.semiLatusRectum) print("speedOrbital m/s " .. vessel.speedOrbital) print("orbitalSpeed ?? not the same as vessel.speedOrbital " .. mechjeb.core.part.orbit.orbitalSpeed) print("orbitalEnergy " .. mechjeb.core.part.orbit.orbitalEnergy) print("speedSurface m/s " .. vessel.speedSurface) print("speedVertical m/s " .. vessel.speedVertical) print("speedHorizontal m/s " .. vessel.speedHorizontal) print("vesselHeading degrees " .. vessel.vesselHeading) print("vesselPitch degrees " .. vessel.vesselPitch) print("vesselRoll degrees " .. vessel.vesselRoll) print("altitudeASL meters " .. vessel.altitudeASL) print("altitudeTrue meters " .. vessel.altitudeTrue) print("altitudeBottom meters " .. vessel.altitudeBottom) print("core altitude meters " .. mechjeb.core.part.vessel.altitude) print("latitude degrees " .. vessel.latitude) print("longitude degrees " .. vessel.longitude) print("vessel orbit radius meters " .. vessel.radius) print("core orbit radius meters " .. mechjeb.core.part.orbit.radius) print("localg m/s " .. vessel.localg) print("atmosphericDensity " .. vessel.atmosphericDensity) print("ObT ?? " .. mechjeb.core.part.vessel.orbit.ObT) print("ObTAtEpoch ?? " .. mechjeb.core.part.vessel.orbit.ObTAtEpoch) print("SEVp ?? " .. mechjeb.core.part.orbit.SEVp) print("SEVs ?? " .. mechjeb.core.part.orbit.SEVs) print("fromE ?? " .. mechjeb.core.part.orbit.fromE) print("fromV ?? " .. mechjeb.core.part.orbit.fromV) print("E ?? " .. mechjeb.core.part.orbit.E) print("V ?? " .. mechjeb.core.part.orbit.V) print("toE ?? " .. mechjeb.core.part.orbit.toE) print("toV ?? " .. mechjeb.core.part.orbit.toV) print("UTappr ?? " .. mechjeb.core.part.orbit.UTappr) print("UTsoi ?? " .. mechjeb.core.part.orbit.UTsoi) print("referenceBody.name string " .. mechjeb.core.part.orbit.referenceBody.name) if mechjeb.core.part.orbit.referenceBody.name == "Kerbin" then print("referenceBody full name string KSP_Galaxy1_Kerbol_Kerbin") elseif mechjeb.core.part.orbit.referenceBody.name == "Mun" then print("referenceBody full name string KSP_Galaxy1_Kerbol_Kerbin_Mun") elseif mechjeb.core.part.orbit.referenceBody.name == "Minmus" then print("referenceBody full name string KSP_Galaxy1_Kerbol_Kerbin_Minmus") elseif mechjeb.core.part.orbit.referenceBody.name == "Sun" then print("referenceBody full name string KSP_Galaxy1_Kerbol") end print("ClAppr ?? only nonzero when closestEncounterBody ~= nil " .. mechjeb.core.part.orbit.ClAppr) print("ClEctr1 ?? only nonzero when closestEncounterBody ~= nil " .. mechjeb.core.part.orbit.ClEctr1) print("ClEctr2 ?? only nonzero when closestEncounterBody ~= nil " .. mechjeb.core.part.orbit.ClEctr2) print("CrAppr ?? only nonzero when closestEncounterBody ~= nil " .. mechjeb.core.part.orbit.CrAppr) print("EndUT " .. mechjeb.core.part.orbit.EndUT) print("eccVec[1] eccentricity vector ?x? ?? " .. mechjeb.core.part.orbit.eccVec[1]) print("eccVec[2] eccentricity vector ?y? ?? " .. mechjeb.core.part.orbit.eccVec[2]) print("eccVec[3] eccentricity vector ?z? ?? " .. mechjeb.core.part.orbit.eccVec[3]) print("FEVp ?? " .. mechjeb.core.part.orbit.FEVp) print("FEVs ?? " .. mechjeb.core.part.orbit.FEVs) print("h[1] ?? " .. mechjeb.core.part.orbit.h[1]) print("h[2] ?? " .. mechjeb.core.part.orbit.h[2]) print("h[3] ?? " .. mechjeb.core.part.orbit.h[3]) print("mag ?? " .. mechjeb.core.part.orbit.mag) if mechjeb.core.part.vessel.orbit.closestEncounterBody ~= nil then print("closestEncounterBody.name " .. mechjeb.core.part.vessel.orbit.closestEncounterBody.name) end print("orbitPercent " .. mechjeb.core.part.orbit.orbitPercent) if mechjeb.core.part.orbit.previousPatch ~= nil then -- Orbit class print("previousPatch.semiMajorAxis (a) meters " .. mechjeb.core.part.orbit.previousPatch.semiMajorAxis) print("previousPatch.inclination degrees " .. mechjeb.core.part.orbit.previousPatch.inclination) end if mechjeb.core.part.orbit.nextPatch ~= nil then -- Orbit class print("nextPatch.semiMajorAxis (a) meters " .. mechjeb.core.part.orbit.nextPatch.semiMajorAxis) print("nextPatch.inclination degrees " .. mechjeb.core.part.orbit.nextPatch.inclination) end print("nearestTT ?? " .. mechjeb.core.part.orbit.nearestTT) print("nextTT ?? " .. mechjeb.core.part.orbit.nextTT) print("objectType string " .. mechjeb.core.part.orbit.objectType) print("sampleInterval ?? " .. mechjeb.core.part.orbit.sampleInterval) print("timeToTransition1 ?? " .. mechjeb.core.part.orbit.timeToTransition1) print("timeToTransition2 ?? " .. mechjeb.core.part.orbit.timeToTransition2) -- ?? FUTURE ADD TimeSincePeriapsis, angular momentum, end

Until you ask KSP where the Apoapsis or Periapsis of a circular orbit is, or the time to them. Or want some of the orbital elements of a circular, equatorial orbit using an equation that assumes an elliptical orbit... or a non-equatorial circular orbit. I'm finding all kinds of fun special cases.

Do not despair! It appears that mechjeb.core.targetVessel mechjeb.core.targetBody mechjeb.core.part.vessel .orbit .referenceBody local Orbits = script.call("Planetarium.Orbits") Orbits. are all direct interfaces to the KSP mod system, while vessel. is an abstraction layer/interface/wrapper that the Mechjeb team wrote for the Autom8 module. Thus, there is choice inherent in the system - choose the Autom8 abstraction, which is more limited but which is, I suspect, more likely to remain consistent version to version, or choose the more direct KSP interface, which is fuller featured, but more likely to change (and, apparently, nearly completely undocumented as far as I can tell - I'm adding what I find to the SimpleKSPOrbitalOperations.lua file, and to this thread). Also, what was the answer to FindAn(orbit, tgttorbit) - can you post sample code, please, so we can all learn more?

I'm working through much the same things - the trig I haven't used in a long, long time, physics likewise, and orbital mechanics I've never studied in detail. I've found searching the Web to be extremely limited; orbits can be circles, ellipses, parabolas, or hyperbolas. Unfortunately, most orbital equations I can find are simplified to either circles or ellipses (but not both). Arrowstar recommends the Vallado (http://www.amazon.com/Fundamentals-Astrodynamics-Applications-David-Vallado/dp/1881883140) third edition, with erratta (http://celestrak.com/software/vallado-sw.asp) - I won't have a copy for another couple weeks. I'm documenting as much as I learn and code in the Autom8 thread (post #53 and after) for others - SimpleOrbitalMechanics is lua code (equations are very readable) for basic orbital equations; it doesn't depend on KSP or Mechjeb Autom8 at all (you could run it with lua on Linux, or Lua for windows (http://code.google.com/p/luaforwindows/) or just read the equations and notes. Learning the geometry seems a pre-req for the Keplerian orbital elements. Some web references I've used are: http://what-when-how.com/remote-sensing-from-air-and-space/a-few-standard-orbits-orbital-mechanics-interlude-remote-sensing/ http://www.braeunig.us/space/orbmech.htm http://www.faqs.org/faqs/space/math/ https://en.wikipedia.org/wiki/Orbital_period https://en.wikipedia.org/wiki/Rocket_equation https://www.earthobservatory.nasa.gov/Features/OrbitsCatalog/ https://en.wikipedia.org/wiki/Semi-major_axis https://en.wikipedia.org/wiki/List_of_mountains_on_the_Moon https://en.wikipedia.org/wiki/Standard_gravitational_parameter https://en.wikipedia.org/wiki/Sphere_of_influence_%28astrodynamics%29 https://en.wikipedia.org/wiki/Standard_gravity https://en.wikipedia.org/wiki/Gravitational_constant https://en.wikipedia.org/wiki/Kepler_orbit

If you get them into orbit, I've got a Mechjeb Autom8 module that has a function to experimentally calculate Isp in post #53 of the Autom8 megathread at http://kerbalspaceprogram.com/forum/showthread.php/16503-MechJeb-Autom8-Scripts-Megathread?p=238962&viewfull=1#post238962 One function does the calculation, and another actually will circularize your orbit and execute a set of burns (1 to N) to calculate Isp at different throttle settings, so you'd want just 1 for the burn. To use it, get into orbit, make sure you've got only SRB's of the same type* in the stage you're on, and then in the Autom8 window: require "SimpleKSPOrbitalOperations" cotestSkooIspFromTmbiTmbtwnNsMpcs(2, 15, 1, 0.02) The function definition and notes, if anyone cares, are: cotestSkooIspFromTmbiTmbtwnNsMpcs(TimeBeforeInitial, TimeBetweenEach, NumberSlices, MaxPointingChangeStable) -- MaxPointingChangeWeCallStable is the maximum degrees of change in heading + pitch -- we'll call "stable" for purposes of detecting when mechjeb.attitudeTo() is done -- i.e. 0.2 means 2/10ths of a degree change during TimeBetweenEach seconds -- This is a wrapper that circularizes our orbit, verifies -- a stable orbit, orients prograde, and then runs the Isp test -- NOTE: This is designed to be run asynchronously to vessel control. -- NOTE: This will only work anywhere close to properly with a small TimeBetweenEach, -- in a circular orbit, with the vessel held in prograde or retrograde directions. -- TimeBeforeInitial is the "spool up" delay in seconds we're going to use -- this is how much time we think it takes our engines to come to stable thrust -- i.e. 0.5 means set thrust to the desired value, then wait half a second, then start the measurement for this "slice" -- For the bell rocket engines in 0.16, 0.25 is a reasonable minimum for TimeBeforeInitial -- TimeBetweenEach is the time in seconds between initial and final measurements for each "slice" -- For the bell rocket engines in 0.16, 0.25 is a reasonable minimum for TimeBetweenEach -- NumberSlices is how many slices we're going to divide our thrust into, i.e. -- 1 means 100 (100% max thrust) / 1 = one test at 100%. -- 2 means 100/2 = 50% for the first test, and 100% for the second. -- 4 means 100/4 = 25% for the first test, 50% for the second, 75% for the third, and 100% for the fourth. -- Nothing is returned per se, but the Specific Impulse, kg mass lost, and Delta-V per mass is printed at each slice for human consumption. -- While we could use the Skom reporting functions, because we need initial and final mass -- instead of just differences, this is almost easier and is certainly simpler to understand. *I've never tried this, but it should work - if they don't automatically fire, set a large initial delay (the first number) and fire them "by hand" when it throttles up

For Kerbin ascent, I have no idea; I wasn't good enough at rocket design in 0.15 to think that ascent settings mattered more than rocket design, and the 0.16 fuel bug prevents any meaningful efficiency comparisons. For ascent from any body with no atmosphere, lift off and do your gravity turn as soon as you aren't going to hit a mountain or cliff! There's no atmosphere to worry about. Always burn to the inclination you want in the first place.

Relating to "I didn't see an easy way to launch from, say, Minmus (or an arbitrary orbit), and then use Kerbin to give a grav assist to another body ouside the Kerbin system (say, Eve)" I agree that this isn't something that works within the two body model. However, given that you've worked out an iterative solution already, what about a nested iterative solution? I.e calculate a spread of two body problems (say, the end first - going to Eve), and then for each of those, calculate a spread of two body problems (say, the beginning - using Kerbin as a grav assist). Determine the aggregate best out of the spread, and then iterate a new spread around that. Or whatever other iterative technice is preferred, of course; this was merely a poor example.

Based on further experimentation, here's additional information on the vector based mechjeb.attitudeTo, for those planning to terrify their kerbals during more complex orbital manuevers with Mechjeb's Autom8: mechjeb.attitudeTo({x,0,0},"ORBIT") ?Where x < 0, NML+ ?Where x > 0, NML- mechjeb.attitudeTo({0,x,0},"ORBIT") ?Where x < 0, RAD- (to body) ?Where x > 0, RAD+ (Away from body) mechjeb.attitudeTo({0,0,x},"ORBIT") Where x < 0, RETROGRADE Where x > 0, DIRECT (PROGRADE) mechjeb.attitudeTo({x,0,0},"INERTIAL") ?Where x < 0, ?? ?Where x > 0, ?? mechjeb.attitudeTo({0,x,0},"INERTIAL") ?Where x < 0, ?? ?Where x > 0, ?? mechjeb.attitudeTo({0,0,x},"INERTIAL") Where x < 0, ?? Where x > 0, ??

First, if anyone corrects me, you should probably pay attention to them. But, based on my knowledge thus far: Molniya, Tundra, and _eostationary orbits all are designed to provide coverage over specific surface locations. They all operate on the premise that the sidereal orbital period is a specific fraction of the sidereal rotation period; i.e. your orbit moves at a specific rate compared to the surface. Tundra and _eostationary orbits have a SOP (Sidereal Orbital Period) equal to the SRP (Sidereal rotation period). Molniya orbits have a SOP exactly 1/2 the SRP. Note that your Sidereal orbital period is equal to: 2pi * (a^3/GM)^0.5 Where a is the semi-major axis of your orbit (half the distance from periapsis to apoapsis, including going through the body you're orbiting) And GM is the standard gravitational parameter So, the altitude of the _eostationary orbit is based on the SOP (how long it takes to go all the way around the orbit from the point of view of other stars) - since it's a circular equatorial orbit, the semi-major axis is equal to the distance from the center of the planet to your spaceship, all the time. With this, you can calculate the orbital period, and if your orbital period is 6 hours, you're at the right distance. If you're at the right distance in a circular orbit, you must therefore be at the right speed to keep falling and missing the planet by the same amount all the time (i.e. orbiting).

Thank you, maltesh. I do have to ask, then, what are the _defining_ parameters of a Molniya orbit? When I was looking at I, I thought the defining parameters were 1) orbital period 1/2 sidereal rotation rate of the body being orbited 2) Inclination set to zero out oblate body perturbations (116.6 or 63.4 degrees) 2a) Alternate: for perfect spheres, coverage far from the equator (high or low latitudes) 3) As large as is practical Apoapsis loiter, i.e. a "highly eccentric" orbit with a Periapsis as close to the body as is deemed safe/desirable. I didn't think any _particular_ eccentricity was required or even important; just because Earth Molniya orbits use Ecc 0.74 doesn't mean you'd stick with 0.74 around a planet Earth's size with a dramatically different density, does it? Thus, for Kerbal, my lua (via Mechjeb Autom8) calculations show a pretty tight Molniya orbit around Kerbin to be 70000.0000007m Periapsis and 3099882.16762357m Apoapsis, assuming 70km as a hard floor for Periapsis. Example of elements from a ship in a slightly safer Molniya orbit: > require "SimpleKSPOrbitalOperations" > printSkomKSPCurrentOrbitalElements() orbitApA 3091223.15732252 orbitPeA 75180.8230804288 orbitPeriod 10785.3686006449 orbitTimeToAp 2324.66911005364 orbitTimeToPe 7717.35341037608 orbitLAN (RA/Long of Ascending Node) 213.427100427749 orbitArgumentOfPeriapsis (APe) 219.071721398138 orbitLongitudeOfPeriapsis (LPe) 72.4988218258869 orbitInclination 63.3747757462778 orbitEccentricity 0.690738270649006 orbitSemiMajorAxis (a) 2183201.99020147 speedOrbital 772.447710561223 speedSurface 933.959438086068 speedVertical 447.721196680242 speedHorizontal 819.649902264227 vesselHeading 262.950357055664 vesselPitch -24.3717094421387 vesselRoll 28.5230310440063 altitudeASL 2589812.40431608 altitudeTrue 2589411.90915805 altitudeBottom 2589411.90915805 latitude 15.5475476988583 longitude 61.1391499060891 radius 3189852.69837219 localg 0.3470805440598 atmosphericDensity 0 time 8428218.41378137 For the Mun, I calculate that an Apoapsis of 2429999.9999757m and a Periapsis of 1328033.84149341m is about as close as we can come to a Molniya orbit; it's going to have a much lower loiter time, but it's still a 1/2 sidereal (I think; I'm still trying to get a solid answer on the Mun's sidereal rotation rate) rotation rate, eccentric orbit, and thus it'll still show up over the same spot on the surface every other Apoapsis, and spend more than half the time over it. How much more, I don't yet know the math to figure out, so I can't tell you how many more satellites per constellation are required... but I believe it can be done over the Mun. For Minmus, I get an Apoapsis of 2712999.99997287m and a Periapsis of 2664532.22551369m, so it's technically a Molniya orbit, but the loiter time is going to be barely, barely more than a circular orbit would have, so yes, practically, Minmus doesn't have a very useful Molniya available. My constants may be wrong, of course. P.S. With some help from r4m0n, the mechjeb.core.targetBody.orbit.* parameters will give me the Keplerian orbital elements except True Anomaly/Mean Anomaly at Epoch, and I don't yet see anything to get me sidereal rotational period (and I don't expect to find end of atmosphere/highest mountain, Hill sphere of influence, or sidereal rotation rate out of them, though sidereal rotation rate would be most excellent for Molniya calculations).

Excellent - thank you, r4m0n! I was able to determine many of the relevant values by guesswork. Unfortunately, in any of the .cs files, looking for even "orbitalSpeed" did not turn up anything other than part.vessel.orbit.getOrbitalSpeedAt(timeLeft), which I couldn't figure out in Lua by guesswork. Is there another place to look for the contents of the C# Vessel (and Body) object? I'm sorry for the basic questions. If anyone else can use it, here's a list of the additional functionality I've read on the forums/userecho, or found based on r4m0n's help so far: Undocumented commands: mechjeb.stage() increments stage, just like hitting space bar mechjeb.controlRelease() deactivates the .attitudeTo(), .thrustActivate() and perhaps other commands mechjeb.thrustActivate(Percentage) sets engines to that level mechjeb.thrustDeactivate() turns off engines mechjeb.warpIncrease() increases warp factor by 1 Returns True if the warp increase succeeded, False if it failed mechjeb.warpDecrease() decreases warp factor by 1 Safe to re-run when at 0 Always returns nil mechjeb.warpPhysics() 0.16 - sets warp to 1x mechjeb.warpMinimum() 0.16 - sets warp to 1x mechjeb.getAttitudeActive() returns boolean - apparently whether Smart A.S.S. or a similar attitude hold is in effect mechjeb.attitudeDeactivate() disables .attitudeTo() and/or Smart A.S.S. without changing thrust. var = mechjeb.getModule(ModuleName) ?? mechjeb.attitudeGetReferenceRotation(??) ?? mechjeb.attitudeWorldToReference(??) ?? mechjeb.attitudeReferenceToWorld(??) ?? mechjeb.attitudeAngleFromTarget(??) ?? mechjeb.distanceFromTarget(??) ?? mechjeb.relativeVelocityToTarget(??) ?? mechjeb.targetName(??) ?? mechjeb.landActivate(??) ?? mechjeb.landDeactivate(??) ?? mechjeb.launch(??) ?? mechjeb.mechjeb.getControlClaimed() ?? - returns False even with both Smart A.S.S./.attitudeTo() and .thrustActivate() active EITHER mechjeb.core.targetVessel (select target Vessel or Debris, NOT Bodies, in Rendevous Module GUI) OR mechjeb.core.targetBody (select target Celestial Body in Rendevous Module GUI) .orbit.orbitalSpeed Example: print(mechjeb.core.targetBody.orbit.orbitalSpeed) returnsTarget orbital speed in m/s mechjeb.core.targetBody.orbit.orbitalSpeed returns Target orbital speed in m/s .latitude (targetVessel ONLY!!!) returns Target latitude in ?? .longitude (targetVessel ONLY!!!) returns Target longitude in ?? .orbit.semiMajorAxis returns Target semi-major axis in meters .orbit.LAN returns Target LAN in degrees .orbit.eccentricity returns Target .orbit.argumentOfPeriapsis returns target Argument of Periapsis in degrees .orbit.altitude returns target ??(ASL? Bottom? True? Other?) altitude in meters .orbit.ApA returns target Apoapsis in meters .orbit.PeA returns target Periapsis in meters .orbit.inclination returns target Inclination in degrees .orbit.period returns target Period in seconds .orbit.timeToPe returns target time to Periapsis in seconds .orbit.timeToAp returns target time to Apoapsis in seconds .orbit.radius returns orbital radius (from center of body being orbited) in meters .CoM[1] (targetVessel ONLY!!!) returns ?? .CoM[2] (targetVessel ONLY!!!) returns ?? .CoM[3] (targetVessel ONLY!!!) returns ??

From the UserEcho, I found 'access the C# class with mechjeb.core.targetVessel" 1) What's the companion way of getting to a body, like the Mun, Minmus (Eve), etc.? 2) Is there one of the C# files from the svn repository I can ready to see what options I have for mechjeb.core.*, or mechjeb.core.targetVessel? Or a way in lua to enumerate all the possible options? I hate asking silly questions like these. In MechJeb 1.9.1, I popped up the Rendevous module, selected a Vessel from the Spacecraft exchange at 1200km distance, and tried: > print(mechjeb.core.targetVessel.speedOrbital) receiving: Exception: Cannot get speedOrbital from Talos-MKII Debris (unloaded) (Vessel) So it's reading the target correctly, but I don't know how to use it . I then selected the Mun, and tried again - still pointed at the Talos debris (unsurprisingly)

While we have the Wiki, I'd like to know where and in what format KSP stores, or otherwise how to extract or display or save in some readable fashion, the various orbital and planetary elements KSP stores directly from the game. I've used the wiki, but after a little confusion over a tidally locked moon whose X rotation period doesn't equal its Y orbital period, I'd rather see what I can pull directly out of the game. I'd like to be able to calculate orbits for Molniya constellations and other eccentric orbits which require the sidereal rotation period of the body, as well as plug in accurate values for orbital transfer math (once I learn said math).

I'm waiting for the Electrical Power Standards to become more popular so different modules can work together without hand edits before I so much as touch an electrical plug-in - there's more than enough in the game to keep me occupied until then (I hope). All my "mod the mod" time is already taken up .

Relating to TOT itself, in version 0.3 I didn't see an easy way to launch from, say, Minmus (or an arbitrary orbit), and then use Kerbin to give a grav assist to another body ouside the Kerbin system (say, Eve). Is this a lack in the interface, or a lack in my understanding of orbital dynamics?

Again, thanks to the KSP and Mechjeb teams for providing us with such an exciting toolbox to play with in an easily written and scripted interpreted language. With little more than KSP, Mechjeb, a text editor, and some typing we can land on the Mun, get into a Molniya orbit, or perform most other manuevers. I think I may be running into either mechjeb.* data limit, or a limit in my vocabulary, as I'm rapidly approaching a stalling point where I have almost, but not quite, all the orbital elements. to do more math and then more operations with. I'm asking for help in gathering the following information, either directly or by pointing out the elements I have that I can use to derive the following: A. Mean Anomaly at Epoch and units (or any of the related anomalies - Mean Anomaly, True Anomaly, perhaps the Eccentric Anomaly) EDIT: A.1 in Kerbin Orbital Parameters V2 (https://docs.google.com/document/d/1fmTW6P91OVFj5Tuj0JzKcnfpcw79RqveQTAywrPIIrI/edit?pli=1#heading=h.ktf15rmlbwy8) I see a formula that says it's for Mean Anomaly at Epoch based solely on semi-major axis, the standard gravitational parameter, and time since periapsis. My questions now becomes: is that correct, Epoch is strictly arbitrary (i.e. the first step in any set of formulas that use Epoch is to synchronize Epochs, and/or set them all to a reference value, like - arbitrarily - vessel.time = 0)? I'm still seeking the formulas and elements for circles, equatorial circles, parabolas, and hyperbolas, though. B. True longitude (is it the same as vessel.longitude) and units C. True latitude (is it the same as vessel.latitude) and units Or, alternately: D. Position Vector and units E. Velocity Vector and units F. Frame of reference and units G. Any recommended pure lua library for matrix and vector math to code the conversions with . Some references on equations I'd like to be able to use (True Anomaly or other values required): http://kerbalspaceprogram.com/forum/showthread.php/10037-Getting-Absolute-Longitude-%28in-same-reference-system-as-LAN%29?p=216289&viewfull=1#post216289

First, thank you very much for building this, and referencing the Vallado book - I knew I'd barely started, but now I know I have not even set foot upon the path. I'll certainly be willing to help out with Autom8 integration of some sort, though my initial thoughts would be to leverage and extend the functionality I'm already building (http://kerbalspaceprogram.com/forum/showthread.php/16503-MechJeb-Autom8-Scripts-Megathread?p=238962&viewfull=1#post238962). Let me know your thoughts on this, but I'd expect that the simplest way to start integration off, have the TOT write out an Autom8 script that executes the various parts at whatever level of detail we reach in the middle. Eventually, I'd hope to create the capability within Autom8's lua to perform more and more of the orbital mechanics and operations directly, which would allow the TOT to do better optimization and all the graphs, then based on user selections in the graphical TOT module give a very simple, readable lua script, specifying the orbital transfers, while the lua code does a lot of the determinations on attitude adjustment for each burn - i.e. feed Autom8 the optimal/chosen orbital path, and let Autom8 do the calculations for how to get onto it. Note that this is my first and only lua project, and my first and only orbital mechanics and astrodynamics project, so it'll take me awhile to get anywhere meaningful - and I'm trying to document as I go, which takes time up front. Anyone else wanting to jump in, with or without bootstrapping off the code I'm writing (anything protectable is under GPLv2, GPLv3, and/or CC BY-SA 3.0 Unported - math, of course, is not protectable), is more than welcome to. Also, I have never touched Java, either, but I was once quite comfortable with C. Any assistance or good references on the various and sundry reference systems available, and which are best for what purposes, would be more than welcome. P.S. Since KSP operates in seconds, seconds are essentially the fundamental time unit, are much finer grained than a 'day', have no confusion about which celestial body's 'day' it is or what rotation period to use, and are not subject to occassional calendar-correcting chagnes, I would very seriously recommend seconds instead of days.

There's a userecho request for it to be in-game, per stage, to the lua code. Alternately, at the design stage, write down the amount of fuel per stage in mass units, and then feed your code one parameter - the dry mass of the rocket, and then it can calculate fuel from the wet mass... as long as you don't use more than one fuel type (i.e. RCS).

SimpleKSPOrbitalMechanics upgraded to 0.003 and SimpleKSPOrbitalOperations upgraded to 0.002; see post #53 in this thread for more details (now includes function listings!). http://kerbalspaceprogram.com/forum/showthread.php/16503-MechJeb-Autom8-Scripts-Megathread?p=238962&viewfull=1#post238962 Togfox, there's code to calculate actual measured Isp (at whatever throttle setting you like) from any rocket you can get into stable orbit. You could then calculate exhaust velocity from this and feed it into your delta-V calculator if you still don't like mine . Try it on every stage for fun and profit . Added KSP based isOrbitStable, reporting on orbital and mass variables instantaneously and over time(!), and operational testing of actual Isp at various thrust settings. Skoo now has functional code to detect when mechjeb.attitudeTo() has finished pointing. New Skom functions: isSkomCurrentOrbitStable() reportSkomCurrentMsMsdApPeSopTmapTmpeLanAopIncEccAOvSvVvHvHdPiRlAltaslAlttruAltbotLatLngRfcbGAtmdTm() reportSkomCurrentChangeOverTimeMsiMsfMsMsdApPeSopTmapTmpeLanAopIncEccAOvSvVvHvHdPiRlAltaslAlttruAltbotLatLngRfcbGAtmdTmFromTmbiTmbtwnDriver(TimeBeforeInitial, TimeBetween) printSkomCurrentChangeOverTimeMsiMsfMsMsdApPeSopTmapTmpeLanAopIncEccAOvSvVvHvHdPiRlAltaslAlttruAltbotLatLngRfcbGAtmdTmFromTmbiTmbtwnDriver(TimeBeforeInitial, TimeBetween) coprintSkomCurrentChangeOverTimeMsiMsfMsMsdApPeSopTmapTmpeLanAopIncEccAOvSvVvHvHdPiRlAltaslAlttruAltbotLatLngRfcbGAtmdTmFromTmbiTmbtwn(TimeBeforeInitial, TimeBetween) New Skoo functions: measureSkooIspFromTmbiTmbtwnNsDriver(TimeBeforeInitial, TimeBetweenEach, NumberSlices) testSkooIspFromTmbiTmbtwnNsMpcsDriver(TimeBeforeInitial, TimeBetweenEach, NumberSlices, MaxPointingChangeStable) cotestSkooIspFromTmbiTmbtwnNs(TimeBeforeInitial, TimeBetweenEach, NumberSlices) cotestSkooIspFromTmbiTmbtwnNsMpcs(TimeBeforeInitial, TimeBetweenEach, NumberSlices, MaxPointingChangeStable)