Peewee

Did you read the challenge guidelines? It does matter.

This should probably be in Tools and Applications. Also, why is it tagged as a plugin?

No idea, those inputs produced this result for me:

Any plans for when test flight mode might be fixed? If in that mode, the reward for recovering things should also be reduced significantly... I've accidentally given myself about 100,000 kredits by landing test flights successfully. >_>

That's not a simple task. You might want to check out this tool to help with the math, but if you insist on doing it all yourself you can change the conics patch mode to see your flyby relative to the particular body, and increase CONIC_PATCH_LIMIT (in settings.cfg, located in the install directory) to see more than 3 SoI's ahead.

6. Taking advantage of aerodynamic bugs is frowned upon. (No magical canard turbines) :/

Wow, that was an impressive time. I had a much simpler, smaller design, but only managed 1:40 (Fired rocket at 42:47, impacted at 44:27). VIDEO MIRROR Disclaimer: I had Kerbal Alarm Clock (not a performance-enhancer, just to keep track of the time in-game) and Kethane installed, though the ship itself was all stock parts. I also used the debug menu to make getting into orbit trivial. Bonus: Land at high speed and survive (40 m/s) Actually thrust downwards to increase speed before slowing down. (Ok technically I didn't thrust straight down because I swung it around the wrong way by accident, but I did the spirit of this one) Practical size (You could have multiple of them docked to a space station) Technically an IVA view for the final 20 seconds of landing. Edit: I just saw the part of the OP about the .craft file. It's really quite simple and I can't be bothered to upload it, so here's how it's built and how to land it: Start with the pod seen in the video (has impact tolerance of 50 m/s). Add 4 backwards-facing sepratrons on the wide side of the pod. Add a decoupler. Add a SRB (Might experiment with the big one, but the smaller one is fine for LKO insertions). Correct the staging because it's terrible. SRB fires first, then the decoupler, then the sepratrons. Flight instructions: 1. If you need to go down RIGHT NOW, aim more down than retrograde (poorly demonstrated in the video), otherwise just aim retrograde to deorbit normally. 2. Fire the SRB at the lowest point of your orbit. 3. The craft will face the correct direction on its own, that's why you put the sepratrons in the back. 4. Watch the RADAR altimeter in IVA view: fire when it's between 200m and 300m. You have ~0.7 seconds to fire the landing motors or else you will hit the ground too fast., so pay attention.

Or you know, just get the free one at http://www.7-zip.org/

http://ksp.olex.biz Silly nonstandard URLs

Yes, that's what I'm working towards. The math has to be done before any simple 'run it and it just works' scripts can be made, and it just so happens that rendezvous scripts take a significant amount of annoyingly hard to debug math, which hasn't already been given to us by MuMechLib. In the meantime, have a simple script I whipped up in an hour: http://pastebin.com/ZZ0VGU6N It will take you on a quick spin around the Kerbin neighborhood and land. (Kerbin -> Mun -> Minmus -> Kerbin)

... Because it doesn't matter which way 'up' the rocket is. It's probably more aerodynamically stable upside down or something, since the ascent autopilot just tries to keep it from rolling very much.

It's fine if you're just checking out the code, but if you want to execute anything in-game, you'll need to get rid of the .txt on the end. Once again, it's a work in progress, and doesn't actually do anything useful yet. As it is now, Rendezvous() will just spam some debugging text to the console then throw an error about trying to do math on a nil value (AN is not currently returned because it was inaccurate). I'll edit that post before it causes any more confusion.

Yep, it's that easy.

I'm using code from MuMechLib, so I'm obligated to release those parts under GPL. To keep everything tidy, I'm releasing it all under GPL. Here's my script as-is. (still obviously a work in progress) ------NON-FUNCTIONAL CODE------ http://pastebin.com/uxCZJgjT http://pastebin.com/X8qgZGdE ------FOR SCRIPT WRITERS ONLY------ ------DON'T BOTHER DOWNLOADING IF YOU JUST WANT IT TO WORK------

You need to run it in a coroutine. See kerbin2mun.lua in the OP for an example. After thorough testing, I've determined that my FindAN() function doesn't work as expected. If anyone has a working algorithm to get the true anomaly of the ascending node between two orbital planes, I'd be much obliged. What I've got so far (significant portions ported over from MuMechLib): -- TAKES: orbital position vector (3d vector) -- RETURNS: geocentric latitude and longitude? (2d vector) at given orbital element vector function LatLongofVector(vinput) -- get the geocentric latitude and longitude of a orbital element vector local rads = math.pi/180 local c1 = vinput[1] local c2 = vinput[2] local c3 = vinput[3] local lat = math.atan(c3 / math.sqrt(c1*c1 + c2*c2))/rads local long = math.atan2(c2, c1)/rads if (c1 < 0) then long = long + 90 elseif (c1 > 0) then long = long + 270 end local coord = {lat, long} return coord; end -- TAKES: geocentric coordinates (latitude, longitude) -- RETURNS: true anomaly (radians) when orbit is over coordinates -- note: May or may not actually work right now... function GetTrueAnomalyAtGeoCoordinates(orbitParams, coords) local temp2 = math.deg(math.atan(math.tan(math.rad(coords[2]))/math.cos(math.rad(orbitParams.I)))) -- print("temp2: " .. temp2) local truAnomaly = 180 + (temp2 - orbitParams.AoP) if (truAnomaly > 360) then truAnomaly = truAnomaly - 360 end return math.rad(truAnomaly) end -- TAKES: target orbital parameters -- RETURNS: (radians) true anomaly of ascending node -- note: does not work yet. function FindAN(orbitParams, targetParams) print("finding AN") local vA = math.sin(math.rad(orbitParams.I))*math.cos(math.rad(orbitParams.LAN)) local vB = math.sin(math.rad(orbitParams.I))*math.sin(math.rad(orbitParams.LAN)) local vC = math.cos(math.rad(orbitParams.I)) local tA = math.sin(math.rad(targetParams.I))*math.cos(math.rad(targetParams.LAN)) local tB = math.sin(math.rad(targetParams.I))*math.sin(math.rad(targetParams.LAN)) local tC = math.cos(math.rad(targetParams.I)) -- vector3D.cross(v, t) inline here local c = {} c[1] = vB*tC - vC*tB c[2] = vC*tA - vA*tC c[3] = vA*tB - vB*tA -- print("end vector stuff C") local coordsA = LatLongofVector(c) coordsA[2] = coordsA[2] - orbitParams.LAN --don't ask me. if (coordsA[2] < 0) then coordsA[2] = coordsA[2] + 360 end print("AN coords?: ".. coordsA[1], coordsA[2]) -- Got latitude/longitude of node A -- local latB = coordsA[1] * (-1) -- local longB = coordsA[2] + 180 -- if (longB > 360) then -- longB = longB - 360 -- end -- local coordsB = {latB, longB} -- Got latitude/longitude of node B -- print("end coordinate stuff C") local nodeA = GetTrueAnomalyAtGeoCoordinates(orbitParams, coordsA) -- local nodeB = GetTrueAnomalyAtGeoCoordinates(orbitParams, coordsB) -- print("end node stuff A") -- TODO: figure out a way to distinguish ascending and descending nodes. -- if (GetRadiusAtTruAnomaly(orbitParams, nodeA) > GetRadiusAtTruAnomaly(orbitParams, nodeB)) then return nodeA -- else -- return nodeB -- end end I also have true anomaly -> eccentric anomaly -> mean anomaly conversions.