Dunbaratu

The same antenna range that lets you perform "copy" operations from the archive also lets you perform "switch to archive"... making it sort of pointless to bother storing code on the probe and dealing with the 10k limit.

The basic advice about building a parser yourself is... don't. The algorithms for how to parse language text are so well known and well studied that there's a zillion libraries already out there to do all the work for you. Only make your own if you're trying to make parsers because you're trying to teach yourself that subject. Here's an introductory list of known ones to start from: http://en.wikipedia.org/wiki/Comparison_of_parser_generators KOS doesn't use anything like this which is part of the reason its syntax gets a bit wonky at times (expressions are defined at the top level instead of having a recursively nested list of building blocks, which is why expressions that *should* work don't a lot of the time).

The antenna range calculations changed in 0.65 so it's not QUITE as bad as it was before, but it's still going to require a few. What would be great would be if it was directional. If the dish antenna is aimed at kerbin you get better range than if it isn't. But before that can be a possibility we have to have the ability to get data on objects more than 2.4 Km away, and on objects that don't have their own SCS on them. Right now the way the data gathering about your target's stats works is that the target must be a vessel and must be loaded into the full simulation system (not on rails). This makes getting data on planets impossible unless that system is handled differently. Heck if we could just query the universe time (as opposed to just the mission time), we could devise our own equations to work out where planets and moons have to be using our own homebrewed "on rails" calculations.

If it is possible to instantly stop all time warping by clicking the green gui buttons then that proves that the problem is NOT that the physics engine can't do it.

That's because that advice is CORRECT. If you absolutely need SAS to make your launch work, then you DO have an unstable vehicle. Performing a launch without the aid of SAS is easy if the craft is not wobbly and has symmetry. Using WASD to keep the nose pointed where you want is easy - and in fact it causes LESS wobble and lets you launch rickety designs that SAS would shake apart. I don't use SAS because it's needed. I use it because I want to take a break and take my hands off the keyboard. If you use it because it's impossible to launch without it then something IS wrong.

It looks like on GitHub someone is working on a way to log text data to the hard drive of the KOS part. Perhaps when that exists one could write to a known filename on the archive drive (assuming you have antenna range to do it) containing Kosscript commands, and another KOS part elsewhere in the solar system (assuming it has antenna range to archive as well, and is close enough to be loaded and running and not "on rails") could continually run that file from the archive as code over and over until it sees an expected change to a variable. Thus modules could write snippets of code in the "log" files for other modules to run. Whether or not this works will depend on whether they let us make log files that have *.txt extensions so they look like the program files.

I've seen such horror stories on mapsat being such a mess right now spiking CPU usage that I'm not installing it until it gets an update. But otherwise that seems like the right approach which is why I gave up on trying to detect slope in both directions as a solution. (Also, trying to store a field of data points from which to build an idea of ground slope is a bit of a pain when the language doesn't have arrays or sets or any sort of aggregate data type at all.)

Why not just link to that last URL? Because I can't see into the future that's why. Check the dates on the posts.

That's the thing I described as having no effect at all. I described two different things I'd tried, although I admit I didn't say it very clearly. Let me try describing it again: Thing 1 I tried: lock wheelsteering. What happened: Nothing at all. Drove in straight line on existing heading, ignoring the setting. Thing 2 I tried: lock steering. What happened: Turned to heading but then kept on turning. Was not just a case of oversteering because it didn't turn back again. It just kept going in a circle.

Has anyone gotten wheelsteering to do anything? It seems to have no effect right now. I tried "lock steering to 90 by 0" to get a rover to drive on a heading of 90, but all it does is just drive in circles when I do that.

You could put a do-nothing loop at the end to keep the program running: until 0 { wait 1. }. To wait 1 second, then wait 1 second again, then wait 1 second again.. etc. When you want control back you'll have to bring up the terminal window and "CONTROL-C" inside it. Obviously if you have something more sophisticated to check for to trigger the end use that instead. You can't make a null loop body in KOSscript syntax so *something* has to go in there. It may as well be a wait statement. Besides, I can't shake the old UNIX programmer habit of considering all busy-loops with no blocking statements in them to be Very Bad Practice, even though in KOSscript you're not multitasking the SCS CPU with anything else so it doesn't matter. I just can't bring myself to do it , thus the wait statement in there. I haven't experienced this. Sorry I don't know what's happening.

Maybe it's different when the program crashes with error than when it ends nicely. As you noted there was a missing period at the end. I could see it making sense to say that when there's an error that aborts the program things need to return to manual control right away just in case there's an emergency coming up and the user didn't expect the program to kick out at this point.

Yeah that is definitely a big problem. The craft can only "see" the height where it is at the moment so to get a proper slope would require hovering and "surveying" the terrain in several directions, which gets really messy and a good skycrane shouldn't have that much fuel to be puttering around like that. I tried having it veer a bit left and right and take samples that way to guess whether it can seek better ground to the left or to the right, but that was getting very messy and wasn't working well so I took it back out. I figure a better solution is working on the "land at position lat,long" algorithm and say that the people designing the probe's mission surveyed a good landing spot for the craft ahead of time. I'm going to work out the math for how to do it in polar coordinates because I suspect it will make some of the messy terms go away and also perhaps remove some of the trig until the end when converting back out to XYZ.

Well.. you *did* describe that as being the last segment of your code. Is there anything that comes after it that you were expecting to execute that you didn't show us? Otherwise ending after the last statement seems perfectly normal to me. The program "lets go" of the steering after it ends and you return to interactive mode. This is deliberate so you can have manual control back after the program is done. If the MECO line is the last line and it is ending there, then what happened is that it tried to steer toward prograde for just a moment and then stopped trying when the program ended. Supposedly you can: LOCK STEERING TO NODE. But I haven't tried it to see if it works. And again, if your program ends it will stop trying to control the steering. That's going to require information on the craft to diagnose.

My next project I've set for myself is to make a little library routine to detect the current lat/long where on the surface the trajectory is predicting to hit the ground. It can't be as accurate as the blue line in the game because the blue line is done knowing the terrain of the planet surface, and I don't have that information so I'll just make an approximate guess that the height is probably about half the max height of the planet terrain (from the KSP wiki). But the idea is that this is a requirement if I want to try to make something land near a chosen target. I first have to be able to at least predict where freefall is taking it now It all hinges on pulling out my old rusty math skills and finding the intercept point between an ellipse (your orbit) and a sphere (the planet surface) *, and working out how to get the parameters of those equations given what information is in KOS. The altitude of apoapsis and periapsis plus the planet's diameter give me the length of the major axis of the ellipse, and I know that Kepler's laws of motion say that one of the foci of the ellipse has to be the planet center (the focus closer to the periopsis side will be), which conveniently is the origin in the XYZ grid, and the difference between apiopsis and periopsis should be able to tell me how far apart the foci of the ellipse are, and the current altitude (from core so + body radius) and current Up direction should get me the datapoint that I am currently on in the ellipse, so it seems to me the data to do it should all be there.. I just have to do some scratch-paper work to get it to come out.

It performs the following logic. You can calculate the height above sea level of the terrain directly under the lander (assuming you're close enough to the ground for alt:radar to work right) like so: Terrain height = altitude - alt:radar. If you remember the previous terrain height from the last time through the main loop, and compare it to the current terrain height, you have delta height. If you record the previous timestamp so you also know how long it took between iterations, you can get the horizontal distance traveled between those two samples as deltaTime * surfacespeed. So the slope is deltaHeight / deltaHorizontalDist: Or in other words: cur slope = (current terrain height - prev terrain height) / ( (curTime - prevTime)*surfacespeed ) So as long as abs(cur slope) is too big, I don't entirely allow it to kill horizontal speed. I allow it to continue moving at 10 m/s sideways until it finds terrain with shallower slope and then I begin the last few meters of descent. I intend to post the code for it but not until I work out a few more bugs and land with it a few more times. I'm certain in its current state its still a bit wrong.

I can't find this. After the forum reboot old URLS no longer work, and I did a search for that thread and didn't see it.

There's actually some comments in the networking code inside the linux kernel that mention potential problems with latency times if the kernel was running on Mars. It was probably a bit tongue-in-cheek but.... there have been probes sent to mars with Linux in them so... it could be a concern I guess.

I had three different landing scripts called "lander", "hover", and "skycrane" that I've now merged together into one that just takes a parameter. Now I just call: run descend("skycrane",0.2). For example. Since they all do the same thing up until the last moment. (The 0.2 is a slope parameter. The lander will attempt to wait until it sees that the terrain beneath it has a sope of 0.2 or less before descending all the way to drop the payload. It avoids dropping the payload on a hill slope.) Oh so dashes are allowed now? Good. I've been trying to find a good word-separator in program names. I tried camel-casing it but that seems to cause trouble if I use mixed case in the program names.

Because of the 10k limit, I still run my code through my comment stripper anyway even though there's now support for them. I don't mind the challenge of having to write code that's compact enough to fit in 10k, but I don't think it's a fair challenge to be counting legibility against you in that calculation. In the real space program when they had to deal with very tiny computers with very tiny storage they were sending compiled assembly code or machine code to the craft, not source code. Comments should cost nothing.

In a lot of experimenting I eventually figured out what the underlying "hidden" XYZ system really is based purely on taking lots of velocity and "up" samples at different positions and using them to work out logically what it has to be. Now I've got the transformation I wanted worked out, and it's here: http://kos.wikia.com/wiki/Tutorial_-_KOS_0.65_and_above:_Finding_surface_dynamic_information It occurs to me that now that I have this I could probably also get my position in XYZ terms (another thing the KOS mod doesn't tell you) by using the altitude plus the sea-level radius of the planet to get the radius of the polar-coordinate system, and then convert that to XYZ now that I can work out the angles of the polar coordinate system relative to the "hidden" X and Z axes.

((In the fourm reboot my previous post seems to have been posted twice for some reason. Clobbering the repeat.))

I did this during the days the forum was down (and posted it right before the hack, so it got reverted. Here it is again:) This should be handy to anyone who's been trying to work out various landing autopilots. The vectors for velocity:orbit and velocity:surface are given in terms of the XYZ grid system that KSP uses natively behind the scenes. The problem: But users of KOSscript can't do much with that information other than use it precisely as-is, because we can't "see" that XYZ system. We can't get the positions of things in those coordinates. We don't know where our own ship's position is in that system. If we want to LOCK STEERING TO *exactly* surface prograde or retrograde its fine, but if we want to do something like "LOCK STEERING TO SOMETHING A LITTLE BIT WESTWARD OF RETROGRADE" there isn't a way to do that because we don't actually know which way is east, west, north, or south in the XYZ system. And we can't derive it either (or so I thought) because we can't see our own position. (For example, lets say you know you are going in V(50,0,50). You know that's going at a 45 degree angle from the grid lines, in the positive direction of the X axis and Z axis, but is that toward the planet? Away from it? Tangental to it? Dunno without the position information. If we assume the coordinate grid has an origin at the planet's center (it does but I only know that from asking other modders -KOS doesn't tell you that), then if my position was at X=100000 and Z=100000 then I'd know that a velocity of V(50,0,50) is straight up. But if my position is X= -100000 and Z = 100000 then the same velocity is due west.) The solution But from experimentation I worked out that there is ONE way to figure it out. By reading what the angle of Up:yaw is, you can find out exactly how far around the planetary circle in the XZ plane you are from its zero point (its X axis intercept). Once you've got that you can work out the rest of it. So I made a small program file that if you pass in the XYZ coordinates of a vector, it will calculate for you the same vector in terms of a surface-relative frame of reference grid, using the three axes of East, North, and Up. (negative east is west, negative north is south, and negative up is down, obviously). Beware that this information is only correct at the instant it's derived. The further the craft moves from where it was at the moment you called the program, the more incorrect the data becomes, because East.North,Up is a polar coordinate system but your movement is linear. The page has a lot of explanatory text but you can skip past it and just go to the bottom if you just want to snag the code: The page is here: http://kos.wikia.com/wiki/Tutorial_-_KOS_0.65_and_above:_Finding_surface_dynamic_information This program uses the new parameter passing of 0.65. You will need version 0.65 before it will run.

Please read this thread through to the end: http://forum.kerbalspaceprogram.com/showthread.php/50274-I-can-t-understand-the-coordinate-system-why-am-I-moving-vertically-when-on-ground I had the same problem and read the code on github and saw that all it's doing is exposing us to the native API's concept of velocity, so I figured whatever weridness was going on must be coming from the underlying mod API. So I asked over there if other mod makers could tell me how the native coordinate system is meant to work. I think I can work out from the second number of the "UP" tuple what the REAL longitude is relative to the planetary axis and work it out from there. (Squad chose to make the reported longitude to the user not match the coordinate grid underneath for ... uh... no apparent reason. The real zero point seems to be around about 100 degrees longitude for some reason).

It doesn't offer enough to do this, which is the problem, I think. It presents an "up" Euler rotation set for your current position, and a "north" Euler rotation set for your current position and expects you to use them to steer by, but when it gives you vectors instead of rotation tuples, those vectors are expressed in the native coordinate space, and since Euler rotations, despite the name, don't actually rotate the universe but rather they distort it into a non-orthogonal shape, I can't wrap my head around them. Basically I guess it's a failing of the mod. To do anything useful requires that you know the meaning of the XYZ numbers but there isn't enough information being passed from the native API up to the KOS user to do that. I've been experimentally looking at the XYZ velocity at different points in orbit trying to find the longitude where the X and Z axes is on the planet (when the X or Z part of the velocity turns to zero when in a perfectly circular orbit, I reckon I'm on an axis). Z seems to be near 100 degrees, but not exactly there, and at any rate this isn't a general solution for all planets just to learn where it is on Kerbin.