Dunbaratu

The problem is that in real vector math there's more than one type of "multiply" and I'm not entirely sure which type is being done here.

Wow. I guess now that I think of it I never actually tried driving straight through the rocks. I just assumed they were real physical barriers and took care to never run into them.

Nice that the surface:vector is there. Feels like a waste of time that I went through the effort of finding it from the latitude and longitude, but it's better now that it's there. Is there anything in the underlying mod API that lets you detect the existence of scatter rocks? If you have terrain scatter on, I think it would be a fun challenge to write a rover script that tries to head toward a destination location, BUT has to have the logic to stop and steer around rocks on the way. Right now there's no way to detect a rock without hitting it and noticing there's something preventing motion. Anyway, it's a good update. I like it.

That wouldn't be true the way I was describing it to work (you'd edit in the IDE a file which is NOT the one KOS sees. You export the file you edit it over to KOS's archive, and only the exported version is missing the comments, not the original that you work on when you edit.). But it's largely moot now since the 0.6 KOS update has its own comments anyway now.

While I seriously love this mod, the fact that the script language is not being parsed in a properly recursive fashion becomes painfully clear at times and you may have run into one of those. Instead of every expression working the same way everywhere, each high-level construct defines its own syntax rules and they're not always the same. For example, one command might allow runs of 1 or more spaces between terms while others allow only exactly one space, and so on and so forth. OR as another problem I just ran into, the trig functions sin, cos, and tan don't allow parentheses inside themselves so you can't do sin( abs( a ) ) for example without doing it in two different statements.

Supposedly support for thinking in those terms is planned for the future. But for now it works like this: In the expression: up * V(x,y,z). The positive x direction is north, and the positive y direction is west, and the positive z direction is up. So to translate compass points to X and Y you do this: x = cos( compassPoint ) * cos(pitchUp) y = sin( - compassPoint ) * cos(ptichUp) z = sin( pitchUp ) (Where pitchUP = 0 on the horizion, 90 at the center of the blue part of the navball, and -90 at the center of the brown part of the navball.) I haven't actually tried these numbers, mind you. This is just from guesswork in my head. Give it a try to make sure I've got the directions right. You may have to fiddle with the trig a bit if I got it wrong.

Ironically it would be easier if it was MORE complex. It's the simplicity that makes it hard because it does so little you have to work out how to obtain missing information yourself. I have not experienced this. Could there be a problem between KOS and another mod on your install? The editor in the terminal window is extremely limited. Most people have been editing the code behind the scenes in the text editor of their choice instead. If you go to Plugins/PluginData/Archive you see a text file for each program you wrote and saved in the archive volume. You can just pull those up in a text editor and edit them outside the game. Or make a new file called something.txt and save it there, and it will become a program called 'something' in the game. What do you mean by "don't work?" You can't type them? Or you can but they don't function right? The rotation system using R() tuples is *REALLY* messed up unless you're a computer graphics professional or a mathematician who's experienced a thing called "Euler Rotations" before. It doesn't work like normal mathematical rotations work, because it bends axes into non-orthogonal shapes making it messy to work out how to rotate around two axes. If you've had introductory understandings of the math of 3D space you'll think the word "rotate" means all three axes rotate together and remain orthogonal to each other. But Euler Rotations don't do that, and in a sense are slightly mis-named. They're not really rotations but rather they are distortions of space and understanding them is an advanced topic. So instead it's far easier to use the V() system to just point at a vector of your choosing. It works like so: lock steering to up * V( x,y,z). This will let you just point along a vector. The markup is [ C O D E ] (minus the spaces) to start the section and [ / C O D E ] (minus the spaces) to end it.

In my case because I was in the midst of a loop anyway I just got the snapshots once per iteration and checked current versus prev iterations. I think that helps because it meant the time is farther apart, and that smooths out the variations better.

The trick was my addition of putting the delta time in the calculations. That way even though each loop iteration doesn't necessarily take the same amount of time, that is accounted for. While it might be true for example that in one iteration the craft moved 50 meters while in the next iteration it moved 100 meters, I found that usually that was happening because the second one took twice as long as the first, not because it was giving incorrect or widely swinging data. Once I divided by the amount of time elapsed between iterations (via the missiontime variable), the differences smoothed out and became far less swingy. Its still a little inaccurate but it's more workable than it used to be when I assumed a fixed iteration time. In the interest of making this not be just a mechjeb clone (the whole point is to write the autopilot yourself), I prefer opening up the raw data and letting people work it out themselves. For example, if KOS would let us find the current time from the start of campaign (rather than just the missiontime), that would mean you could find the current position of a planet by running the on-rails calculation given the planetary stats, its start position, and the current time.

Incidentally, I thought it would be really useful to have a generic publicly-maintained file everyone could share that does this sort of thing with planetary stats and lets you run it up at the top of your program, giving everyone a sort of standardized set of variable names to use for this sort of thing. Here's the example I started building for my own purposes. Right now it only has Kerbin and the Mun and I was going to add more as needed: (YES I know comments like this don't really exist. I have a small Perl script I run to publish my code to the archive directory and as part of doing that it strips the comments out. Thus I can have comments in my source without the language ever seeing them.) # bodystats: sets up variables for use in programs # that need stats about the orbital body that is the # current SOI. Looks up the body name and fills # the appropriate variables. clearscreen. print "Settings for current SOI body: " + body. print " ". # Placeholder Defaults in case I didn't code stats for current body. # ------------------------------------------------------------------ set bodySurfaceGrav to 10. # The m/s^2 at the body's surface. set bodyRadius to 500000 . # The radius from center to equator. set descendAGL to 50000 . # The highest AGL at which descents might start. set hoverAGL to 100 . # the AGL where a descending craft should hover. set descendTopSpeed to 2000.0 . # Desired speed at top of descent profile. set descendBottomSpeed to 4.0 . # Desried speed at bottom of desecnt profile. set bodyLandingSpeed to 4.0. # Desried speed to come down from hover to set bodyAvgGround to 1500. # The body's average ground altitude to use # When the radar is too far away to read the # real ground altitude. set throttleGentle to 80. # Throttle gentleness. # too low and the throttle is twitchy. # too high and its too slow to react. set c to " ====== deviations for each body ===== ". if body = "Kerbin" { set bodySurfaceGrav to 9.802 . set bodyRadius to 600000 . set descendAGL to 70000 . set hoverAGL to 50. set descendTopSpeed to 1800.0 . set descendBottomSpeed to 2.0 . set descendLandingSpeed to 4.0 . }. if body = "Mun" { set bodySurfaceGrav to 1.63 . set bodyRadius to 200000 . set descendAGL to 20000 . set hoverAGL to 15 . set descendTopSpeed to 542.0 . set descendBottomSpeed to 2.0 . set bodyLandingSpeed to 2.0. }. print " ". print "bodySurfaceGrav = " + bodySurfaceGrav. print "bodyRadius = " + bodyRadius. print "descendAGL = " + descendAGL. print "hoverAGL = " + hoverAGL. print "descendTopSpeed = " + descendTopSpeed. print "descendBottomSpeed = " + descendBottomSpeed. print "bodyLandingSpeed = " + bodyLandingSpeed. print "throttleGentle = " + throttleGentle. print " ". print "('AGL' means Above Ground Level to distinguish ". print "from sea level altitude.)". print " ". print "You may change these variables with the 'set' ". print "command before running other programs to try ". print "other settings.". print " ". Obviously some of the settings in there are meant for things my own scripts need and probably would need to be stripped out if this was made generic and public. Also the print statements don't need to be there but I liked having them during my testing. Things I was thinking could be in it: bodySurfGrav (i.e. 9.802 on Earth or Kerbin). bodyRadius bodyMass (You need this if you want to calcluate the gravity at other altitudes besides sea level, for example if you wanted to calculate where geosynchronous orbit is.) bodyAtmoHeight (altitude above sea level where atmosphere ends. Zero or -1 for airless bodies.) bodyAtmoPres (how much atmosphere pressure at sea level? from this plus atmoHeight you can calculate it for other altitudes.) bodyYear (Number of seconds for body to orbit the sun. Perhaps useful when planning movements.). and so on. Anything else that would be useful? Also, it shouldn't JUST depend on the current body. There should also be a way to do a lookup for other bodies to get stats on target planets. So since there's no real arguments you might devise a system you call something like this: // Example to get Kerbin's grav and Mun's grav into two different variables: set bodyQuery to "Kerbin". run bodystats. set kGrav to bodySurfGrav set bodyQuery to "Mun". run bodystats. set mGrav to bodySurfGrav. Would a thing like this be useful to people? The reason for the klunky extra lines (set a variable, run the program, copy the variable into a result) is to get a cheezy way to pass parameters without having real parameter passing.

This would be far faster to calculate and much cleaner than what I ended up resorting to. But the problem is that you can't obtain the three XYZ components of you orbital velocity vector. If you *could* then you could just subtract the surface speed of the planet (plus a bit for your altitude as you point out) from just the X component and that would be that. Done. But there's no access to the 3 parts of the vector so that isn't an accessible solution right now. I did think of that possible solution and rejected it for that reason. If I do get access to the XYZ components later I may change the code to this simpler solution. I ended up having to do it this way. I work out how much distance is covered by the delta in latitude and longitude angles.

On the skycrane. Yeah it sounds similar to what I did. I run some quadratic math to guess out what a preferred speed would be at a particular altitude in the descent. I don't just want to linearly slow down as that eats a lot of fuel. I want to do most of the retro burn at the bottom. If you descend too slow then you're wasting fuel but you shouldn't descend faster than the TWR is capable of correcting for at the bottom. So I sort of fudge it by comparing maxthrust to mass to decide how to "shape" the descent speed envelope - low TWR means I want to slow down from higher up even though it wastes fuel, and high TWR means I want to let it drop more quickly and do all the braking at the end. But at any rate after working out the 'ideal' preferred speed at a given altitude, I check the actual speed to see if it's above or below that, and calculate at the current mass how much thrust would provide me with "nuetral boyancy" against gravity, and if I'm going faster than I wanted then I thrust more than that neutral amount, or slower than I wanted means I thrust less than that. It's a bit fudgy but it seems to work. Getting it to be gentle enough to perform the hover stage right, while at the same time being harsh enough to thrust high when it needs to on the descent was a bit of guesswork. Basically the amount by which it deviates from the neutral thrust level depends on how far off the actual speed is from the desired speed. The further off it is, the more it deviates away from neutral thrust, with the degenerate cases being max thrust if it really has a lot of slowing down to do, or no thrust if it's not falling anywhere near fast enough. I just posted it in the above post. Give it a look and let me know what you think.

I don't know how much utility there will be for this, because maybe there will be a proper surface:prograde vector in the language some day. But until there is I made a program that (sort of) can calculate it. It's dead-on accurate when used over the mun, but it becomes way off when used in an atmosphere because the air drag is throwing off the calculations, I think. (It's measuring it based on how the craft is actually moving, not on how it WOULD have been moving had there been no air.) It's a longwinded thing, so instead of posting a wall of text here, I put it over on the wiki as a tutorial and example: If you just want the code and want to skip the explanations, pan down to the parts labeled "File 1", "File 2", and "File 3". Link --> http://kos.wikia.com/wiki/Tutorial_-_Finding_surface-relative_data_(prograde/retrograde_directions)..

Ah man, you beat me to it. It looks great. I'm making a very similar skycrane deployment program and was trying to test it with different craft on different planets before posting it - it's supposed to work with any craft but the sticking point is that it only works on craft I designed. When I tried using it by attaching a KOS unit to the stock skycrane rover example that KSP comes with (and add a bit more fuel rings because of the KOS's weight), the crane's idea of which way is the "top" of the craft suddenly flips upside down the moment the rover is dropped. I have no idea why (i wonder if the stock design is built with an upside down command module in the skycrane? When the rover decouples the upside down command module takes over?) I wish I had the full paid version of FRAPS because it really needed to be recorded. It's rather funny. The crane descends beautifully, nice and gentle, comes down and hovers just right, deposits the rover gently on the ground.... and then flips upside down and angrily slams itself as hard as it can into the rover at full throttle. (It's executing the safe escape sequence, but with an inverted idea of which end of the craft is the top.) At any rate as part of this I have some code to get around the fact that there's no surface-based prograde vector. I found a solution to that problem that works that I'll probably post on the wiki's examples page.

I think comments in the IDE that are NOT in the kOS language might be useful. The idea is that when the IDE puts the code out into the archive directory it publishes an export version of the code that strips comments out. So they only exist in the source code inside the IDE but not in the KOS module. That also has the advantage of them not contributing to the 10k Volume limit. The version I have in a little perl script does this (it uses Perl and Bash style comments ("#") rather than ("//") but it could be adapted to use // instead. Original code in my text editor: # header comment describing my program. # this gives a long winded explanation. # and could be many lines long print "Welcome to myprog". set sVel to 0. # surface velocity variable. #... (etc)... Which then turns into this after stripping: print "Welcome to myprog". set sVel to 0. (It turns the comment lines into blank lines rather than deleting them so you still get error messages from KOS using the same line numbers.)

The way the steering system works it seems to need a bit of time to find its own head when you first use a "LOCK STEERING TO...." command. It will spin about all axes before settling on the direction you gave it. I suspect it's doing something to "learn" its rotational controls by trying them out and seeing what happens. But after it's rotated through all three axes it will settle down and work right. It just means you need your program to take over the steering a good 5 to 10 seconds before it's actually needed.

People are talking about comments. Are there comments? The kOS langauge doesn't have them but does this IDE add them (and then presumably stripping them out as it publishes the code to kOS). What do they look like? I ask because I developed my own homebrewed comment system for my development that does that. I edit a file I call blah.ksc (KSC for KOS source Code), and then I run a little Perl script that reads through all my .ksc files, filters the comments out of them, and puts the result into .txt files (which kOS will use). I'm considering also adding a variable name shortener and de-indenter to it, thereby allowing me to write nice pretty code with long variable names and good indentation and comments, that then gets crunched down to a tighter form for KOS to execute. This is because it feels a bit unfair that the 10k limit on a volume penalizes me for writing readable code. Does this tool have that sort of feature in it? If so it might be enough to make me want to use it despite being an old guy with typing fingers trained to use vi.

I too had a syntax error on "break." start happening where it was fine before. But luckily its at a spot in the code where the loop in question happened to be the last thing in the program so the break was there to end the program anyway, so it didn't harm the logic. BUT, if it happened on any loop that wasn't the last thing in the program, and there were important statements that came after that loop, then it would be fatal to that program's logic that "break." started causing syntax error.

There's two different questions here - I'll address them seperately: 1 - How to edit programs outside of KSP: The plugin stores the master archive programs outside the saved game files. They're stored in the plugin's directory, here: Kerbal Space Program/Plugins/PluginData/Archive/ If you have a program called 'myprog" in the archive, there will be a text file for it called: Kerbal Space Program/Plugins/PluginData/Archive/myprog.txt There is a one-to-one mapping between files in that folder and files in the in-game archive, so you can edit a file in a separate text editor and store it there, and it will appear in kOS right away in its archive volume. 2 - How to keep programs saved when reverting the flight: Anything in the volumes that are NOT called "archive" exist only on the vessel itself. (They're stored inside the persistent file in the save folder). Only the things in the archive folder exist outside of any specific vessel. To save a program between flights, just make sure you've put it into the archive volume. They way you're meant to use it is that you build up a library of several little programs and store them in the archive volume, and then when launching a ship you first copy the ones that ship will need to its own volume before launching it. The archive is the master copy of the program in the mission control's mainframe. There's a wiki about them here - this page was just written earlier this afternoon: http://kos.wikia.com/wiki/Archives_and_Volumes

I figured it out, again by reading the GitHub code because the error message itself wasn't describing the problem, and the problem was a completely undocumented (as far as I can tell) fact that's REALLY important for the end user to know about: That undocumented fact is: * The archive has unlimited capacity, but any volumes other than the archive have only a limited capacity of 10,000 bytes per volume. If you try to copy a file FROM archive to the current volume it will check against this capacity and refuse the copy (without explaining why) if it would exceed the limit of 10,000. Weirdly it's only checked in the FROM direction and not the TO direction. So it's possible to overload a probe with more than 10000 bytes of code on the launchpad by copying from the archive to the volume and not realize you'd filled it beyond capacity. Then later after it's launched and you're far enough away that you have to copy FROM the archive rather than copy TO the volume, you can't alter any of the software with a new update because THEN the check is being done when it wasn't before.

While this does SORT of address the problem by giving people a way to avoid using the current R() system, the real problem isn't that rotations are confusing. They're not. The problem is that EULER rotations are confusing. Intuitively you'd expect the R() tuple to give you an orthogonal rotation, not a Euler one. It's the TYPE of rotation it gives you that's confusing, not that rotations in general are confusing.

Yeah. Although the components of the R() vectors are NAMED "yaw", "pitch", and "roll", once you combine more than one of them together they're not QUITE the same thing as aircraft yaw, pitch, and roll.

Has anyone else seen this problem? It has to do with the COPY command. Some of my programs can be copied in the "to" direction but not the "from" direction (making updating them on a remote probe impossible). Here's an example: This fails: switch to 1. copy hover from archive. File copy failed When at the VERY same time, this works: switch to archive. copy hover to 1. switch to 1. And it's not consistent. Its only some files that fail. Some files work so I know the probe can get to the archive to copy. In fact, this problem happens even when sitting on the launchpad at Kerbin so it's not a range issue. It's making it impossible to update the software on my remote probes because they can only copy software by issuing a COPY ... FROM command while in their local volume, and can't do a COPY...TO it while in the archive because they can't switch to archive.

I couldn't understand this either and finally wrapped my head around it with a lot of time on Wikipedia and a little peeking at the GitHub code. What it boils down to is that the rotations with R() aren't really rotations in this language. They're "Euler rotations" which aren't anything like what the English word "rotation" means. And the fact that they're "Euler rotations" was not documented in the readme, and it's NOT what a person would assume when told they're doing a "rotation". Doing R(n,0,0) or R(0,n,0) or R(0,0,n) all work sensibly, but once you have two axes in there and try something like R(n,r,0) (which is identical to saying R(n,0,0) + R(0,r,0) ) it goes all wonky. And this is because it's not REALLY rotating space but rather is skewing space. Euler rotations are very much NOT rotations, by the normal English meaning of the word "rotate". If you draw a cube in orthogonal space, and then apply a 45 degree Euler "rotation" to that space, you don't end up with a cube rotated 45 degrees which is obviously what you'd picture in your head when you hear the word "rotate". Instead you end up with a cube that got warped into a skewed shape with stretched parallelogram-shaped sides instead of square-shaped sides. Euler "rotations" don't rotate space, they skew it. They end up only rotating only one axis at a time while leaving the other two axes fixed where they were, resulting in a non-orthogonal coordinate system. This is what the R() system is doing to the coordinate axes, and this is why the rotations don't make any sense once you try to do more than one of the three axes. The second "rotation" ends up happening in that skewed coordinate space that the first "rotation" set up. I would love it if the R() system used proper ordinary rotation of all the axes as an orthogonal set (Intrinsic rotation). (You can't get gimbal lock if you keep the axes orthogonal by rotating the entire grid.) I agree. If the goal was to make the language accessible to the everyman, then the decision to use Euler rotations was definitely not the way to go. Most people are going to have a picture in their head that looks nothing like what a Euler rotation does when they hear the word "rotation". It's not intuitive.

That's correct. What the current "TARGET" direction means is basically the "purple" marker on the navball.