[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Dunbaratu]

Yeah there is definitely a problem here.

take a look at this:

http://cloud-4.steampowered.com/ugc/53243610307866655/3A13CFB12778276D3DA2E6BA7CAEAB881E1EBA07/

In this picture I have 3 rovers pointing to the exact position where KOS thinks all objects in the world are.

As you can see all 3 rovers thinks Enmy Kerman is in a different position. These positions seem to change depending on the rovers orientation in the world.

Here is the code each rover is running: (note only the color was changed for each rover.)

clearscreen.
list targets.
list targets in tar.
set arrows to list().
set x to 0.
for t in tar
{
    SET arrows:add TO VECDRAWARGS(v(0,0,0), t:position-ship:position, rgb(1,0,0), t:name, 1.0, true).
}
until abort
{
    for t in tar
    {
        set arrows[x]:vector to t:position-ship:position.
        set x to x + 1.
    }.
    set x to 0.
}.
for arrow in arrows
{
    set arrow to "".
}.
set arrow to arrows:clear.

I know you said you guys are working on new stuff right now but, won't this throw off orbital projections and well... Just about everything else? Knowing where stuff is, is pretty important...

Do you guys an updated version of KOS that I can test out for you?

You'd probably need a full compile suite to take the source code and make it into a DLL. I could compile a DLL and try to give it to you but it's literally changing about 10 times per night as we fiddle with the final debug tests.

When this problem appeared before it was always only off by a few meters, in a way that *didn't* scale with magnitide. It was always only a few meters even when talking about distances to the moon, which is why it's not detectable when doing orbital calculations. The problem (in the past which I thought was fixed, darn it), really only was noticed over very short distances because that's where being a few meters off is relevant.

[Trewor007]

there is one thing that's buging me about this bug. all the drawn vectors are pointing in a good directions, and they are precise on target. So that means they "know" where Enmy Kerman is, also they know where ate the other rovers. So i suspect the problem is somewhere else. Maybe the controlled rover has a unnecessary "round()" somewhere in its positioning code. But that's just a theory.

[Dunbaratu]

Let me give a few details about past problems the vecdraw had with this, to give a hint as to why I am suspecting this is an old bug resurfacing due to some code being lost along the way and not being merged in, rather than a new one.

Problem 1: People routinely claim when talking about the space kraken problem that what SQUAD has done is to place the origin of the coordinate system on the current vessel. This is false. What they actually did is to put the origin NEAR the current vessel, but allowed it to drift away. I don't fully understand the reason for it, but early experiments showed that the position of the ship is never exactly 0,0,0, and that over time the active vessel drifts farther and farther away from the worldspace origin point the longer you stay in flight view at 1x speed. Going to time warp speed seems to cause the origin to reset when you come out of it, so the ships is once again back at the origin exactly, but then immediately starts drifting away from it.

Therefore I made the decision that in order for the positions and vectors of kOS to be usable at all, they must shift the origin point to something you can see and relate to in-game. The actual origin is a magic invisible point you have no idea where it is. Therefore every single position kOS returns is in a coordinate system centered on whatever vessel is the one running the computer on which your script is executing. It's just a matter of subtracting the ship's position from the coordinates that KSP gives us under the hood.

That solved some of the problems.

Problem 2: Under the hood, there are two methods to get the position of a vessel, and it was unclear what the difference between them is because the API is undocumented. (all the documentation comes from the user mod community). One is clearly named findWorldCenterOfMass, which is clear what that means, but the other is just the actual position of the ship.. well. the position of what part of the ship? (It turns out it's the position of the root part of the ship - the command core you used to start building it from, which might be quite far from the center of mass, but this wasn't mentioned and took trial and error to figure out.) The problem was that different parts of the code, written at different times, by different people, used a mix of both types, leading to inconsistencies that you'll only notice when in a context where the few meters of difference between rootpart and center of mass matter. I ran through and changed every one of them to a standard of using center of mass everywhere, and that got rid of the weird vector offsets.

At least it got rid of them... until NOW. Which is why I'm baffled that this has come back again. It looks *exactly* the same as a problem I already fixed, which is why I started asking questions about which version number this was.

I promise that as soon as 0.15 is out that this will be the next thing I look at for 0.15.1. I fully expect that once 0.15 hits the public, people will find stuff wrong with it that we haven't foreseen, that require a patch, just because it's impossible for two people to fully test every usage case. It's my goal to make the fix of this part of the first patch after 0.15.

[ouch]

That makes sense as it seemed like the more the craft moved and rotated the farther off it got, almost like rounding errors were accumulating or something. But has anyone else confirmed? I have quite a few mods installed. one could be affecting it.

Oh, and I don't mean to add to your stress, I do realize your just doing this for free... So fix it if you want to fix it and when you want to fix it. I still need to develop a better target seeking pathing for the drone anyway.

[Amloris]

Greetings! I have picked up coding with KOS once again. I had stopped using it about a year ago to wait for further development as I felt that some essential features were lacking. Now that lists are available and the coding documentation has been updated it has unlocked many possibilities that were previously impossible. Furthermore, I'm glad to see this mod has continued and that the developers are active on the forums.

However, I have some questions that need to be answered and some suggestions that I would like to make. Most of my coding experience comes from using C++ for engineering iterative methods, or VBA and MatLab for control system analysis, so I may use inconsistent code oriented language as I talk about examples.

Question #1

Is there a way to retrieve/store data from lists other than using FOR loops?

In most coding languages, lists come in the form of matrices that are used to store data in various forms. Users generally must define an array size (unless the are using scale-able vector arrays). To store and retrieve data, the program uses row and column integers to interact with the data matrix (if it is a 2-D array). Does KOS have any of this functionality? I know lists exist and can be stepped through with the use of FOR loops, but is there a more straightforward way to pull a specific point of data from matrix through the use of requesting rows and columns? Below is an example of some of my C++ code that performs RREF calculations on a data matrix and accurately portrays the functionality that I am talking about.

double normalization(double A[NROW][NCOL], int mark)
{
	int col;
	double temp;

	temp=A[mark][mark];

	for (col=mark; col<NCOL; col++)
	{
		A[mark][col]=((A[mark][col])/temp);
	}
	return (0);
}

In this situation, A is a 2 dimensional array with "m" rows and "n" columns. So if I say X=A[row][column] where "row" and "column" are represented by integers, then X will equal the value pulled from the matrix at that point.

Using lists and matrices in this way is very intuitive and straight forward. FOR loops can still be used to store and retrieve data, but this structure also allows users to request a singular data point easily without FOR loops. The reason why I am asking about this feature is because I am attempting to program an inertial guidance system in C++ that will take the initial conditions of the craft and information about the type of orbit you would like to achieve with said craft. This program will then use an iterative Runge-Kutta procedure, coupled with a Monte-Carlo method to find an optimal ascent profile and store the final trajectory data in the form of a txt file that can be read by KOS. At the end of the day, I want to be able to say "At mission time 53, look at matrix row 53 and pull pitch, yaw, and throttle info from the matrix and implement it with the rocket". Is this currently possible with KOS, or is it a potential feature in the future?

Due to the long-winded nature of my first question I will abstain from asking the rest of my questions in this post to prevent information overload. Thanks in advance for any information that anyone can provide!

Regards,

Amloris

[ouch]

Sounds like you might not have seen the new, updated wiki. Check it out here: http://ksp-kos.github.io/KOS_DOC/

But yes you can actually create multi-dimensional arrays and step through them just like c++.

So:

Set mything to stuff[2][5].

Is valid kos code.

[Dunbaratu]

@Almoris, What @ouch said.

What do all of you, the users of kOS, think of the possibility of implementing implicitly expanded lists based on usage? In a lot of languages designed for quick and easy prototyping, they have this rule:

* If the program attempts to assign a value into array[idx], where idx is larger than the array's current size, then instead of bombing out, take this as an implicit desire by the programmer to want to grow the array to become big enough to have an index of idx.

So, for example, if you did this:

set mylist to list().
set mylist[2][3] to "hello".

Then you'd now have a list that looks like this:

mylist[0] = list of size zero.

mylist[1] = list of size zero.

mylist[2] = list containing: list [0] = null, list [1] = null, list [2] = null, list [3] = "hello".

It grows the list at the minimum necessary to hold the index given.

There are some languages, like Perl, that operate this way. It's an idea I had rattling in my head a while. It makes for very easy to read code when you are trying to populate a matrix of data, but it does have the following pitfall: If you try to do mylist[x], where by accident you had an enormous x, like 9999999, you end up carving out a gigantic chunk of memory and perhaps crashing because there's not enough. I consider that an acceptable programmer error the language shouldn't try to prevent, akin to getting stuck in an infinite loop, but not everyone agrees.

Also, that would require that we have the ability to handle user variables that contain NULL, which up till now has been avoided, in order to let people deal with an array which contains nulls for some of its values.

[ouch]

Well in my experience the word "NULL" tends to scare away non-programmers. They seem to have a hard time figuring out that NULL and a 0 length string or "" are two separate values. And while I definitely think being able to resize lists like that would make lists easier to use for both non-programmers and programmers, it also comes at a risk of alienating the non-programmers. To solve this I think you could get away with making null and "" mean the same thing according to KOS.

[Dunbaratu]

Just a general warning about some breaking changes upcoming in v0.15:

One of the reasons for the delay of releasing v0.15 has been the fact that we've been stretching the language past some limitations of its original design, and hitting a wall caused by our desire not to break old scripts you've all written. There are a few cases where the original language spec is quite limiting and trying to make old code work without any edits despite adding new functionality was forcing us to implement the new features in rather convoluted and bug-prone ways just to shoehorn them into the old syntax of things. It hit the point where we just decided that what we were trying to do would probably cause *more* user headaches than just telling people to make some edits to their scripts in small places here and there. By breaking with tradition in a few places we gain the ability to actually implement things the right way. And it's actually a lot easier than the messy hacks we were in the middle of trying to make.

So when the release announcement is eventually made (RSN?), please pay special attention to the section of the release notes that tells you what the breaking features are. It's going to be important in this particular release. But when you all see it I think (hope?) you'll agree that the breaking changes were worth it to allow the new features.

(I'm just trying to manage expectations here.)

[Drew Kerman]

I personally don't mind recoding anything for the sake of progress! As considerate as it is to keep old code functional, at some point yea you're just going to be hamstringing the whole project. So thanks for the heads up but IMO keep breaking what you need to moving forward...

[steddyj]

After watching kOS for a while now I've finally decided to take the plunge, in part because I've been very impressed by the recent progress of the mod. While the documentation is leaps and bounds from what it was the last time I thought about adding kOS to my modlist, I'm still getting a bit stuck on a few things.

For my first useful script I wanted to have something that will deploy a satellite for me after the lifter has coasted out of atmo. I'm using RT, and the antenna on the satellite would face into the lifter if deployed before the payload is decoupled. Functionally this would work fine, but it was a good excuse to give kOS a try.

So I have my basic script working fine, it decouples the satellite, fires RCS forward a few bursts, waits a few seconds, then hits an AG deploying comms and solar panels. Now I'm trying to refine it a bit, I'd like it to make sure it gets at least 10m or so from the lifter before deploying. Logically I have this all worked out - target the lifter, get the distance, is it far enough? ok deploy. The issue I'm running into is how to set the target specifically to the lifter, since it's named "Vessel Debris" along with the fairings I just jettisoned and the launch clamps back at the KSC, which is what I end up with if I try to target it by name. I tried the following script:

list targets in targs.
for this in targs {
	if this:distance < 100 {
		set target to this.
	}
}

and I get "Vessel 'SHIP("Vessel Debris")' not found"

I figured maybe I need to set target to this:vesselname and that just gets me back to a docking clamp.

What am I missing here? Is there a unique identifier that can be queried in the orbital structure that will help me make sure I'm setting the right target?

Thanks for the help, and sorry for the wall of text.

[Trewor007]

Hi is there, a way to check in KOS, the rotation of my rover around, a axis made of a vector?

[ouch]

steddyj: you want to use just :name for targeting, not :vesselname But to save you time I wouldn't bother targeting the ship. There can only be one target regardless of what ship your in. So if you want to say run the script on one ship and dock with another you can't change your target because it will break your kos script. Not targeting something first will likely save you time down the road. Secondly to pick a specific object out of a bunch of the same name then, it's best to use list to look through all the objects parts till you find an object that has the parts your interested in. you can look here for more info on how to do that: http://ksp-kos.github.io/KOS_DOC/command/list/index.html (specifically #4)

Trewor007: what do you mean exactly? if you have a vector and want to look at a specific axis than you can just specify that axis like so:

print "myvector x axis: " + myvector:x.

print "myvector y axis: " + myvector:y.

print "myvector z axis: " + myvector:z.

A direction has it's own suffixes:

print "mydirection pitch axis: " + mydirection:pitch.

print "mydirection yaw axis: " + mydirection:yaw.

print "mydirection roll axis: " + mydirection:roll.

[Trewor007]

ouch

I'm trying to write a code that will check the slope angle of the current rover position. I've managed to make an accurate measurement witch the code below . But it works only if the slope is right in front (or back) of the rover, when the slope is on the side (left wheels higher/lover than the right ones) the program does not "see" the slope because of how ship:facing:vector works.

set line0 to ship:body:position:vec:normalized.
set line1 to ship:facing:vector:normalized.
set katprzod to 90-vang(line0,line1). 
print katprzod at(0,24).

that why Im interested in measuring rotation around a vector. I thing that can help me check the side slope angle

Edited November 15, 2014 by Trewor007

[steddyj]

Ouch:

I appreciate the help. I'm not sure what gave you the impression that I'm trying to set multiple targets, perhaps because I don't have a break in the target code I posted. It's not very elegant (yet, its a POC script) but the IF statement will only be true to the lifter debris, and I've debugged it to confirm that it is indeed trying to target the correct object.

Using this:name instead of this:vesselname did correct the error that I was experiencing when trying to set the target, however the result is still the same. I end up targeting the first object of the name that appears in LIST TARGETS even though my target code is executing against the correct instance since ORBITAL:NAME is not required to be unique. Is there a value in the structure which is used to uniquely identifying an orbital which can be used to set the target?

Alternatively, were you suggesting I target a specific part on the lifter?

[Dunbaratu]

I'm trying to write a code that will check the slope angle of the current rover position. I've managed to make an accurate measurement witch the code below . But it works only if the slope is right in front (or back) of the rover, when the slope is on the side (left wheels higher/lover than the right ones) the program does not "see" the slope because of how ship:facing:vector works.

SHIP:FACING is in fact just a "rotation" operator, and SHIP:FACING:VECTOR is really just giving you the result of rotating the Z-axis by SHIP:FACING.

So these three:

```

set shipXvec to ship:facing * V(1,0,0).

set shipYVec to ship:facing * V(0,1,0).

set shipZVec to ship:facing * V(0,0,1).

```

Will give you 3 basis vectors aligned with the ship's starboard direction, roof direction, and nose direction, respectively.

In fact one of those three (I believe it's shipZVec but I'm saying this from memory so I may be wrong) will be identical to saying ship:facing:vector.

So you can use VANG, VDOT, and VCRS to get your rotated angles around various different things.

It sounds like what you want is the VANG between ship:body:position and the shipYVec I described above. If 180, you are pointed up directly away from gravity.

(hint. SHIP:UP is a unit vector always pointing away from that ship's body's position, right at the center of the blue half of the navball. This may be easier for you to work with than ship:body:position:vec:normalized).

[Drew Kerman]

ouch

I'm trying to write a code that will check the slope angle of the current rover position.

Here is the code Steven wrote up for me a few months ago:

set upvec to up:vector.
set velvec to ship:velocity:surface:normalized.
set dp to vdot(velvec,upvec).
set currentSlopeAngle to 90 - arccos(dp).

Note that this is done with the RoverBrain part from RoverScience mod to give the rover a proper horizontal attitude when moving. You can find out more by checking our my rover driver script (see sig)

[Trewor007]

Steven Mading

Thanks Man as always You are saving my day. The "ship:body:position:vec:normalized" is a relict copied from my old code I've never bothered to change that.

Gaiiden

I've seen Your code this morning, and I was very impress by it, but when i tried that code it wasn't working properly probably due the orientation of the control part.

[Drew Kerman]

... probably due the orientation of the control part.

Yup if the navball isn't showing a horizon to show that the rover control is oriented horizontally you're gunna get some weird results.

[Dunbaratu]

You could probably now replace the two steps:

set dp to vdot(velvec,upvec).
set currentSlopeAngle to 90 - arccos(dp).

with just this step now that the language has the VANG operator:

set currentSlopeAngle to 90 - vang(velvec,upvec).

Taking the dot product and then taking its arc cosine, under the assumption that the two vectors it was made of were both unit vectors, was a sort of hack to get around the lack of a VANG operator.

[ouch]

steddyj, I was just trying to point out that setting a target and basing your code off doing things to said target can cause quite a few issues and should be avoided. For instance, if you have a craft that deploys a probe with kos on it. If your still in control of the main vessel and the probe tries to target the main vessel it can't because you can't target yourself. So it's best to store the object from the list command as a variable and work with it that way.

For the other thing, since each object your targeting is not going to be an exact copy of an another object then you can compare parts between the two so that you can select the one your looking for. Using the parts list is kinda like a unique finger print. So for instance if you have a main vessel and a probe then you can look for a part one has that the other does not. It might be enough to just look at how many parts are on each object a well.

[Veelay]

I've been having a bit of an issue. When I use the script editor, commands still get through to my ship, making it near impossible to use. Does anyone know the cause of this?

EDIT: Nevermind, it was deselecting the main KOS window when I brought it up. But I'm having another issue where there is only one line in the editor, and the enter button does not add a new line.

Edited November 15, 2014 by Veelay

[steddyj]

steddyj, I was just trying to point out that setting a target and basing your code off doing things to said target can cause quite a few issues and should be avoided. For instance, if you have a craft that deploys a probe with kos on it. If your still in control of the main vessel and the probe tries to target the main vessel it can't because you can't target yourself. So it's best to store the object from the list command as a variable and work with it that way.

For the other thing, since each object your targeting is not going to be an exact copy of an another object then you can compare parts between the two so that you can select the one your looking for. Using the parts list is kinda like a unique finger print. So for instance if you have a main vessel and a probe then you can look for a part one has that the other does not. It might be enough to just look at how many parts are on each object a well.

Regarding targeting - got it, I'll keep that in mind if I'm scripting to deploy from the live craft. In this case, the lifter is dumb, deployment occurs on a suborbital trajectory and the lifter will return to key in ballistically. All control is on the satellite, so that should not be an issue here.

Regarding selecting the correct object. I get what you're saying, but I already have the right object in my variable when I try to set it to the target. Using a parts list instead of target lists may make the script more elegant, and honestly I'll probably recode that way for future use. It still won't solve my issue, however, because I would still be identifying the object, trying to set the target to its name, and failing because there are multiple objects of the same name.

However, I think see the solution that you're trying to present. Don't target, once I have it identified I can use this:distance rather than trying to target, which will actually work better in this case.

Now my question is more academic, though. I'd still like to know how you can set a target when presenting multiple objects of the same name? Is there currently a way, or do you need to make sure that you never forget to rename your comm satellites?

[Dunbaratu]

EDIT: Nevermind, it was deselecting the main KOS window when I brought it up. But I'm having another issue where there is only one line in the editor, and the enter button does not add a new line.

That's truly weird because the internals of that text editing widget are mostly just up to Unity itself. We're just calling out to a stock Unity widget tool. If it doesn't respond right to the return key, then I don't know what to do. What particular OS platform (including bitness) are you on?

[Dunbaratu]

Now my question is more academic, though. I'd still like to know how you can set a target when presenting multiple objects of the same name? Is there currently a way, or do you need to make sure that you never forget to rename your comm satellites?

Not currently, but in 0.15 we have a new "nametag" feature where you can manually assign whatever names you feel like to any part of the ship, and then in the code use those names as your means of selecting parts. you can then just name the root parts (the command cores) of your vessels whatever you like with the rightclick menu. The part will not require power to do so.

(I always thought it was utterly ridiculous that stock KSP requires you to have the craft powered up to change its name. Did the moons choose their own names? Did the asteroids choose their own designations? No, the names are decided by ground control, so even a dead ship that's not responding should still be rename-able.)

I have to ask why you can't rename the ship in flight. Is it out of power?

As to the problem of only having one global ship at a time called "Target", that's a problem inherited from KSP itself. KSP was written to assume it's not possible to control more than one ship at a time, so it was good enough to just have one global target at a time, and then switch what it is as you swap which vessel you're controlling. (each vessel does *REMEMBER* what ship it was targetting, so when you switch to it it will reset the global target to what it remembered, but the rest of the high level logic that goes with having a currently targeted ship doesn't work except on the current active vessel.)

Edited November 16, 2014 by Steven Mading