aNewHope

This is awesome. I always wondered why the chase-cam in KSP felt so unnatural. It's because in all games where you fly planes (HAWX, etc) the camera is fixed along the velocity vector. Thanks! I'll download it asap.

1 Joule or 1 watt for 1 second (call it wattsecond / ws) is the energy required to raise 100 gram of mass 1 meter (E_height = m * g *h) (m = E/[g * h]) Therefore 2 GW over 2 minutes are 240GWs or enough energy to lift 24000 tons 1 km. Or if you want kinetic energy: (E_kinetic = 1/2 * m * v^2), (v^2 = [2*E] /m) It is enough to accelerate a car (about 1 ton) to 20.5 km/s, which is almost the double of earths escape velocity. That's a huge amount of energy and yes, if pointed at a (KSP-)b-class asteroid it would be totally sufficient to push it pretty much anywhere you want it to be.

As far as I can see, you'll need none of those two special cases: if t = 0 { set t to 0.001. } if w = 0 { set w to 0.001. } Your mass never gets 0 (even the kOS unit has mass) and your maxthrust can get 0 without producing an error. Also you can use this formula to get the current acceleration due to gravity: (altitude+body:radius)^2/body:mu (distance from gravity source divided by gravitational parameter of the body). Protip: Use "Lock ... to ..." with things like thrust-acceleration, twr, etc. This saves a whole lot of processing time.

That should be quite easy to accomplish. I locked the roll of the rocket to 360 - Inc (your launching angle) so it would keep the roll it had in the beginning. You could replace set Inc to 90-Inc. lock steering to heading(pitch,inc,360-inc). with set Inc to 90-Inc. lock roll to Inc-(Inc*(missiontime/60)). when missiontime > 60 then {unlock roll. set roll to 0.}. lock steering to heading(pitch,inc,360-roll). This way within the first minute since launch you will slowly turn in the right direction. Of course you could increase the time or make it depend on your Inc value. ... hmm I like the Idea, gonna implement it in my copy. PS.: I don't really know the engine ignitor mod but from the first look at the forum page I'd suggest this: You could try a shallower approach (set your psi0 value closer to 90°) or you could lock your steering to the horizon when your Ap is high enough and don't shut of your engines (This way you'll mostly raise the Pe but the Ap just a little). I can't guarantee that any of my suggestions will work, but that's what came into my mind at first. PPS.: To have special staging conditions you'll probably need to add some extra "WHEN ... THEN" conditions. Totally depends on what you want your rocket to do.

Hi there, a few months ago I have written a kOS launching program. It worked very well, but then a new KSP version came out and I forgot about kOS and the program. Now that Erendrake is working on this new version of kOS (thank you very much, your work is awesome), I have used the last two weeks to update for the current version and make it usable with FAR (now it's almost only usable with FAR). It works almost perfect, uses a correct gravity turn trajectory (follows surface:prograde very closely) and utilizes maneuver nodes to complete its orbit. So here it is, just for you: staging doesn't works with kOS 11.1 ! kOS programs PS.: It works by using a lot of sub-programs. L1 is the master-program. Run it with the parameters (your orbit altitude in m, launch inclination (0 = east; 90 = north; etc.), number of stages on your rocket).

1. If it doesn't work in your kOS console, try editing the txt-files directly (It's also much more comfortable IMO.). After you created a program, you can find it in Kerbal Space Program/Plugins/PluginData/Archive . 2. I have a question myself: Why the heck does this autostaging - subprogram NOT work (Especially the first half)? declare parameter use. if use = 1{ list engines in engl. for eng in engl{ if eng:flameout = true{ set use to 0. } } } if use = 0{ stage. print round(Missiontime) + "s Stage " + St at (1,Log). set Log to Log+1. set St to St-1. print St + " " at (Ic2,Il+4). } Whenever I try to read out any info out of the engine-structure kOS just gives me a flagrant error.

My bad, I tried to raise a negative number to a non-integer power. Now, that I changed the code, everything works just fine! PS.: Right now the launching program works very well. Maybe I'll post it, when I tweaked it to perfection.

Hi, Erendrake, I have a request for the upcoming update(s): Right now kOS seems to be incapable of putting out a number to a power, that is not an Integer. I would really need that functionality in order for this program to work (It gives out a list for an almost perfect gravity turn). declare parameter twr,v0,psi0. print "Computing Trajectory" at (Ic,stl). print "Progress:" at (Ic,Il+6). print "0 %" at (Ic2,Il+6). set z0 to -tan(0.5*psi0). set c to v0/(z0^(twr-1)+z0^(twr+1)). set gt to list(). set n to 0. set zm to 0.5. lock v to 5*n^2+55*n+10. lock vm to c*zm^(twr-1)*(1+zm^2). until n > 12{ set zmin to 0. set zm to 0.5. set zmax to 1. until round(vm,0)=v{ if vm>v {set zmax to zm.} if vm<v {set zmin to zm.} set zm to (zmin+zmax)/2. } set n to n+1. set gt:add to 90+2*arctan(zm). print round(100*n/12) + " %" at (Ic2,Il+6). } print " " at (Ic,stl). print " " at (Ic,Il+6). print " " at (Ic2,Il+6). Edit: Problem is solved.

So Z is tan (1/2 Ψ) ? Thank you very much! That's exactly what I wanted to know! Damn, I love the KSP community! PS.: Sadly I can't log into the library but z was pretty much all that's missing. PPS.: (to Kasuha) Due to the limited power of kOS I wont be able to model the drag accurately (without FAR, yes ; with it certainly not). Hopefully this wont be necessary to give a good trajectory. PPPS.: It works! It ********** works! Thank you so much Capi3101! I tried all week to solve this darn problem and now I have a very good solution. Maybe I'll post the program, when it's finished

Hi there, since a few months I've been playing around with the kOS scriptable autopilot (mod). In case you don't know it, try it out, it's awesome! Now that I installed FAR, I want to adjust my rocket launching program to do an almost perfect gravity turn. The program should check the TWR of the craft, and find the fitting trajectory. The thing that's missing is the right formula to get a trajectory always following the prograde marker. I even found a paper on "Computational algorithm for gravity turn maneuver" that should contain the required maths. Until equation II it's easy going, but the following 3 are the problem I can't solve. What do they describe? What is this variable "z"? And can I use them to get a perfect gravity turn for e.g. a constant TWR of 2.5?

I got the problem as well. Whenever I add the mod to my ksp installation (I use OX Mavericks) it starts to load the kerbin1.png and the freezes. Hopefully this'll get fixed soon. PS @ rbray89: I love your texture compression mod and am really looking forward to being able to use the visual enhancements.

Sure. If you're on volume 1: .if you're on volume 0: .

Before writing your program you'll have to switch to volume 0 (The library) by typing "Switch to 0.". Then you can start a new program and save it. Volume 0 is accessible from a height up to 100 km.

Uahrg I'm starting to shiver. Me wants 0.23 Naow!

I can only agree with you, Camacha, only because the "apoapsis" is coded like this, my ∆V calculations work right out of the box. Even on a hyperbolic trajectory I can e.g calculate the ∆V for a circularization burn. Kevin (Laity), please don't remove this bug/feature/useful stuff.

I have a question: Is there any easy way of locking a vector to your up-direction? maybe the unit vector or your vertical speed as vector. This would solve a lot of problems right now, as it would bring an easy way of getting your 6 orbital directions with it. Crossproduct of up and prograde --> normal vector. Crossproduct of normal vector and retrograde --> radial out.

It's out! There's a changelog where you can see the changes. Simply click download from spaceport.

That's an awesome picture and your idea is very good as well. If that would get implemented (maybe along with ordinary alt:radar) it would solve most of my automated landing problems. But I guess that the issue with this feature is, that the current alt:radar is simply putting out the radar altitude that is provided by KSP itself (you can see it in IVA). Probably it's way harder to get the radar distance you are talking about.

You my fellow Kerbonaut are clearly a victim of the well known Tetris effect! It can strike you with almost any game or often repeated activity and has the effect of you visualizing things or activities from the game in the real world. It happens to a lot of people and is no reason for concern. Fly save on all your future adventures! PS: This is a real thing! Wikipedia link --> Tetris effect

I attempted it with 0.10 and even reached escape velocity. But then I realized, that you can't stack fuel tanks in 0.7.3, so it's no legit entry. Maybe I'll try without fuel tank stacking later.

Simply use print velocity:orbit:mag. That should work.

If I use 0.10, does that still count? first version for mac. No map view included.

Nope. That's not yet implemented.

Have you forgotten your terminator ? (the " . ") If not, try Eta:Nextnode which should give you the ETA for your next maneuver node. If that doesn't help I got no other solutions for you. Sadly many of the kOS variables are broken in a way, that you can't calculate with them without using inefficient workarounds. The best example may be eta:apoapsis which you can't really use to trigger actions ( "If eta:apoapsis >=< ... {...}").

As far as I know 1 man pods can only hold one surface sample, while the 3 man pod has more space. But I'm not 100% sure.