Nadrek

Hmm; I'd have to wonder if you redid all your calculations after the warp (and noted the differences), and if you accounted for thrust ramp-up and ramp-down time and the change in attitude required during the burn. When you say within 12%, are you always under, always over, or sometimes some of each? May I also ask how you warped to the nearest burn node?

If I may ask, I was waiting to even try this until I can warp to the ascending or descending node - have you actually worked out the amount of time from apoapsis/periapsis to the ascending/descending node for elliptical orbits, or are you using a different technique? My plan would have been to try and figure out the delta-V required, then do a burn anticipated to reach it, possibly with some fudge factor and touch-up afterwards for the highest accuracy, and possibly multi-orbit based if the thrust available isn't high enough.

KSP is, in essence, several games rolled into one - and just like a lot of other sandbox games (X3, for example), the player has choices. Not all players are the same. Some players are playing an atmospheric flight sim - perhaps they want to bomb something with their K-52 Kerbalfortress. Some players are making movies. Some players are creating mods. Some players are accomplishing specific goals or challenges. Some players are blowing things up. Some players are learning about 1-body orbital mechanics by feel. Some players are learning about 1-body orbital mechanics by calculations. Some players are engineering new rockets or planes. Some players are building new rockets or planes. Some players are flying a space flight sim. Some players are doing something you and I have never once considered. Some of these are not helped by Mechjeb (flying by the seat of your pants) Some are. Personally, I started using MechJeb in my quest to build the most efficient rockets - having a consistent ascent, every time, means that within a (small) margin of error, I can play with different configurations and determine how efficient they are. I very much like the various information displays, and I like being able to know "This rocket can carry a payload of X tons, including Y tons of fuel, into a circular orbit/Molniya orbit/Munar landing/Grand Tour". For me _at this point_, the whole trip into whatever my target is, whether it's an orbit or a landing, is a waste of time - I'm looking forward to the accelerated full control mode, too. I build or tweak my rocket, then set up MechJeb, hit Space, and put KSP into the background until it's done and I can check my stats. Then I tweak and repeat - I'll go through a couple dozen configurations (six Aerospikes + 2 Turbofans, four Aerospikes, 2 45's, 2 turbofans, different staging, etc.) to compare. At such time as I actually want to fly, I'll not use MechJeb's autopilot - but really, I'm not that interested in flying. Recently, I've been playing with MechJeb's Autom8 module - being able to actually do the actual calculations in-game is very cool, and after I build modules to do the math, I can feed in information from my current rocket and orbit. Also, I can have a one-button launch to Molniya orbit, or a one-button Grand Tour - and then perform my efficiency tweaking routine over and over, easily... and that's what I find fun, getting closer to what the math says I should be able to do. If I had to hand-fly everything, I'd have quit long ago. I'll hand-fly combat sims with a Thrustmaster HOTAS setup, but not civilian sims.

SimpleOrbitalMechanics and SimpleKSPOrbitalMechanics upgraded to 0.002; see post #53 in this thread for more details: http://kerbalspaceprogram.com/forum/showthread.php/16503-MechJeb-Autom8-Scripts-Megathread?p=238962&viewfull=1#post238962

I'd love a little window to type in a °/sec limitation, gain settings, and so on and so forth; that would be wonderful (perhaps an "Advanced" window) - or even exposing whatever raw internal variables/"constants" MechJeb has, and we can figure out the conversions if the MechJeb developers give us a "134 is slow, 8734 is fast" type of instruction. Alternately or in addition, a way of changing from being full in "impulse to start, wait, impulse to stop" mode vs. continuous power would also work well. As far as automatic rate limiting, I have to strongly disagree. For one, when I want to save RCS fuel, I leave them off - then we have the "slow, fuel-saving" mode. But even in interplanetary flight, perhaps I was out getting coffee, and came back to see I was just past the ascending node of an orbital intersection, and I want Smart A.S.S. to get me turned the right way for an inclination change burn RIGHT NOW!!!. Sometimes you want to save fuel, sometimes you want to save time - at 1.9.1, save fuel = RCS off, and save time = RCS on, with nothing in between - it's enough now, though as I said above, I'd love to have the intermediate modes available, but right now we have the two extremes available - I'd be quite annoyed to lose the "save time" option we have now.

Here's mine so far - they'll be in SimpleOrbitalMechanics 0.002 - licensed under your choice of GPLv2, GPLv3, or Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) http://www.gnu.org/licenses/gpl-2.0.html or http://www.gnu.org/licenses/gpl.html or http://creativecommons.org/licenses/by-sa/3.0/ That said, math is math, and is unprotectable, as are the lua calls . function calcSomDeltaVFromIspTsmTem(Isp, TotalStartingMass, TotalEndingMass) -- Isp is the Specific Impulse in seconds -- TotalStartingMass is the total mass before the burn, including fuel - units must be the same as TotalEndingMass -- TotalEndingMass is the total mass after the burn, including remaining fuel - units must be the same as TotalStartingMass -- returns Delta-V in meters per second. --[[ ex: print(calcSomDeltaVFromIspTsmTem(390,15,10)) ]] -- reference is Tsiolkovsky rocket equation https://en.wikipedia.org/wiki/Rocket_equation -- Total Delta-V = Isp * g * ln(TotalMass/DryMass) return Isp * globalg * math.log(TotalStartingMass/TotalEndingMass) end function calcSomIspFromTsmTemDv(TotalStartingMass, TotalEndingMass, DeltaV) -- TotalStartingMass is the total mass before the burn, including fuel - units must be the same as TotalEndingMass -- TotalEndingMass is the total mass after the burn, including remaining fuel - units must be the same as TotalStartingMass -- returns Isp, the Specific Impulse in seconds --[[ ex: print(calcSomIspFromTsmTemDv(15,10,1550)) ]] -- reference is Tsiolkovsky rocket equation https://en.wikipedia.org/wiki/Rocket_equation -- Total Delta-V = Isp * g * ln(TotalMass/DryMass) return DeltaV/(globalg * math.log(TotalStartingMass/TotalEndingMass)) end

I think that's a bad idea for all Kerbalkind. One day, you're going to bouncing around the system, and you're going to hear "I'm sorry, Dave, I'm afraid I can't do that."

Is there any kind of exception handling that can be used to find these exceptions and retry a random but short amount of time later?

I looked at your script, and I noticed that you know commands that I do not - mechjeb.thrustActivate(10), mechjeb.controlRelease(), and mechjeb.stage() are not on the Autom8 wiki page I was using as a reference, much less ils = mechjeb.getModule("ils") ils.glideslope = slope - how did you find them - read the source code for Mechjeb, or some other way?

We're working on opposite ends of the problem, then. I want to calculate dV required for arbitrary operations, and you want to calculate dV remaining. I'd advise you to create the pure math functions first, in the most general way possible. That way, you have options: 1) You can have the user enter the amount of fuel left (in kg, available by using the GUI to right-click fuel tanks one at a time and then using another general function to convert X type of fuel from liters to kg) as a temporary bandaid. 2) Once fuel is available, you can easily create a shell function like the ones in my SimpleKSPOrbitalMechanics that automatically determines those values in the units you need, and passes them in to the mathematical function you already wrote. 3) The real future fun will be figuring out fuel per stage and mass per stage, for accurate calculations on multi-stage vessels.

To the author: Thank you again for creating this - it's very much something I like working with. I do have a few requests for future versions: 1) mechjeb.warpToEvent with "instant" as an option, so only the optional lead time in seconds is used (i.e. warp (amount of time)) 2) mechjeb.warpToEvent Ascending Node and Descending Node, for inclination change manuevers 3) Ideally, some way of determining where other objects are - the Mun, other craft or debris, and their orbital parameters so we can work out the rendevous/intercept/orbit phase math ourselves. 4) mechjeb.launchToApogee - do the launch to inclination at an apogee, but do not circularize. 5) Better instructions on how to use mechjeb.attitudeTo - is it instant or sustained, and if sustained, how do we turn it off?

What I actually was talking about was "dV required" equations; i.e. to move from a 125km Pe, 500km Ap orbit to a 125km Pe, 750km Ap orbit, what dV will be required? i.e. http://www.enotes.com/topic/Bi-elliptic_transfer has some equations based on orbit changes irrespective of the vessel doing so, but again, a brief glance shows "initial circular orbit with radius r0", which indicates a simplification has been done that I don't want (circular orbits only). Likewise, http://en.wikipedia.org/wiki/Hohmann_transfer_orbit uses circular orbit based equations, i.e. "r1 and r2 are, respectively, the radii of the departure and arrival circular orbits". Note that this is going to end up as the same math Mechjeb uses internally to tell you how much dV will be required for a given manuever.

Well, if you can help with an equation that works for any mix of circular, elliptical, parabolic and hyperbolic orbits, perhaps we can work something out together. Equation or equations which don't assume at least one orbit is circular are what I haven't found (or noticed I'd found) yet.

Thank you. For C functions, what I meant to say was can we include (require "xxx") Lua libraries that are wrappers to C libraries - there appear to be very few pure lua libraries to do real math available. When I tried the hand-typed experiment, in the Autom8 console, of: do print(vessel.time) wait(2) print(vessel.time) end The entire game froze for 2 seconds, and then I had two identical timestamps in the display.

Thank you to the Mechjeb team for both Mechjeb, and releasing the Autom8 lua interface! That's very much something I'm enjoying. In the hopes that this is useful to some of the other script kerbals out there, I'm hereby releasing a set of three lua scripts/pseudo-libraries, licensed under your choice of GPLv2, GPLv3, or Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) http://www.gnu.org/licenses/gpl-2.0.html or http://www.gnu.org/licenses/gpl.html or http://creativecommons.org/licenses/by-sa/3.0/ All functions have extensive comments regarding how to use them, and there are help functions in all three files to make essentially the same information available when using the code. SimpleOrbitalMechanics 0.002 (http://pastebin.com/eZkL9wW7) is just that - orbital mechanics. It can be run in any lua environment (including lua for your OS), and all it does it orbital math. Well, and it knows a few facts regarding a few celestial bodies (Earth, Kerbin, Mun, Minmus). It has functions to calculate the semi-major axis, calculate desired Apoapsis and Periapsis values, calculate sidereal orbital periods, calculate orbital velocities, and calculate u (GM, the standard gravitiational parameter) - which it can use to guess which body your orbit must be around. There are also functions to calculate whether an orbit is stable (above the atmosphere, below the end of the Hill sphere [of influence]), to calculate Apoapsis and Periapsis for a particular orbital period, and a specific function to calculate Molniya orbits. Additionally, it has a reasonably capable test harness, so you can do a test and see if it's returning the expected results. -- Function headings: globalSomOverallInit() globalSomMainBodyReset(MainBodyName) calcSomSemiMajorAxisOrbitingSphereFromApPeMbr(Ap, Pe, MainBodyRadius) calcSomPeorapFromaAporpeMbr(a, Aporpe, MainBodyRadius) calcSomSiderealOrbitalPeriodFromaGm(a, GM) calcSomSemiMajorAxisFromSopGm(SiderealOrbitalPeriod, GM) calcSomGMFromaSop(a, SiderealOrbitalPeriod) calcSomSiderealOrbitalPeriodFromApPeMbrGm(Ap, Pe, MainBodyRadius, GM) calcSomOrbitalVelocityFromaGmRfcb(a, GM, RadiusFromCentralBody) calcSomOrbitalVelocityFromaGmAltaslMbr(a, GM, AltitudeASL, MainBodyRadius) calcSomGMFromaOvRfcb(a, OrbitalVelocity, RadiusFromCentralBody) calcSomGMFromaOvAltaslMbr(a, OrbitalVelocity, AltitudeASL, MainBodyRadius) guessSomWhatBodyIsTheMainBodyFromaOvAltaslMoe(a, OrbitalVelocity, AltitudeASL, MarginOfError) calcSomPeorapFromAporpeMbrGmSop(Aporpe, MainBodyRadius, GM, SiderealOrbitalPeriod) calcSomMolniyaPeorapFromAporpeMbrGmSrp(Aporpe, MainBodyRadius, GM, SiderealRotationalPeriod) calcSomApPeFromAporpePeorap(Aporpe, Peorap) calcSomMolniyaApPeFromHsoiMsaMbrGmSrpMoe(HillSphereOfInfluence, MinStableAltitude, MainBodyRadius, GM, SiderealRotationalPeriod, MarginOfError) isSomOrbitStableFromApPeHsoiMsa(Ap, Pe, HillSphereOfInfluence, MinStableAltitude) calcSomDeltaVFromIspTsmTem(Isp, TotalStartingMass, TotalEndingMass) calcSomIspFromTsmTemDv(TotalStartingMass, TotalEndingMass, DeltaV) testSomTestHarness() helpSomSimpleOrbitalMechanics1() helpSomSimpleOrbitalMechanics2() helpSomSimpleOrbitalMechanics3() helpSomSimpleOrbitalMechanics4() helpSomSimpleOrbitalMechanics5() Notably lacking are Delta-V predictions for specific orbital changes - what I could find of the vis-viva equations were mostly simplified for circular orbits, and I want to implement the general case if possible, not a specific case. SimpleKSPOrbitalMechanics 0.003 (http://pastebin.com/fvD6hK1h) is pretty sparse, since KSP already implements simple orbital mechanics properly in the first place. It has functions that automatically use the vessel.X values to guess which planet you're orbiting (or on), to print a fair bit of that vessel.X information to the Autom8 screen, to calculate stable Molniya orbits around whatever celestial body you're orbiting, to check if your current orbit is stable, and to report on orbital and mass variables instantaneously as well as the changes over a specified number of seconds. -- Function headings globalSkomKSPMainBodyResetBasedOnGuessing() guessSkomKSPWhatBodyIsTheMainBodyCurrentlyBeingOrbited() function calcSkomMolniyaApPeFromMainBodyCurrentlyBeingOrbitedFromMoe(MarginOfError) function printSkomKSPCurrentOrbitalElements() function reportSkomCurrentMsMsdApPeSopTmapTmpeLanAopIncEccAOvSvVvHvHdPiRlAltaslAlttruAltbotLatLngRfcbGAtmdTm() function reportSkomCurrentChangeOverTimeMsiMsfMsMsdApPeSopTmapTmpeLanAopIncEccAOvSvVvHvHdPiRlAltaslAlttruAltbotLatLngRfcbGAtmdTmFromTmbiTmbtwnDriver(TimeBeforeInitial, TimeBetween) function printSkomCurrentChangeOverTimeMsiMsfMsMsdApPeSopTmapTmpeLanAopIncEccAOvSvVvHvHdPiRlAltaslAlttruAltbotLatLngRfcbGAtmdTmFromTmbiTmbtwnDriver(TimeBeforeInitial, TimeBetween) coprintSkomCurrentChangeOverTimeMsiMsfMsMsdApPeSopTmapTmpeLanAopIncEccAOvSvVvHvHdPiRlAltaslAlttruAltbotLatLngRfcbGAtmdTmFromTmbiTmbtwn(TimeBeforeInitial, TimeBetween) isSkomCurrentOrbitStable() printSkomKSPCurrentVesselInfo() helpSkomSimpleKSPOrbitalMechanics1() helpSkomSimpleKSPOrbitalMechanics2() helpSkomSimpleKSPOrbitalMechanics3() helpSkomSimpleKSPOrbitalMechanics4() SimpleKSPOrbitalOperations 0.002 (http://pastebin.com/Vsdbth2h) is, so far, similar to but a little more generic than what we've seen already by other users - one function to launch a ship from the ground into a specific orbit (by Apoapsis, Periapsis, and Inclination), and a second script that automatically launches into a Molniya orbit at the chosen inclination (63.4, 116.6, -63.4, -116.6), if one is available (Kerbin and the Mun, at least, can have Molniya orbits). Functions are available to show a ship's actual, tested Isp (Specific Impulse), DeltaV per kg fuel, and DeltaV per second at various thrusts - this is an amazing test of the 0.16 fuel consumption bug: -- Put the three .lua files in your PluginData\mumechlib directory -- in the Autom8 window from a vessel in a stable elliptical or circular orbit around any body, copy and paste: require "SimpleKSPOrbitalOperations" cotestSkooIspFromTmbiTmbtwnNsMpcs(0.5, 0.5, 4, 0.02) -- then hit Enter or click Execute -- Function headings launchSkooFromApPeInc(Ap, Pe, Inclination) launchSkooMolniyaFromIncMoe(Inclination, MarginOfError) colaunchSkooFromApPeInc(Ap, Pe, Inclination) colaunchSkooMolniyaFromIncMoe(Inclination, MarginOfError) measureSkooIspFromTmbiTmbtwnNsDriver(TimeBeforeInitial, TimeBetweenEach, NumberSlices) testSkooIspFromTmbiTmbtwnNsMpcsDriver(TimeBeforeInitial, TimeBetweenEach, NumberSlices, MaxPointingChangeStable) cotestSkooIspFromTmbiTmbtwnNs(TimeBeforeInitial, TimeBetweenEach, NumberSlices) cotestSkooIspFromTmbiTmbtwnNsMpcs(TimeBeforeInitial, TimeBetweenEach, NumberSlices, MaxPointingChangeStable) helpSkooSimpleKSPOrbitalOperations1() helpSkooSimpleKSPOrbitalOperations2() Next on the agenda, if I can get them working: Orbit phase changes for those that want constellations! I've also attached them, for anyone who doesn't want to use the Pastebin links. P.S. No, I've never touched lua before in my life. Why do you ask? P.P.S. No, I really don't know if the sidereal rotational period of the Mun is 41, 38... or 39... hours - I see a note about being tidally locked in the wiki, and then I see that the sidereal and planetary rotation periods are different, so I'm confused. EDIT: 20120827 Updated Som and Skom to 0.002 - added real life Moon data, delta-V based on Tsiolkovsky rocket equation and Isp (specific impulse), useful constants, minor renaming of Period to SiderealOrbitalPeriod, added more Autom8 variables to the Skom print... functions. EDIT: 20120904 Updated Skom to 0.003 and Skoo to 0.002 - 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. Older versions are at: SimpleOrbitalMechanics 0.001 (http://pastebin.com/YDdSA37H) SimpleKSPOrbitalMechanics 0.001 (http://pastebin.com/yQ09yHJi) SimpleKSPOrbitalMechanics 0.002 (http://pastebin.com/8zcahtTB) SimpleKSPOrbitalOperations 0.001 (http://pastebin.com/s5KQg8fu)

Thank you for the reference; if I'd seen that Lua guide in the Autom8 wiki, I would have read it. Is there a trick to using C functions inside Lua with Autom8, per: http://stackoverflow.com/questions/1034334/easiest-way-to-make-lua-script-wait-pause-sleep-block-for-a-few-seconds ?

A few questions: First, is there a better documentation link? It seems to be missing the concatenation operator, as well as things like the wait() function (i.e. wait(function() return (vessel.altitudeASL <= 75000) end ), per the Shuttle Autopilot Library by olex. In particular, Wait and Warp to seem to be absolutely critical, and I'd like to know how to control waits and warps other than Pe, Ap, and Sol. In particular, how can I Warp to just after a certain point in orbit (say, the point as far from KSP as is possible? FlyMeToTheMun is a good start, but when I tried FlyMeToTheMun(35,35), and once in Munar orbit, the LandTo doesn't appear to be warping ("Cannot warp faster than 1x while the ship is under acceleration"). My orbit is Pe 200836 Ap 200986km Inclination 1.25 Semimajor Axis 400.870km, LAN 145.36, LPe <varies wildly). Stock parts except for MechJeb 1m on top of the 1 kerbal capsule, plenty of fuel left, and I'm at the "Landing" step. EDIT: Just as I posted, my rocket apparently hit the right orbital point, and began its inclination change burn. Still, I'd much rather it have "cut acceleration" and warped.

Here\'s a pretty bad example. Throttle back before staging the first stage, please.

I\'m working out a ship series, though with the fuel consumption bug, I\'m not able to really tell which will be most efficient post-bug. I\'d suggest, just as your initial post did, making sure that every craft is marked with a version. Personally, I always rate my own craft in terms of fuel carried to a standard 125km circular 0 inclination orbit by a 1m MechJeb module (so the flight profile is as consistent as possible) as well as the launch mass -> orbital mass ratio at that standard orbit. More advanced ratings would include the same factors being evaluated after landing at a standard location on the Mun, also by MechJeb. Remove MechJeb, and it\'s stock.

Very impressive indeed; I like the view when 'CONIC_PATCH_DRAW_MODE = 3' in settings.cfg.

This appears to be an amazing application for orbital mechanics, and could likely be useful with Orbiter as well as Kerbal! I have a suggestion, a request, and a frivolous request: Suggestion: As far as the thousands separator goes, yes, it\'s useful, but perhaps an option for scientific notation at whatever level of precision is requested would be useful as well, if a bit more complex? Request: Molniya orbits. Frivolous request: Computer support for both minimum time and maximum energy re-entry impacts at a defined point on Kerbal\'s surface, suitable for ortillery (orbital artillery) practice.