[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Vegemeister]

anyways there is one more problem...when I type LOCK STEERING TO Up. , it just tips over and heads right into the ground. Same happens with North + R(90, 0, 0).

I had a similar issue that was fixed by using "lock steering to lookdirup(up:vector, facing:topvector)." That keeps it from trying to change the roll.

[Dunbaratu]

my code looks like this:

print "Initiating ascent sequence in 5.".
LOCK THROTTLE TO 0.
SET now to time:seconds.
WAIT UNTIL time:seconds > now + 5.
print "Now.".
STAGE.
LOCK THROTTLE TO 1.
LOCK STEERING TO Up.
WAIT UNTIL SHIP:ALTITUDE > 500.
// more code here

This may be an obvious question but I'll ask it anyway just to be sure: Is your command core mounted upside down? The steering may literally think up is down when you do that. To test this case, have a careful look at the navball when you are on the launchpad. It should be showing the prograde marker in the center of the blue sky, rather than the retrograde X marker in the center of the blue sky.

- - - Updated - - -

IIRC, the terminal is supposed to grey out when the editor is open, as the focus is now on the editor.

Correct.

If it didn't then the game wouldn't know when you press "A" whether that goes to the command line in the terminal or to the text file in the editor.

- - - Updated - - -

my code looks like this:

print "Initiating ascent sequence in 5.".
LOCK THROTTLE TO 0.
SET now to time:seconds.
WAIT UNTIL time:seconds > now + 5.
print "Now.".
STAGE.
LOCK THROTTLE TO 1.
LOCK STEERING TO Up.
WAIT UNTIL SHIP:ALTITUDE > 500.
// more code here

and it still doesn't work..

If I run it like this, it will immediately pitch over and crash. So I enabled SAS, let it go for a while, disabled SAS and of course, it immediately pitched over again. This is screenshot from just a moment after pitching over

Incidentally, you're not actually showing us the relevant part of your script.

What is buried inside the bit you described as:

// more code here

Because notice your screenshot is from an altitude of 593.

And your script says WAIT UNTIL SHIP:ALTITUDE > 500.

So... if you *just* started pitching over there ... then you've just hit the next part of the program after that - which we can't see.

[Mirean]

print "Initiating ascent sequence in 5.".
LOCK THROTTLE TO 0.
SET now to time:seconds.
WAIT UNTIL time:seconds > now + 5.
print "Now.".
STAGE.
LOCK THROTTLE TO ((SHIP:MASS*9.8)/SHIP:MAXTHRUST)*1.4.
LOCK STEERING TO HEADING(90, 90).
WAIT UNTIL ALT:RADAR > 400.
print "Initiating hover sequence.".
LOCK THROTTLE TO (SHIP:MASS*9.8)/SHIP:MAXTHRUST/2.
WAIT UNTIL VERTICALSPEED < 1 AND ALT:RADAR > 500.
LOCK THROTTLE to (SHIP:MASS*9.8)/SHIP:MAXTHRUST-0.01.
SET now to time:seconds.
WAIT UNTIL time:seconds > now + 10.
print "Initiating descent sequence.".
LOCK THROTTLE TO (SHIP:MASS*9.8)/SHIP:MAXTHRUST/2.
WAIT UNTIL VERTICALSPEED < -20 AND ALT:RADAR < 400.
LOCK THROTTLE TO ((SHIP:MASS*9.8)/SHIP:MAXTHRUST)-0.01.
WAIT UNTIL ALT:RADAR < 200.
LOCK THROTTLE TO ((SHIP:MASS*9.8)/SHIP:MAXTHRUST)*1.5.
WAIT UNTIL VERTICALSPEED > -10.
LOCK THROTTLE TO ((SHIP:MASS*9.8)/SHIP:MAXTHRUST)-0.01.
WAIT UNTIL ALT:RADAR < 30.
LOCK THROTTLE TO ((SHIP:MASS*9.8)/SHIP:MAXTHRUST)*1.5.
WAIT UNTIL VERTICALSPEED > -2.
LOCK THROTTLE TO ((SHIP:MASS*9.8)/SHIP:MAXTHRUST)-0.01.
WAIT UNTIL ALT:RADAR < 10.
SET THROTTLE TO 0.
print "Ship has landed.".

As I said, it starts pitching over immediately after launch, so the "more code" part shouldn't be the problem...this is the working version with heading, however, if you replace it with "Up" it will pitch over

[Dr_Goddard]

What I have is no code. I do have screenshots.

There have been internal combustion engines before, but they were very slow, lacked power and needed support from launch stabilizers - fixed to the launchpad.

Mine can drive around en hopefully even power airplanes. This is unique in KSP, never done before.

Very cool constructions for sure.

Maybe you need to think way out of the box. After all there is no reason why we have to adhere to the normal rules of physics.

There has to be some part that will interact with another part to give a result.

What about a small rocket engine on the crank that hits a thermometer device?

What about a barometer? Would it sense the pressure from a manoeuvring thruster?

Edited January 14, 2015 by Dr_Goddard

[Azimech]

What an excellent idea! I'll create a rocket engine that doesn't produce thrust nor FX, only heat.

[Dr_Goddard]

What an excellent idea! I'll create a rocket engine that doesn't produce thrust nor FX, only heat.

Atta boy. Hope you don't mind if I steal it when you get it working.

[Camacha]

As I said, it starts pitching over immediately after launch, so the "more code" part shouldn't be the problem...this is the working version with heading, however, if you replace it with "Up" it will pitch over

This all suggests kOS sees up as another direction than you. Steven and I both asked you: are you sure the command module is mounted right side up? Your craft might be trying to right itself the wrong way up, meaning it keels over violently.

[Azimech]

Atta boy. Hope you don't mind if I steal it when you get it working.

When I get the engines running, I will release everything together with the engine construction kit.

- - - Updated - - -

I wanted to try one more time.

LOCK cosValue to VDOT(PIST:FACING:FOREVECTOR,CRANK:FACING:TOPVECTOR).
LOCK sinValue to VDOT(PIST:FACING:STARVECTOR,CRANK:FACING:TOPVECTOR).
LOCK crankAngle to ATAN2( sinValue, cosValue ).

I've set the names and all, but then complains about non existing ATAN2 thing and points out things about sinus & cosinus that are wrong, and other incomprehensible ....e, but doesn't explain why not, so changing the vector ... I will not continue with this one, since my blood is boiling and I already have the urge to grab my pickaxe. How do you do it people? Why can't programming be like building with lines and shapes? Or like schematics in electronics and hydraulics <-- those are easy. This is worse than Klingon!

I will try it with the thermo sensor option. First sleep & nightmares.

[Camacha]

I will not continue with this one, since my blood is boiling and I already have the urge to grab my pickaxe. How do you do it people? Why can't programming be like building with lines and shapes? Or like schematics in electronics and hydraulics <-- those are easy. This is worse than Klingon!

In my perception that is programming. It is doing really complicated things easily and then spending the next two hours figuring out why exactly the computer thinks X is Y. I always consider it akin to dealing with the peculiar kid. Find out what it wants in what way and you will be golden.

[Azimech]

Thinking aloud here ...

.....

Temperature sensor is no go, response is extremely sluggish and measurement is bonkers. In the end I placed in the blast of a closed-cycle rapier: max temp after two minutes at full power: 329C.

.....

Barometer: nothing. Very realistic, Squad

.....

New approach, two accelerometers. One attached at a normal place, the other one gets a blow with a rod every x degrees.

.....

Nope ... the thing measures only acceleration of the root part.

.....

Wheel telemetry, measurement of suspension travel ... Too bad it was last updated in June. Still, it's worth a try.

http://forum.kerbalspaceprogram.com/threads/82180-WheelTelemetry-mod-1-1

.....

Bingo.

- - - Updated - - -

Now I now that a MM script adds partmodule "wheeltelemetry" to my sensor. I don't know what next. The manual is incomplete but where there is text, there is a lot. I'd like to know ONE way of doing things instead of shown 4 different approaches, all of them unclear and without tutorial. But I was going to bed ... 4 hours ago.

Edited January 14, 2015 by Azimech

[Mirean]

This all suggests kOS sees up as another direction than you. Steven and I both asked you: are you sure the command module is mounted right side up? Your craft might be trying to right itself the wrong way up, meaning it keels over violently.

Yup, you can see it in the picture I attached, I'm sure it's the right way

[Dunbaratu]

I've set the names and all, but then complains about non existing ATAN2 thing

I had it wrong. it's the full word: ARCTAN2, not ATAN2. In lots of other languages it's atan2, so I remembered it wrong.

and points out things about sinus & cosinus that are wrong, and other incomprehensible ....e, but doesn't explain why not, so changing the vector

That rambles a bit and is impossible to decipher what you're talking about.

... I will not continue with this one, since my blood is boiling and I already have the urge to grab my pickaxe. How do you do it people? Why can't programming be like building with lines and shapes? Or like schematics in electronics and hydraulics <-- those are easy. This is worse than Klingon!

It is like building with lines and shapes in exactly the same way that math is like drawing. things like sine, cosine, tangent, functions, derivatives, etc all have meanings that do in fact map to visual representations, bu doing everything visually, while easier to follow, would be very slow. You can manipulate an equation faster than you can draw out graphically what those manipulations mean. Similarly you could program graphically, and there's been attempts to do so where you make the languages constructs into blocks and lines connecting them, but aside from proofs of concept they haven't really caught on, and for good reason. They may be easier to understand but they'er slower to work with once you do understand them.

It's the common learning curve problem where usually the technique that's easier in the long run is harder in the short run.

- - - Updated - - -

Yup, you can see it in the picture I attached, I'm sure it's the right way

It's too small in the picture to tell which way is right side up on that wafer thin part.

Do this on the launchpad:

set vd to vecdrawargs(v(0,0,0), 10*ship:up:vector, red, "ship:up vector", 1, true ).

(I'm typing that from memory - I hope I have the arguments correct).

If you have it mounted correctly, that should make an arrow pointing up. If you have it upside down, it will make an arrow pointed down through the launchpad.

[kcs123]

I created a user defined language file for kOS scripting in Notepad++, to make my scripting easier.

DOWNLOAD v 1.0

Install instructions below.

Released under GNU GPL version 3, if that's important for this. It's just an xml file, so it is its own source.

It automatically color codes things to make the script clear, as well as allowing things like folding bracketed "{ }" sections down for easier editing.

Suggestions on better formatting are appreciated. If I missed any keywords let me know.

Currently:

Flow control -- navy blue, bold, italic

Standard commands (SET, etc.) -- blue

Functions (things with parentheses after) -- black, bold

Things in quotes -- purple

LIST type things -- brown

Other recognized words (like :suffixes and 'ship') -- black

Operators ( + / and, etc.) -- blue

Numbers -- green

Anything I didn't tell it to recognize (which is hopefully just your variables) -- black with yellow highlighting.

Example:

http://i.imgur.com/Zqw2rE2.jpg

Install instructions:

1. In notepad++ 6.7, go to Language>Define your language.

2. Import the downloaded file.

3. ****It seems you have to restart Notepad++ at this point or it won't let you select the new format.*****

4. Go to Language>kOS Script.

That is nice touch for kOS and KSP. Still didn't have time to upgrade my crafts for 0.90 and finally give kOS some love that deserves. Didn't even think about it to do editing in notepad++ instead of ingame terminal, that will comes handy when I mess up and need to debug and find what was gone south

Now, some critics about color scheme. I think that lot of people use Visual studio, at least those that have some basic programming skills and don't afraid to use kOS.

In visual studio for c++ and C# green is commonly used for comments, so don't use that color for numbers, could be confusing for people that shift from different kind of languages in one day.

Suggestion that will more fit with C++ or C#

Flow control -- navy blue, bold, italic

Standard commands (SET, etc.) -- blue

Functions (things with parentheses after) -- black, bold

Things in quotes -- Red

LIST type things -- brown

Other recognized words (like :suffixes and 'ship') -- object like keywords - aqua or light blue

Operators ( + / and, etc.) -- blue, can stay blue, but since red is used for thing in quetes could be purple

Numbers -- orange - more fits existing notepad++ color schemes, some editors use blue, some black, no consistency here, but avoid green

Just personal preference, some may or may not agree.

[Azimech]

"susp. compression" <-- that's the one I was looking for.

So the structure would be as simple as

"if from part "pos" the value "susp.compression" becomes larger than 1.22,

toggle action group x

repeat"

[Wercho]

Would the devs prefer that I move this to a new thread?

Didn't even think about it to do editing in notepad++ instead of ingame terminal, that will comes handy when I mess up and need to debug and find what was gone south

Yeah. I do almost all of my kOS coding in a separate window rather than ingame. Specifically, I share the scripts directory on my network and use my laptop for writing code without having to tab out of ksp.

Now, some critics about color scheme...

Ok, I've created an updated color scheme. I'm torn on making the keywords light blue, because so much more of my code is keywords than other things that it ends up being all light blue. I did it anyway. Numbers were made black because orange was just too jarring for me. Quotes changed to red.

kOS formatting for Notepad++

Download 1.01

Link to original post with better description, pics

[Robotengineer]

Will this work with the new RemoteTech? I saw that they had API changes.

[Wercho]

Ok, thanks to the new direction functions and especially

tutorial video, I was able to write code that back calculates the reference direction (for the ascending node) based on the orbit of any body with an inclined orbit (so that it has an ascending node with a definite position).

Here it is if others want to check it out... you know, for satellite deployment contracts, say...

//find the reference direction

//Use eeloo to back calculate the reference direction.
//Anything that has an inclined orbit will do.
SET refbody to eeloo.

//Get the position of the reference body with reference to its parent.
SET refbodypos TO refbody:position-refbody:body:position.

//Get the vector normal to the orbit of refbody.
//This normal vector is used for rotating around.
SET refbodyorb TO vcrs(refbodypos,refbody:obt:velocity:orbit).

//Get the location of the ascending node relative to the parent body by rotating the position vector around the orbit normal vector. Degrees to rotate is the negative of the true anomaly plus the argument of periapsis.
SET refbodyan TO angleaxis(-1*refbody:obt:trueanomaly-refbody:obt:argumentofperiapsis,refbodyorb)*refbodypos.

//Get the Celestial up vector (or maybe it should be called celestial north. I'm not sure.)
//Do this by rotating the refbody's orbit normal vector around the ascending node vector by inclination degrees.
SET celup TO angleaxis(refbody:obt:inclination,refbodyan)*refbodyorb.

//Get the reference vector by rotating around celestial up by the negative of the longitude of the ascending node.
SET refdir TO angleaxis(-1*refbody:obt:lan,celup)*refbodyan.

//Using this I drew a vector from Kerbin to Minmus without referencing Minmus' position, just its orbital characteristics.
//The same could be used for anything, such as satellite contract orbits.
SET minmusan TO angleaxis(minmus:obt:lan,celup)*refdir.
SET minmusorb TO angleaxis(-1*minmus:obt:inclination,minmusan)*celup.
SET minmuspos TO angleaxis(minmus:obt:argumentofperiapsis+minmus:obt:trueanomaly,minmusorb)*minmusan.
SET minmuspos:mag TO minmus:altitude+minmus:body:radius.

SET minmusdraw TO vecdrawargs(kerbin:position,minmuspos,white,"Minmus",1,true).

[Mirean]

It's too small in the picture to tell which way is right side up on that wafer thin part.

Do this on the launchpad:

set vd to vecdrawargs(v(0,0,0), 10*ship:up:vector, red, "ship:up vector", 1, true ).

(I'm typing that from memory - I hope I have the arguments correct).

If you have it mounted correctly, that should make an arrow pointing up. If you have it upside down, it will make an arrow pointed down through the launchpad.

http://i.imgur.com/a7KjRa2.jpg As I said, I'm sure it's mounted correctly. When I type "LOCK STEERING TO Up." into the console it works fine too, only when I run my script, it pitches over.

EDIT: I tried it again, and now it doesn't pitch over. That is really, really weird...it is however not perfect, it oscillates a lot around the up vector and it drifts sideways. I think that might be due to the lack of reaction wheels though, now, the only control is gimbal

Edited January 14, 2015 by Mirean

[kcs123]

Would the devs prefer that I move this to a new thread?

Yeah. I do almost all of my kOS coding in a separate window rather than ingame. Specifically, I share the scripts directory on my network and use my laptop for writing code without having to tab out of ksp.

Ok, I've created an updated color scheme. I'm torn on making the keywords light blue, because so much more of my code is keywords than other things that it ends up being all light blue. I did it anyway. Numbers were made black because orange was just too jarring for me. Quotes changed to red.

kOS formatting for Notepad++

Download 1.01

Link to original post with better description, pics

Thanks, looks nice, just tried few scripts from this thread, it will be more fun to customize kOS scripts trough notepad++

Black color for numbers fits nice too. Now that green is not for numbers you can use that for lines that begins with "//".

Light gray italic is good for comments too, but with green it stants out more out of the rest of code, when you need to stress out some important stuff in code that need more attention. I can custumize it further for my personal purpose, so there is no need to make it for public if you don't want, it is just another positive feedback.

Thanks for making this, it will be put to good use soon

[Dr_Goddard]

I have managed to get multiple cores to boot with distinct bootXX.ks scripts by editing the craft file.

The problem with selecting from multiple boot files in the VAB is certainly a bug IHMO. Simply can't be done.

I'd be happy to be proven wrong, but no big problem if I need to wait for a fix.

BTW, I have a few tricks to share for fancy robot scripts.

The first one that everyone should try is running a XX.ks file with all the list and partmods work first, and then running separate scripts for the logic.

The variables will stay in memory as long as your core is powered up, and it saves a ton of time loading files.

Since robotics will likely be a collection of scripts to perform actions, your robots will be much more responsive.

If I can get a few hours in on Kerbal this evening, I'll post some videos of my progress.

For those of you that are wondering when I'll get my robot off Kerbin... I launched a Duna mission last week.

My rover and support module are in orbit, and the fellows are all anxious to get the programming so they can be on their way.

[Ziw]

Hooray!

After a couple of very long evenings, a lot of Wikipedia browsing along some peeking into MechJeb sources for ideas (as I'm not an astronomer and had zero knowledge about orbital mechanics and maneuvers) I've finished my automated rendezvous script.

It has some limitations, like the chaser must be in a lower orbit, which in turn must be quite close to a circular orbit, but it works!

I found out the hard way that programming and testing KOS scripts may be even more addictive that playing KSP - time flies past really fast.

BTW it all started when I decided to try RemoteTech for my second playthrough and stumbled upon Rescue Kerbal from orbit mission. I could've saved the poor sod from the orbit in 1/100th of the time i spent on writing the script but I call WORTH. I learned/remembered more about orbits, vectors and orbital maneuvers in 2 days more than in last 10 years (and I have master's degree in applied math and computer science, this helps a little bit).

I will not share the script itself as I believe the learning experience of writing it yourself is priceless and I don't think my script is good enough to be shared (pretty sure there are some noob things there). If you need some pointers you can look into MechJeb sources for orbital maneuvers, though some things cold be done more elegantly through built-in KOS functions.

On a side-note I found a strange behavior/bug - when KSP is on pause (via ESC button) with KOS Terminal open on probe, for some reason probe's electric charge is still consumed (very slowly). I noticed it while alt-tabbed to notepad++ for prolonged periods - when I return to KSP and unpause the game the probe's EC can even go to 0 and I had to wait until solar panels replenish the charge. I remedied it by putting bigger batteries on my probes in sandbox mode, but I still find this behavior as strange.

[Dunbaratu]

On a side note - I see some people posting art where they've clearly got their hands on some rendering of the KSP parts inside some type of cad or diagramming tool, as in the recent post by Dr_Goddard.

I might find such things useful in diagraming examples for docs. Where do you find the resources for those things. I'm assuming you didn't draw the parts yourself - they look too much like the rendered parts for that - I assume they were auto generated by somebody.

[Ziw]

Kronal Vessel Viewer

http://www.curse.com/ksp-mods/kerbal/224287-kronal-vessel-viewer-kvv-exploded-ship-view

Does it look like what you're looking for?

[Dr_Goddard]

On a side note - I see some people posting art where they've clearly got their hands on some rendering of the KSP parts inside some type of cad or diagramming tool, as in the recent post by Dr_Goddard.

I might find such things useful in diagraming examples for docs. Where do you find the resources for those things. I'm assuming you didn't draw the parts yourself - they look too much like the rendered parts for that - I assume they were auto generated by somebody.

Hey Ziw, Good going on the docking script! That sounds like quite an adventure.

I'm a writer by profession. Mostly technical literature, not novels (yet). Programming kOS is my relaxation time.

It's a great way to learn some programming basics.

The craft rendering is done with a plugin.

http://www.curse.com/ksp-mods/kerbal/224287-kronal-vessel-viewer-kvv-exploded-ship-view

It's a nice bit of programming itself, but the interface is a bit tricky.

[Dr_Goddard]

New day, new challenges.

What worked before with simple routines is now a problem when I try something more complex.

I'm working a three segment robotic arm, as an example.

My script says basically:

"if you are not where I say to go, then go in the direction of that angle"

"when you reach that angle, then stop, and set a flag saying you are there"

What tends to mess with this is the physics.

The arms have "bounce".

So an arm segment reaches the point its set to go, and sets a flag saying it's there.

This point is precisely 0.00000001 degrees away from "not being there"

so in the next loop, if the arm bounces which it is likely to do since other arms and attached segments are moving too, the arm looks and says "hey I'm not where I should be anymore.

and it moves again, and sets a flag again.

Meanwhile; I'm counting flags and looking for the number of flags to indicate all the segments have reached their set points.

What happens is, one segment may set 2 or more flags... making it uncertain whether all the segments have reached their goals.

So now I need a bit of code to say: "If a flag is set on a segment, then skip that segment in the next loop."

Thanks for the opportunity to rubber-duck this one.

The results of the glitch are hilarious. My six legged robot goes into a kind of tap dance mode, and finally all the legs get twisted and it falls over dead like a spider hit with bug spray.