Dunbaratu

One thing that might work, assuming you don't mind the time expense of calling another program, is to make the body of the WHEN/THEN be a program file so you can refer to itself inside of itself: Imagine a small program file consisting of just these lines: // This is a program file called "whenResponder" print "doing a thing here". WHEN blah THEN run whenResponder. // Note the recursion. This is the name of this program file itself. Then from your main file, set it up for the first time: WHEN blah THEN run whenResponder. By putting the body of the THEN inside a program file, you give yourself the ability to perform recursion because you can refer to the chunk of code by its name from inside itself, which you can't do otherwise. That might let you break out of the Klein bottle problem that you want a WHEN/THEN that contains itself inside its own body.

Nope. You can only get the strings on the screen, not into variables. I figure in order for those to be useful commands, KOS has to first implement arrays, and then implement a way to get the output of a LIST command into an array of objects instead of to the screen. That's a first step. Then the ability to take an object of type "vessel part" and manipulate it would have to come second.

You're still inserting the hooks, even though they all do the same thing. Now instead of saying "set kp to kp + 1" 30 times, for example, you're now saying "set agHook to 3." 30 times. That fixes the logic problem of doing the thing many times, but not the performance problem of doing it many times.

Correct. Let me describe it for just the case of ag3 - the same thing happens with all the other action groups ones too: Each time the statement "on ag3 set kp to kp + 1." runs, it inserts a NEW event hook into the list of things the KOS computer watches for and it doesn't clear out the old one. So the first time the UNTIL loops runs, there's one instance of looking for ag3 to happen and if it happens to run 'set kp to kp + 1." The second time, there's now two of them, then three, then four, and so on. iF the loop has run 30 times before you press ag3, then all 30 of those hooks get fired off at once, and then kp has been incremented 30 times. If you want to use "on" like this, you have to protect it with a check to see if it's really necessary to insert yet another hook. Basically, only run the "on' command if it got triggered last time. If it hasn't been triggered yet, then just rely on the previous one that's still there. needAg3Hook on. until ... etc ... { if needAg3Hook { needAg3Hook off. on ag3 { ... do your normal thing here (i.e. "set kp to kp + 1.") ... needAg3Hook on. }. }. Each time it runs through the loop, if only inserts a new "on ag3" command if needAg3Hook is true, which it only will be if the previous "on ag3" has been executed after it was set up. You basically need to do that thing for all the "on" commands you're using (not just ag3) , if you're going to do it this way. KOS script could really use some other form of input besides this. The need to protect the hook insertions like this makes it impractical, and using action groups for this gets in the way of using them for what they're meant for. Just a simple "readline" would be a handy addition, even if it's blocking and line-at-a-time.

Too many people have already written scripts expecting alt:radar to work like it does now, so I don't think changing it is a good idea at this stage. But I do advocate making a second type of radar altimeter for this purpose. I've been thinking more and more about this and what would provide a good solution without just having the mod hand us all the terrain information on a silver platter (after all KOS is NOT meant to be mechjeb - we're supposed to do a portion of the autopilot logic ourselves and that means only being able to "know" what the vessel knows). I first described the idea of the craft having a radar altimeter that's fixed in place on the craft itself and thus it rotates with the craft's facing. If we want to aim it in a different direction we have to rotate the craft to do it. I'm not so sure now that this is the right answer because of spaceplanes. With a retro-rocket lander, the engineers would have installed the radar altimeter hardcoded to aim 180 degrees off from the facing (When landing, the craft's facing points at the sky). But for a space plane, they would have installed the radar altimeter hardcoded to aim 90 degrees off from the facing (when landing the craft's facing is horizontal, not toward the sky). That one problem means it would be unfair for the KOS mod to pick one hardcoded direction relative to the facing and call that the direction of this altimeter's aim. That hardcoded direction would either favor spaceplanes and not work for landers, or favor landers and not work for spaceplanes. It can't be made to be correct for both if it's hardcoded. If the altimeter were a new kind of vessel part, then the player could pick its direction when attaching it to the craft and the mod could read the part's orientation to decide which way its radar is aiming. But I have no idea how to make a part and add it to the game. So maybe the only real workable solution would be to let the player pick the direction of this radar in the script. I propose something like this: lock radardirect to (whatever). print "directional radar altitude is " + alt:direct. where "(whatever)" is any of the of usual ways to aim things in KOS script, an R(), a Q(), a vector, etc. i.e. To make it behave like the blue line in my diagram: lock mybottom to facing + R(0,180,0). lock radardirect to mybottom. or, to make it behave like the a clone of the normal old-school alt:radar: lock down to up + R(0,180,0). lock radardirect to down. A clever script writer could actually implement a radar "sweep" this way by successively moving the radar direction, and get an idea of the terrain in a patch of the ground. As far as implementing it, I believe ANWRocketMan is right - Presumably the KSP API knows where the ground terrain is and provides a way for a mod writer to find it, and getting the intersect of a ray and the ground should be doable.

What I would find really helpful, and it really seems quite realistic to me to enable it, would be a variant of ALT:RADAR that tells you the distance from your craft to the ground in the direction your craft is pointed rather than straight down. In other words, if you are aimed 45 degrees off from "up", then don't report the altitude below the craft, but rather report the distance to the ground in that 45 degree angle. The diagram below shows what I'm talking about. Getting the radar distance along that blue line in my picture is what I'm talking about. It makes sense that the radar distance measuring equipment would actually rotate with the craft and give the blue result rather than the green one. And that data is crucial to making a working landing script that can react to unknown landing sites at unknown locations. Because of the inability to read the terrain, I can't really do a "suicide burn" efficient landing because of the case illustrated in that picture. I end up having to guess what the highest ground MIGHT be based on the wiki entry for the body (all the bodies tell you the max elevation of the highest mountain on that body), and design the suicide burn to "land" at that height first, and then descend from there down to the ground. On rocky bumpy bodies like The Mun, that's an enormous amount of error I have to account for.

In no way, in any way, is Notepad++ a "compiler". Other than that, yes this does work.

I have yet to see the line number reported as anything other than zero. Ever.

STEERING is an R() tuple that defines the direction you are telling the ship to point, and FACING is an R() tuple that shows the direction the ship is currently pointing. So, after setting STEERING to R(a,b,c), then you can test for how much FACING:yaw differs from a, and FACING:pitch from b, and FACING:roll from c to see if they're getting close to lined up yet or not. One warning, the rotations are not reliably always mapped down to numbers between 0 and 360. In other words, sometimes a rotation that's really 15 degrees will be reported as 375 instead, which is the same compass point, but if you just compare the raw numbers it looks like it's really far off. So remember to take the values MOD 360. Also, remember that values that are, say, different by 350 are really different by only 10 (i.e. 355 degrees versus 5 degrees). What I've resorted to now to cover all those cases is to just take the sin and cosine of the angles and compare that instead of the angles themselves. That way, for example, if sin(theta) and sin(gamma) are close to each other, and cos(theta) and cos(gamma) are close to each other, then that tells you that angles theta and gamma are close to each other, no mater how they're expressed. That way you get the same result if an angle is expressed as -5, or 355, or 715, and so on, all of which are really the same thing.

(In response to the idea of a double-planet pair) The problem is that to do it right you also need to calculate the proper pull on the spacecraft as it passes between the two planets. That's the Lagrange Point problem. The real gravitational acceleration is significantly different from the primitive SOI body calculation as you rise from one planet toward the other.

It's impossible to give a concrete answer without seeing the code, but here's one quick thing that may help explain it: When KOS tells you there's an error on a line number, the line number it reports to you is often utterly wrong, especially if it's saying line number 0. Just because it says line 0 doesn't mean it really is line 0. It could be anywhere in the program. The line number problem is a bug that seems especially difficult to get rid of, as Kevin keeps claiming it's fixed in each release and yet it keeps happening.

If making a new program from scratch: switch to archive. edit programname. If you have a program already on the local volume and want to move it to the archive; copy programname to archive.

One thing I'm coming to realize is the need to anticipate what the value WILL be at the next iteration, and then pick a setting halfway between that value and the value you have now as the number to work from in calculations like these. In my case I'm trying to make a "suicide burn" landing script that burns the least amount and waits until the bottom to burn, but the error you get from slow iterations means my script is always calculating based on what the situation WAS a half second ago, not what it is now. That "slight" error can mean about 10-20 m/s difference in impact speed. It's slightly different from what you need it for but the basic problem is the same problem. We're both trying to calculate a thing once per iteration of a loop, which is essentially the problem of approximating calculus by using a finite number of timeslices, and our timeslices are large enough to cause error. Here, with amount of deltaV remaining what that means is this: 1 - Keep track of the deltaTime your loop is taking to execute by comparing missionTime this iteration to missionTime last iteration. 2 - Using maxthrust, throttle setting, mass, and delta time, you should be able to calculate a fairly accurate idea of how much your speed is expected to change per loop iteration at this throttle setting: dV per iteration = (delta Time) * ( (current throttle * maxthrottle) / mass ) 3 - decide your program behavior based on what the dV WILL be next iteration. not what it is now. In your case, try this: If the node dV remaining after next iteration is predicted to be zero or less than zero, then adjust your throttle down NOW, but not all the way down to zero. Scale it down based on how much you're going to overshoot. (i.e. if the current throttle setting would give you three times as much dV as you needed to get to zero in the next iteration, then cut your throttle to 1/3 of what it was. That should finish the job in the next iteration.) Or alternatively, for more accuracy, add a fudge factor to reduce the throttle by a bit more than the amount needed to get to zero, so there will still be a bit of dV left next iteration. This will make the throttle slower and slower and slower and make it asymptotically approach the right delta V rather than get there in one single iteration (which is still likely to overshoot a bit).

Yeah I end up having to do the same thing. Vector math is halfway implemented for a few things now, but it still doesn't have everything so sometimes you still have to do it manually: What is implemented: Tip -to- tail vector addition: set newVect to v1 + v2. (indirectly) scalar times a vector, via the new ":mag" operator: // Multiply vector v1 by scalar s1, storing the result back into v1: set v1:mag to (s1 * v1:mag). What isn't implemented yet is cross products and dot products and matrix transformation multiplications. For those you still have to break it apart into its separate XYZ pieces and run them manually, which in a slow language like KOSscript, is really slow. Another feature that would be very nice is to transform a Direction into a unit vector. i.e. V( North) to turn the Direction North into a vector of length 1 in the direction of North. Right now I do this by hand with breaking the XYZ parts up and running the rotation matrix transformation math on the rotation angles in the Direction vector, but that's something like 10-15 lines of KOS script to do a thing that I'm sure is done natively in just one fast function call in the underlying 3D engine.

For Windows there's the Windows IDE for color syntax highlighting for Kos script, but for UNIXy people like me who prefer editing with the VI text editor even when using Windows, I made a crude VIM syntax file for KOSscript code that should highlight the colors correctly for you if you install the files in the right places if you're a VIM user: Here's a screenshot while using the koehler color theme. The syntax file doesn't define the actual colors, by the way. It just categorizes things into parts of speech (statements, comments, strings, numbers, identifiers, operators, etc), and then lets the color theme file pick the colors for them. That way it should work with any color theme choice you have. Note, the usual way for VIM to detect which syntax type it's dealing with is to look at the filename. i.e. if it's called ".java" its a Java file, if it's called ".c" it's C code, etc. But the problem with KOS is that the source code files are named .txt and therefore clash with normal other plaintext files (for which you won't want to have KOS highlighting turned on). Therefore in order to enable syntax highlighting, put this comment at the top of the source file: //KOS And the files are set up to look for that on line 1 as the trigger to turn on KOS syntax mode. Or, alternatively, force kos mode by issuing this command: :set filetype=kos The setup files for it are over here on google docs: https://drive.google.com/folderview?id=0Bxkeai7oN35fV2xCa0Y1RThSYkU&usp=sharing

A pair of double-planets tidally locked with each other. That would be really cool. (Image from Wikipedia). But I suspect it isn't doable because of how KSP only does single-body gravitation calculations. (i.e you can't do it for the same reason you can't have Lagrange points).

The way to make rovers meaningful is to make a form of science points that have to be gathered across a distance. In other words, you turn the device on, move a distance, then turn it off, and to get full points you have to have moved X number of kilometers while it was on. More points if the thing you're measuring actually changed during the rove. (i.e. measuring air pressure or graviolis while driving up a hill (climbing a hill) is worth more because the value of g was changing as your altitude changed.) Measuring temperature while driving from light into shadow is worth more because the temperature changed while moving.

I've seen a few suggestions along these lines, all explained a bit differently, but they all seem like really good ideas. The thing they all have in common is that people keep suggesting some variant of the idea of splitting up science into two different kinds - one kind that transmits well, and one kind that doesn't transmit well. Regardless of the exact means of doing it, this would mean there's a reason to return things to Kerbin when right now, there just isn't. The only thing you lose from transmitting right now is patience as you spam the transmission over and over to get a value that approaches the asymptote of the same value as a return mission would give. And the logical way to do it is to distinguish how much of the science value is "data only" and how much is "physical". (And some experiments might not be 100% one way or the other - some might be, say, 25% data and 75% physical.) The value that is data-only should be worth exactly the same regardless of whether it's transmitted or returned (no spamming anymore). A notebook containing the handwriting: "pressure: 0.2 atm" isn't worth any more than a data stream that encodes that 0.2 as bytes. But the physical experiments would only work if returned.

When you say "yaw freely" do you mean from live user input on the "A" and "D" keys, or from another variable in the script program somewhere? If it's live user input I don't think there's a way to do it, but if it's from another variable in the program there should be a way.

For all the people who've been having problems getting "lock" expressions to work right, here's a potential cause of the problem I just discovered through trial and error: https://github.com/Nivekk/KOS/issues/197 Workaround: Write your lock variable names entirely in lowercase until it's fixed.

Every time I try to use the new "set target to xxxx" command with xxxx as either: mun, Mun, "mun", "Mun", kerbin, Kerbin, "kerbin", or "Kerbin". It just makes the words "no target" appear on the screen and nothing happens. (Edit: Never mind: I see the problem now. It's inherent to KSP not KOS. KSP won't let you target your current SOI body, nor will it let you target the parent body of your current SOI body. So if you're orbiting the Mun, you can't target the Mun nor can you target the Mun's parent, Kerbin. But you can target anywhere else in the solar system.)

I'm the same way. I don't think a video is an appropriate way to teach an inherently bookish, textual thing like a programming language. But it's better than nothing and other people can transform the videos Kevin makes into written documentation.

From that it seems as if somehow the program is treating things like strings rather than numbers at some stage, so that the statement: set tVal to tVal + 0.02. Is interpreting the "+" sign as a string concatenation instead of as addition. It doesn't seem valid for it to be doing that. Try various different ways to express it to see if it helps getting KOS to stop treating 'tVal + 0.02' as a string.

Supposedly although velocity is meant to be a synonym for velocity:orbit it isn't quite. It's probably a good idea to avoid using it and instead use velocity:orbit, like so: set vorb to velociy:orbit. print vorb:mag.

I haven't had a chance to try it yet but there appears to be a new full-size ZIP file on the spaceport page now.