[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Feldhaus]

Hey, I'm new to this, is there a way to directly get the Fuel consumption rate that you can find in brackets in you resource overview?

Currently I'm doing it like this:

set Y1 to ship:liquidfuel.
wait 10.
set Y2 to ship:liquidfuel.
set cps to ((y1-y2)/10).
print cps.

The Liquidfuel is measured every 10 sec and the consumption rate is the difference divided by 10.

The Problem is, ship:liquidfuel always gives a whole number so if your fuel consumption rate is e.g. 0.04, the displayed amount of liquid fuel doesn't change within 10 sec. Of course I could do even larger intervals between the measurements but I don't really want to do that.

Is there a way to get the fuel consumption rate directly? I couldn't find anything in the documentation..

Thanks!

[Dr_Goddard]

Programmed a gyro stabilizer in kOS.

Thanks to infernal robotics.

[Dunbaratu]

Programmed a gyro stabilizer in kOS.

Thanks to infernal robotics.

I like it. So the purpose is to keep the central part level?

[IronGremlin]

@Steve Madding:

Your tutorial is awesome! I love it, and it's wonderful, and I learned some things that I didn't know even though I've been writing functional scripts for a while now.

I would request just one tiny addition: Find some excuse to go over a more complicated data structure, like body, vessel, or engine... Just something to give the reader a handle on how to access sub properties of an object - I know the code in the tutorial shows this already, but it might not click with some readers without being super blatant.

Thanks for the great work!

[Dunbaratu]

can anyone please tell me how I can get the fuel amount of a single tank? for staging purposes.

You can get the resources of a whole vessel or a stage, but not for a single part (I don't think). I wonder if that would be a good feature to add to the Part structure.

[Dr_Goddard]

I like it. So the purpose is to keep the central part level?

Correct. The idea came from a comment about a self levelling lander... this is going to happen soon.

Landing on uneven surfaces shouldn't mean a tip-over any more.

I think this is going to be the core for a few new ideas.

[Laie]

@Steve Madding:

Your tutorial is awesome! I love it, and it's wonderful, and I learned some things that I didn't know even though I've been writing functional scripts for a while now.

I would request just one tiny addition: Find some excuse to go over a more complicated data structure, like body, vessel, or engine... Just something to give the reader a handle on how to access sub properties of an object - I know the code in the tutorial shows this already, but it might not click with some readers without being super blatant.

+1 to both points: that tutorial is great, and it stops too early.

I can list engines and their stats, but I can't do anything useful with it. Like, pick a particular value.

I can not figure out where my vessel is pointing. I'm just giving it directions and assume that it does as it's told. That approach goes a long way, but sometimes I'd like to do better than that.

I think I understand how to set up a manuever node (toss in figures, check X:OBT:APOAPSIS until I like the result), but I have no idea how to execute one.

[Dunbaratu]

+1 to both points: that tutorial is great, and it stops too early.

I can list engines and their stats, but I can't do anything useful with it. Like, pick a particular value.

I can not figure out where my vessel is pointing. I'm just giving it directions and assume that it does as it's told. That approach goes a long way, but sometimes I'd like to do better than that.

I think I understand how to set up a manuever node (toss in figures, check X:OBT:APOAPSIS until I like the result), but I have no idea how to execute one.

Hmm. We were talking about this topic before - the basic conflicting goals are:

* kOS should not be Mechjeb. It should not just *give* you completed code that does everything for you.

* To show how to use kOS you need real world examples that solve realistic use-case scenarios.

So... how do I make an ascent script example that covers all the basic topics without being so complete that you never need to write your own ascent script and you can instead just copy the example?

That's the basic dilemma I'm trying to deal with.

To answer your specific issues:

1. The LIST command has an analogous LIST IN command that looks like this:

LIST thingy IN myOwnVariableName.

After that, myOwnVariableName will be a variable of type LIST, that you can iterate over as described here:

http://ksp-kos.github.io/KOS_DOC/structure/list/index.html

Thus you can LIST ENGINES IN MYLIST, and then MYLIST[0] is the first engine, MYLIST[1] is the next engine, and so on.

here's an example:

SET numOut TO 0.
LIST ENGINES IN EngList.
FOR eng in EngList {
  IF eng:FLAMEOUT {
    numOut to numOut + 1.
  }.
}.
PRINT "There are " + EngList:LENGTH + " engines on the ship, of which " + numOut + " are flamed out.".

2. Which way the vessel is pointing: SHIP:FACING.

SET wantDir to HEADING(0,50).
LOCK STEERING TO wantDir.
LOCK curDir to SHIP:FACING.
// Now the difference between wantDir and curDir is how far off the ship is from its desired pointing.

The ugly thing with Directions like facing is that there are literally an infinite number of possible rotation tuple combinations ( R(a,b,c) ) that result in the exact same thing: For example, imagine starting from a ship facing due east, with its' roof facing the sky, and then applying a pitch of 180 degrees and a roll of 180 degrees, versus just yawing 180 degrees. They're the same thing. You end up facing west, and with the same side 'on top'. There's any number of other similar combinations that are identical in their result. So it's hard to tell if two rotations are "close" to each other or not. The way I'd do it is to convert the rotations to vectors first and then work out how close the angle betwen the vectors is. This will become easier in the next release, as all Directions will now have a working :VECTOR suffix that returns a unit vector pointing the same as the rotation does.

3. To execute a maneuver node, use its DELTAV suffix. That's not just a scalar number. It's a vector, which means it can be used to steer by, like so:

SET nodeVector to myNode:DELTAV.
LOCK STEERING TO nodeVector.

Then you can check the node's time into the future with the ETA suffix. myNode:ETA would be the time until the burn. Node that a proper burn means starting the burn *prior* to the ETA so the burn time straddles the ETA time, and that's your task to work out how to do that.

To know if you've burned long enough, just remember what your velocity was at the start of your burn and compare that the the current velocity. When the difference is equal in magnitude to your node's deltaV, then you've burned long enough.

Edited July 1, 2014 by Steven Mading
mismatched [ code ] tags in the BBcode.

[armeg]

My EDIT command seems to not do anything. I can't seem to get the file editor to pop-up no matter what I do. I'm definitely typing it correctly since it doesn't complain about any syntax errors.

[Dunbaratu]

My EDIT command seems to not do anything. I can't seem to get the file editor to pop-up no matter what I do. I'm definitely typing it correctly since it doesn't complain about any syntax errors.

The editor is only in the pre-release. If you're using the full-release it's not there yet. You can get the pre-release from the github site.

[IronGremlin]

@Steve Madding:

Just write irrelevant code for your tutorial. Something that prints ETA to app in an unending loop, etc. It doesn't have to do something useful to teach useful concepts.

[Dunbaratu]

@Steve Madding:

Just write irrelevant code for your tutorial. Something that prints ETA to app in an unending loop, etc. It doesn't have to do something useful to teach useful concepts.

The problem is that to do that for *every* possible thing kOS supports means making literally hundreds of examples for all the possible terms on every possible structure. How can I know that people have more of a problem with understanding NODE:ETA than, say, understanding SHIP:ORBIT:APOAPSIS, or MUN:POSITION?

That's the difficulty I face. It's not practical to write out an example of literally every single suffix on every single object type. So I have to figure out which ones are giving the biggest problems and stick to them.

Things I figure do need examples are:

* Something with one example of a LIST traversal through a loop doing something practical, since people don't seem to understand it even though there's an example of it right on the LIST page. It seems that it has to be an example of doing something real with it for it to 'gel' when reading the docs. I already do have examples that take the 'do something useless' approach of saying 'okay so you've got some list "foo" that has the values ["hello","bonjour",and "aloha"], here's how you can print them out...' and that just doesn't seem to cut it.

* Something practical that uses one of the many ETA's - since it doesn't seem to gel to just describe it as the amount of time until a thing.

* There are places where the types of things are not mentioned - that *is* a flaw in the documentation. I'm a bit reluctant to spend too much time on it though, as there's talk behind the scenes of some possible better automation of suffix term handling that could include automatic type documentation.

* Something using argument passing into subprograms. There's no concrete example for that yet.

Edited July 1, 2014 by Steven Mading

[IronGremlin]

The problem is that to do that for *every* possible thing kOS supports means making literally hundreds of examples for all the possible terms on every possible structure. How can I know that people have more of a problem with understanding NODE:ETA than, say, understanding SHIP:ORBIT:APOAPSIS, or MUN:POSITION?

That's the difficulty I face. It's not practical to write out an example of literally every single suffix on every single object type. So I have to figure out which ones are giving the biggest problems and stick to them.

Things I figure do need examples are:

* Something with one example of a LIST traversal through a loop doing something practical, since people don't seem to understand it even though there's an example of it right on the LIST page. It seems that it has to be an example of doing something real with it for it to 'gel' when reading the docs. I already do have examples that take the 'do something useless' approach of saying 'okay so you've got some list "foo" that has the values ["hello","bonjour",and "aloha"], here's how you can print them out...' and that just doesn't seem to cut it.

* Something practical that uses one of the many ETA's - since it doesn't seem to gel to just describe it as the amount of time until a thing.

* There are places where the types of things are not mentioned - that *is* a flaw in the documentation. I'm a bit reluctant to spend too much time on it though, as there's talk behind the scenes of some possible better automation of suffix term handling that could include automatic type documentation.

* Something using argument passing into subprograms. There's no concrete example for that yet.

I'm sorry, we seem to be suffering from a rather profound miscommunication.

I don't think it's really necessary to pick sticky case examples - As you made mention of earlier, those are bound to change soon as kOs grows - I mean literally, there are people who don't know what a data object IS. The idea that you could do something like KERBIN:POSITION at all is foreign to people who are new to this stuff. They don't understand what the colons are representing there, conceptually, or that it's the same basic idea as ETA:NODE. I don't mean tutorials on all data objects, I mean A tutorial on the concept of objects that have sub-properties. Let people refer to documentation to work out sticky particulars.

[Dunbaratu]

there are people who don't know what a data object IS. The idea that you could do something like KERBIN:POSITION at all is foreign to people who are new to this stuff.

Then what you're asking for is too gargantuan a task. It's a textbook not a tutorial. Once I start assuming that a few examples plus the explicit information in the reference docs aren't good enough to get people the idea of how the language works, then I'm talking about actually explaining basic programming concepts in details as if it was a college course. Explaining that is just too much work.

Edited July 2, 2014 by Steven Mading

[Matrix Aran]

Then what you're asking for is too gargantuan a task. It's a textbook not a tutorial. Once I start assuming that a few examples plus the explicit information in the reference docs aren't good enough to get people the idea of how the language works, then I'm talking about actually explaining basic programming concepts in details as if it was a college course. Explaining that is just too much work.

Ultimately learning to use kOS is going to have to be a bit like learning Kerbal Space Program. Much like having to learn some basic orbital mechanics to get to the Mun or Duna, the user is going to have to accept that they're going to have to do some homework about programming before they'll be able to get kOS to do what they want.

I think perhaps the best approach is to make tutorials in the same way as one would make a tutorial for KSP. Show how to do something simple, use that to illustrate *some* of the basic concepts they might not be familiar with, and then leave the rest as one big sandboxy playground that they can dive into at their leisure if they enjoyed their experience with the tutorial.

If folks aren't satisfied with this, then they're free to make their own tutorials to fill whatever they find missing. Its not up to one person to teach everything.

Edited July 2, 2014 by Matrix Aran

[luckielordie]

Can kOS work with Mechjeb? Like send off a command to tell mechjeb to pull of a circularise manoeuvre with the parameters available in mechjeb?

[Crown]

I have a quite simple question but the reference didn't help me:

How do I read out the current throttle and the current thrust of a ship I control?

When I try to use "PRINT engine:thrust." in a terminal window it gives me an error but as far as I understand the section Structure Reference that's how it's done.

What do I wrong?

[Dunbaratu]

I have a quite simple question but the reference didn't help me:

How do I read out the current throttle and the current thrust of a ship I control?

When I try to use "PRINT engine:thrust." in a terminal window it gives me an error but as far as I understand the section Structure Reference that's how it's done.

What do I wrong?

engine is a type of variable, not the name of a variable. You get a list of them with LIST ENGINES IN MYVAR.

For what you want, try this:

lock throttle to myvalue. // pick a myvalue in the range 0.0 .. 1.0
print "cur thrust is " + ship:maxthrust * myvalue.

works if all engines are liquid fuel. solid fuels are maxthrust regardless of throttle so that doesn't quite work if you have any of them.

[Camacha]

Can kOS work with Mechjeb? Like send off a command to tell mechjeb to pull of a circularise manoeuvre with the parameters available in mechjeb?

You can do that within kOS, so I do not really see the use of that.

[curiousepic]

Is it possible for a non-focused vessel to be running a KOS program?

Has anyone done this in order to create "AI" opponents for combat?

[Camacha]

Is it possible for a non-focused vessel to be running a KOS program?

I am quite sure you can at least control certain aspects of other craft via a kOS unit on your own craft, so creating opponents should be possible. Running on a non-focussed craft is also possible, as I have used that for air-to-air docking. It can be quite quirky though.

I have not seen anyone creating enemies through kOS, so it looks like you have a job to do

[Dunbaratu]

Is it possible for a non-focused vessel to be running a KOS program?

Has anyone done this in order to create "AI" opponents for combat?

I haven't done it for that purpose, but I did make a simple docking script and then test that it functioned while I was focussed on the target vessel receiving the dock rather than the vessel running the docking program.

It should work, but the vessel running the code does have to be fully loaded into the physics engine or the kOS computer won't be given any update notices by KSP, and it will freeze execution.

(In other works, the kOS CPU has a clock speed of zero while the vessel is on rails, so it's not particularly useful unless the other vessel is near enough to stay fully loaded.)

We went through and tried to diligently find all the areas where the old Kevin Laity code wasn't making the proper distinction between the CPU's vessel and KSP's current active vessel, and tried to fix all of them. I hope there aren't any we missed.

[Camacha]

We went through and tried to diligently find all the areas where the old Kevin Laity code wasn't making the proper distinction between the CPU's vessel and KSP's current active vessel, and tried to fix all of them. I hope there aren't any we missed.

Ah, that should have fixed most of the odd things I have seen going on. I must admit it has been a while since I tried.

[Dunbaratu]

I just finished a major walk through the documentation adding a lot of missing stuff and making sure all the suffix fields are in the same format, with the same information about them.

Documentation link:

Important updates in that documentation:

* All suffix terms explicitly mentioned, after a long walk through the code.

* I had a page for the LIST BLAG IN FOO command and had never realized that it had never been linked to from anywhere and was never included in any of the git commits so it was missing from the public site. No wonder there were so many questions about how you get to the Engines and so on.

* Better organization of the inherited things like Orbitable->vessel and body, and Part->Engine and DockingPort

* List of bound variable names and what they do. Important since so many of the things you do in kOS are done through these variables.

* More structure pages have examples, and all of them mention how you go about getting an instance of the type in question. I didn't like doing this but there weren't good places to put that information some of the time.

* Removed very misleading sentence from the front page that obfuscated the difference between instances of structures (i.e. SHIP, TARGET) versus the structure itself (i.e. VESSEL). Once upon a time the structures list was a mishmash of SOME things being something there can be multiple instances of and SOME things being hardcoded structures there was only ever one instance of. That sentence was causing undue confusion, I think, and must have been leftover from a much older version of kOS and never removed.

Edited July 4, 2014 by Steven Mading
first URL link had no text in the body of the link to click on

[Dunbaratu]

Ah, that should have fixed most of the odd things I have seen going on. I must admit it has been a while since I tried.

Sadly I just discovered as part of the documentation update when I walked through all the structure's Csharp code by eyeball, that it looks like SHIP:SENSORS is violating this rule. It checks whether or not the current CPU Vessel has the right sensor, but then if it does it pulls the data from the flight globals for "current state", which of course KSP thinks of as the where the "current vessel" is, not the CPU vessel.

That was the only such place I found, though.