weissel

Kindly read the part where I "set pitch to ..." and, later in the ascent, "lock pitch to ...". "pitch" is a variable containing the pitch I want to archive, not the pitch I currently have. I use "pitch" in "lock steering to heading 90 by pitch." (which is a deprecated way to lock steering). Since I am only pitching in the yaw axis, I make the pitch I have available as the current yaw angle versus the straight up direction, using: lock dircheck to up * R(0,0,180). lock fyr to facing:yaw - dircheck:yaw. I tried to make that all clear by including all relevant lines in the code snippet. Below 300m I run on SAS btw., that's why I turn it off there.

Not intending any disrespect, but ... at what granularity does a "truly multithreaded" system interrupt the execution of one thread for another? And what's the rationale for that exact granularity? how do you execute things in parallel when you have a single core machine? You do not claim single core machines can't have threads, right? have you ever benchmarked simple and complex statements in kOS, and looked what happened if when code ran at the same time? If not, you're in for a surprise ... what do you call these non-threads, btw?

Of course you can run several programs at the same time (or nearly so) on one unit. Both in the real world (time sharing the resource, running on interrupts, see also the Apollo Flight Computer and it's famous overflow) and in kOS. Look at some code helping to evaluate a gravity turn curve and/or ideal speed curve (for a given craft): ... lock dircheck to up * R(0,0,180). lock fyr to facing:yaw - dircheck:yaw. ... when (airspeed > 2) then { until (altitude > 70000) { wait 0.2. log round(altitude) + "m, " + round(airspeed,1) + "m/s, " + round(pitch,1) + "deg, (" + round(fyr + 90,1) + " real / " + round(pitch - fyr - 90,1) + " off) " + round (tVar*100) + "% at " + round(missiontime,1) + "s" to gravityturn. } } ... when altitude > 300 then { set pitch to 88. // get away from the pad! sas off. lock steering to heading 90 by pitch. //note: DON'T use "heading ... by ..." any more }. when altitude > 8000 then { lock pitch to 80 - (altitude / 1000 - 8)^0.7 * 3.5. // experimental values, probably really wrong }. when (altitude > 39000 or pitch < 10.5) then { unlock pitch. set pitch to 10. }. ... lock throttle to tVar. stage. until (altitude > 30000 or apoapsis > 75000) { ... (try for ideal speed) ... } ... (circularize with external scripts - vary prograde in a binary search, then execute node) ... ... (log the amount of fuel left) ... 2 threads running most of the time, a third one pops up at predetermined points and does a bit of work. In fact, there's another when+until in the original code, printing (pitch) stats every time unit and longer than the other when.