MrOnak

Ok I'm not too sure how the point system handles my attempt but I think I can claim 225 points for an unmanned 254x252km orbit plus return, plus X. X is: - deploying two geostationary satellites - lander on Minmus - lander on Mun One launch, 554 parts, 26.64 tons, no part clipping. Craft file here. Video: Sorry, I was bored

Interesting, will attempt this after some food. What are the parts exactly that you consider legit? Oscar B tank was mentioned, as was the Rockomax48 engine, the OCTO struct. How about the Cubic Octagonal Strut, TR-2V decoupler, 'chutes? ... Thanks for clarifying

Duh, good point actually. See you on Github as well.

I have the same issues actually. The disappearing cursor is somewhat frequent, the lock steering is rare for me but its definitely there. Haven't found a reproducable scenario yet though. I believe the cursor disappearing has something to do with using the Del key (not backspace), but thats not reliable so I can't be sure.

Hmmm.... I guess I'll resolve that my own and KERs calculations are in fact correct and that "terminal" in terminal velocity isn't to be taken literally... *sigh* language... Thanks Padishar

It doesn't actually, it backs up my understanding of terminal velocity. I should clarify that the actual velocity in KSP is higher than the Tv calculated by me or KER, even when going straight down.

Cool that should make the changes rather simple. Is the density chart used by FAR publicised anywhere?

I'm not sure whether this is a bug related to KER, KSP itself, or I'm just confused: On reentry my crafts are routinely a bit faster than the terminal velocity displayed by KER. This is true for any body with an atmosphere not just Kerbin. To isolate the problem I made a clean KSP install with only KER installed but it persists. Obviously with FAR the atmosphere would change completely but thats not the case here. Its hard to tell how much faster than terminal velocity my crafts are on average due to the fast changing numbers but I'm estimating around 10%. Has anyone else noticed that? At the moment I believe KERs calculations are actually correct since my formulas which I calculate in-game using kOS show exactly the same numbers as KER. Nevertheless I'd like to understand whats going on here since I need those numbers to match my actual terminal velocity as experienced in game for a lander script. All parts of my craft have an actual drag of 0.2, hence the overall drag is indeed 0.2, just to rule out that error. Thanks in advance

Is there information around how FAR changes the atmospheric drag, pressure, density, scale height and ultimately terminal velocity? I've searched this thread and checked the github wiki but couldn't find anything in-depth. I'm developing a lander-script with kOS which among other things takes terminal velocity into account in order to determine when to start killing velocity. It works just fine but since it is working with the vanilla scale height etc. at the moment it is off by a bit obviously. Thanks in advance.

*cough* Do I need more coffee or is this a bug? [edit]scratch that, I DID need more coffee.[/edit]

*scratches head* at who was this aimed erendrake? I'm not btw, not in the copy that runs kOS.

Heh, I agree. Thanks to this page by Steven however I think I figured out directions and positions - finally. That still doesn't answer my main gripe with rotation though. At least I think it doesn't but its late and I'm braindead. Having a probecore in orbit for half a day measuring directions and another one on the launchpad for some more time for heading information (which flips twice a kerbin-day thanks to the rotational reference frames) was too much.

Thanks I'm halfway there to figure out the rotten coordinate system of KSP. Once that's done I'm certain I can do much more with the current logic, such as the things you mentioned. Automatic takeoff already isn't such a big deal but without knowledge how to query the current roll it ends up being luck. I tried to keep the angularvelocity along the axis compensated but that naturally is liable to drift over time so thats no use

Hmm thats odd, it works for me.

Good to know thanks

@Kiero: V does the trick.

Wait what? x^y? That simple? Arrrrgh that would be nice in the documentation. Anyway thanks thats awesome Any other constants that are availeble? at the moment I already have a file that contains my own but it'd be good to know

Actually range isn't my problem at the moment. It will be later I'm sure, so thanks for the hint . One of the cores simply will stop processing the script when I switch to the other one, even with a simple two-rocket system on the launchpad. Edit: Scratch that, freshly infused with coffee I just managed to launch both... some more investigation is required Erm.... one other thing I noticed last night: There is no pow(double x, double y) function in kOS? At first I thought oh well I just use exp(y * ln(x)) but exp() is also not available. Am I missing something? I'm trying to implement atmospheric pressure at current altitude for a terminal velocity calculation. Back to spreadsheets, wikipedia and the ksp-wiki it seems...

Hey thanks for the reply Actually the plain RPM /MechJebRPM has a delta-V display: I'm of course not sure whether it reads the info from MechJeb (the MechJeb vaccuum dV number matches closely, although its the wrong one, I'm on the launchpad) or does its own calculations. I could swear that the day I installed RPM and MechJebRPM (but not KSI) I saw a MechJeb-like deltaV breakup by stage on one of the pages of the MFD as well but I can't find it now :-(

Its a bit of a long shot but try toggling between fullscreen and "frameless window" and see if that changes something. You won't find that setting inside KSP, only in the "advanced" (not "graphics"!) section of the launcher settings.

On a different note I think my SAM-Launcher is ready for the public. https://www.dropbox.com/s/q259owv1o3ubj1l/kOS%20SAMLauncher.zip Thanks to Mariano and Steven once more, the whole thing would have taken a lot longer without your help .

Haha! I'm glad you all like it. As I said in the video description the source will be available in a short while, when its a bit more useful. @Mariano: I was actually thinking about that but I can't figure out how to have two scripts run on two different vessels at the same time... as soon as I switch vessels the one I just left seems to stop processing and gets out of control. (BTW your pitch script works like a charm, thanks again!) Steven: I must say I was surprised myself how well the terrain follow mode works. Given that the KSP ground radar points straight down and not forward as any sane terrain following radar would. (Yes yes, its useful for rockets, I know ) That means that I can't do calculations based on "hill coming up in 20 seconds" but have to resort to "HILL! NOOOOOW!". Hence the 9-10 g pulls. Aside from that, the PID controllers do a rather good job. The coding part was easy enough (getting to know kOS aside). The only time consuming part was the PID-Tuning but it always is a PITA, not only in KSP Obviously if you follow the terrain at a radar altitude of 2km rather than 400m the upper/lower bounds for the pitch can be much less, resulting in slower response and less accurate altitude over changing terrain but smooooother flight. If anyone is interested, I did a datalogging run on another flight while I was tuning the gain parameters. It was a terrain following flight with much smoother pitch bounds and a radar altitude of 894m: image here. For a quick glimpse: Light green is the required altitude over terrain, red is the actual altitude over terrain. Regarding those locked controls: Obviously I don't know why they're locked in the first place but assuming there's a good reason for that I believe there is still an option for a more controlled handing-over-controls: One way would be to have the script to lock/unlock controls explicitly, on a per axis basis. set ship:control:mainthrottlelock to true or something like that. That would allow i.e. my autopilot to take control over the throttle but leave pitch/yaw/roll untouched. Or lock only pitch for terrain following but allow me to handle throttle/roll/yaw. I believe that is transparent enough for the programmer to handle and it would avoid fighting-over-control issues which would probably lead to increasing oscillation. Another way would be a "last input wins" approach. Not sure how feasible that is to implement in kOS as that depends largely on how the ship:control section is structured in the first place. Concerning flight performance I don't see any benefit of the "last input wins" approach. kOS trying to achieve (A) while your inputs are trying ( on the same control axis doesn't seem like something that would work in many scenarios. Emergency disengage? Nah... switching off kOS is easy enough and its not like a crash actually matters. Annnnnyway. Back to me figuring out heading and roll *sigh* heheh [edit]@Steven Oh my god I just found the VecDraw video on youtube. I'm so excited now [/edit]

I just thought I'd share a first glimpse of my autopilot (edited for embedding the video)

@Mariano: Oh yeah, that vid started quite something in my head In fact I ended up copying your code for the missile-in-flight part and tweaked it a bit to my needs. I'll put the whole kOS script up once I'm happy with it, with credits to you of course . I'll definitely check your code of calculating the elevation over the horizon, that should be helpful @Steven: Thanks for the link to the coordinate system page. I read it twice by now but that topic needs more time than I currently have Anyway, thanks a bunch, it will be helpful. What I noticed while writing my plane autopilot: As soon as I start setting any of the ship:control:* values, manual steering and manual throttle is completely disabled. Is that a known issue? I.e. with my "altitude hold" program in the autopilot being active (it manipulates ship:control:pitch) it immediately slams the throttle to 0 without an option for manually control the throttle any further until the script is stopped. Similarily when I enable my cruise control (manipulates ship:control:mainthrottle) I'm unable to steer with any of w/a/s/d/q/e. Using ship:control:mainthrottle was necessary in the first place because the "altitude hold" aspect makes using lock throttle to myThrottleVal impossible.

Woah! Thanks for the detailed answer, I think I begin to understand why my attempts were futile Just to be sure, I wasn't implying kOS is at fault or anything . Its awesome, and it has a "0." in front of its version number. All is good Hmmm.... X/Z are not fixed to a point on the surface, that is to GeoCoordinates? That'd imply that Kerbin doesn't have a Greenwich? If so, how do GeoCoordinates work, where is the 0° longitude? One thought crossed my mind last night. When I lock steering to HEADING(90, 20). I go indeed go due east, 20° up and with 0° roll. Is there a way to read my current heading / pitch /roll similar to setting it in that way? Maybe a picture of what I'm trying to do (one of many things) will help. I present, my Kerbal Defense SAM launcher: It is already a working system which tracks a target automatically, launches when target is within range and the missile actually intercepts the target (with a margin for error due to framerate & the physics range load hiccup). Problem is, I'm not happy with it . The parts of relevance here are the washer (to point to the right heading) and the hinge (to adjust pitch toward the target). Both are bound to action groups for easy manipulation in kOS. Since the launcher itself actually doesn't move I can't simply lock steering to VESSEL("target"):direction., obviously. What I do is to move the washer until abs(target:bearing) < 1 and keep adjusting. Easy enough. The hinge currently just moves up for a fixed amount of time to point about 60° up. There is nothing smart involving the hinge. Now, what I'd like to do programatically is two things: - query the angle over the horizon of the target, a.k.a. the pitch I need to point at. Which I think I know how, but there is no point in trying before part two works, which is - query my own current pitch. The missile does have a probe core, so after "control from here" the navball shows the correct pitch. Once I have those two I can very easily move the hinge accordingly until my own pitch matches the targets angle over the horizon. I guess whats screwing with my head is that the navball is showing the information (hence KSP knows my pitch?) I want and that kOS in fact allows me to set my direction with HEADING(h, p) which seems to imply that kOS also knows how to "get" there? Is there a way to query that information? If pitch could be read, how about roll? In an unrelated project I'm trying to develop an autopilot . Sorry that I keep you people, this is driving me mad Thanks a ton again for kOS. It has already become my physics programming environment of choice