Dunbaratu

With 0.61 my 0.5-made script now works again. The command "lock steering to up * V(x,y,z). " now works again! Yay. But I just can't wrap my head around the VELOCITY:SURFACE vector. I'm still having to use my old method of deriving it from the latitude and longitude and vertical velocity. And I think the reason is that the frame of reference for the vector is NOT based on the surface of the planet but based on something in space that I don't know what it is. What is the frame of reference for the vector VELOCITY:SURFACE ? In other words, which direction is X, which is Y and which is Z, and where is (0,0,0) located in that coordinate system?

That CALL system has potential. I like it. I assume the CALL command is what was being talked about with hooking to other mods? I assume it's a way to call functions written outside of KOS?

Yeah I had an introductory computer graphics programming class back in college, back in the day, but the word "Euler angle" was never even mentioned in the class. It was all matrix multiplication and Quaternions. That's why I was so confused trying to use the rotation system in this mod. I was expecting that a thing called a rotation would only rotate space, rather than also skewing it into a non-orthogonal shape which is what a Euler rotation does, apparently.

Ah I didn't know that either. There's a lot that it seems the only way to know it is to read the source code. Well, anyway multiplying the range by an exponential factor per antenna is a great idea, but 10 is probably too small of one given the distances in the solar system. If it takes 3 just to get to the Mun imagine trying to make a Voyager-like mission. The idea of using Remote Tech to manage the ranges is great, but it has to also be balanced against the need to make KOS also be a mod that can also standalone without Remote Tech. Anyway, thanks for the information (and the 0.61 bug fix so quickly).

Yes that would be good. I was waiting for baited breath with the promise that RT will have a computer software system when I gave up on waiting and came here to KOS instead.

I have antennas. But the Mun is too far away even with antennas.

NASA sends new software to real probes all the time. Even ancient ones like Voyager had updates sent during the mission from a LOT farther than 150 km away. This seems like an artificially short limitation to not allow it above 150k. I would argue VERY hard that the ability to send code updates to probes needs to be allowed, especially in light of the fact that you can only use a good text editor on code in the archive back home, not on code in the probe.

Oh interesting. So that's why. I don't mind the way it works now. It's just not obvious to the user THAT it works that way. Getting the message that the archive is "out of range" when you 'switch to archive' should probably be a bit more explanatory, like "At long range, archive is only accessible via COPY ... FROM ARCHIVE." might help. As it is, it makes you think the range is too far to do ANYTHING with the archive - even copy files from it.

I don't understand your description. In the first paragraph it sounds like you said you're not supposed to be able to copy from the archive to the probe, and in the second you say you are.

The existence of the kerbal alarm clock doesn't change the fact that an instant drop to minimum time warp (1x) is a good thing to have. They already do it for the throttle, where you can throttle back gently with CTRL or throttle all the way down at once with "X", and for the same reasons that that is useful, so too would be an instant "throttle down" for time warp.

Better idea: Make the little "SAS" and "RCS" buttons on the navball clickable to toggle them. Having both a hotkey AND a mousey way to do things is a good thing, and helps the newbie experience.

I said "remote" probes. Meaning ones out in space not ones on the launchpad. Once you're far enough away from home, the command "switch to archive" fails.

Yes and no. You can edit programs in the non-archive volumes, BUT only using the KOS terminal, and its limited editor, not using an external text editor. (Well I guess you *could* edit them with a text eidtor, by editing the persistence file in the save game but I really don't recommend doing that, and besides you have to quit and reload the save to do it that way.) It should be noted that if you want to copy programs from archive to the remote probe, you have to do it in this order: On Probe: switch to 1. copy progname FROM archive. rather than in this order: switch to archive. copy progname TO 1. It took me a while to work out that this is how you're expected to be allowed to send updates to the remote probes.

I was confused enough about this when I started that once I finally did work it out from trial and error I decided it needed to be documented better so I wrote this page on the wiki: http://kos.wikia.com/wiki/Archive_and_Volumes I hope that helps.

I've often had wonky behavior from the KOS unit that could be fixed with the far less drastic step of rebooting the KOS unit rather than restarting the whole game. (rightclick the part, toggle power off, then toggle power on again) Give that a try first next time there's a problem. Sometimes it works, sometimes it doesn't. I've found it especially useful when its one of the problems that causes it to start deciding to make the text you type invisible.

That's correct. If you want the *actual* surface speed like the navball gives you have to use the velocity:surface vector's components and run them through the Pythagorean formula like so: set velSurf to velocity:surface. set realSurfSpeed to ( velSurf:x^2 + velSurf:y^2 + velSurf^z^2 ) ^ 0.5 . The reason for the intermediate step of "set velSurf to velocity:surface" is that the system doesn't understand a term with two colons in it like so: "surface:surface:x".

Should solar panels work when inside of fairing shrouds? I just noticed that my batteries recharge from my solar panels even when the fairing containing them hasn't been opened yet and there shouldn't be any sunlight reaching the payload bay.

That's good. Also, like I said I'd have no problem doing it myself if I had access to arcsin, arccos, and arctan.

It doesn't seem that odd to me. Think of the script KOS sees as the "compiled" version and the one in the IDE as the source. I may add that sort of functionality to my comment stripper by having it shorten variable names for the sake of the 10k limit.

It was mentioned in Kevin Laity's video on his dev blog. They look like C++ comments: // comment Like that. It's a bit frustrating that a lot of the information is available ONLY in the form of videos. As we discover things we're trying to update the wiki but for a brand new release the video is often the only way.

Yeah I still have the older 0.5 ZIP file laying around so I'm going back to 0.5 until vectors work again.

In 0.6 the ability to steer by a vector seems to be impossible now. How do I do this? Am I missing something? As far as I can tell, in 0.6 only the following methods of steering now work: The up + R(...) method. The up + Q(...) method. The new HEADING ... BY ... method. These methods, that worked in 0.5, no longer work: up + V(...) up * V(...) They now say "Expression error." It seems that support for steering by vector has been removed. This is a problem because without the reverse trig functions arctan, arccos, and arcsin, I don't know how to convert a vector's XYZ into the necessary angles. Which means I can't steer using the new vector:surface. The math functions needed to transform those XYZ's into angles aren't there. I'm considering implementing one of the approximation methods for the arc trig functions by series or by interpolation, just to get around this hurdle, and that seems a bit excessive, as the hurdle feels entirely artificial. Right now because of the loss of the V() functions, 0.6 actually is less useful than 0.5 and I'm sad that I installed over the top of 0.5. I'd like to go back until these problems are dealt with. I wouldn't mind the change to only be able to steer by angle if it was accompanied by the math functions to allow us to get an angle from the lengths of a vector (arcsin, arccos, arctan). The sad irony is that in the same update that gave us the very useful velocity:surface vector, the ability to use that vector went away.

Except that I just discovered that support for this: lock steering to up * V(1,2,3). just went away. I can't use the V() expression with "up" or "north" or "steering" anymore in 0.6. So now I'm trying to figure out how I'm supposed to convert from xyz distances to the new angle-based steering when the language no longer supports that expression, and it doesn't have the arc trig functions (arcsin, arccos, arctan) to convert from vector lengths to angles. I'm getting the impression that despite giving us more information the removal of that expression "up * V(1,2,2)" may make it actually harder in the new version. I'm still messing with it trying to figure out how to do what I used to be able to do.

I wrote that before I found out that we now have access to :x, :y, and :z seperately now. That didn't used to be supported, which limited the usefulness of vectors. Yes, of course now that we can get the x y and z parts all you have to do is this: set surfProVec to vector:surface. set surfRetroVec to V( 0 - surfProVec:x, 0 - surfProVec:y, 0 - surfProVec:z ). (The reason it says: "0 - surfProVec:x" instead of just "-surfProVec:x" is that I haven't tested yet to see if unary minus signs are being parsed correctly yet. They didn't used to be.)

VECTORS' XYZ's WORK NOW! It doesn't seem to be documented anywhere, but I just tested it and noticed that this now works: set vec to V(1,2,3). set xPart to vec:x. set yPart to vec:y. set zPart to vec:z. This is major. If we can get the 3 parts now, then that opens up a lot of new options. For example, dot products and cross products and scalar magnitudes. With dot products for example, you can answer the question "how close are these two vectors to being parallel to each other?" With access to the 3 parts, we can calculate things like inclination-altering burn directions (the normal and antinormal directions will be perpendicular to the prograde vector). Thank You. THIS, more than anything else, is what I've been wishing for. I have no idea if it appeared in this version or an earlier one, but I just tried it on a whim and was glad it now exists.