kOS Scriptable Autopilot System 0.9

[GavinZac]

Ideas, which may fit with your vision for the mod:

functions

includes/requires (a way of using another file of 'functions' as a library)

debugger/loop detector (so the game crashes less; the terminal should crash, not KSP!)

importing/exporting to/from PluginData filesystem

log to file in virtual filesystem or real filesystem.

API for extensibility (TOGGLE KASWINCH.)

command line arguments (run launchToOrbit 75000.)

runtime input ("enter desired orbit altitude: _").

Edit: right, I've gone to bed with a headache after 6 hours trying to get something into space with this, that I can fly up by hand. I must emphasise again my desire for text file editing (I tried editing the ARC file which was a disaster as the plugin uses some special characters and doesn't account for any possibility that it might have changed, leading to garbled overwrites.), as it's just too clunky to code anything substantial in the laggy little box. The crowning moment and source of my current headache is that having the craft on the launchpad with all the associated lag for an extended period of time led to my PC actually overheating and shutting itself down, discarding my work.

Don't get me wrong, this is exactly what I've been waiting for and it's out of excitement at being so close that I am frustrated. Thank you for your work.

Edited August 26, 2013 by GavinZac

[M5000]

I think maybe you were reading more into it than was there. I clearly stated that it was unqualified scrutiny for the sake of ease of use. It in no way will affect the use or performance of the software itself on any kind of level. It's just a preference. That is the problem with text. Also I don't think you read my post where I said I love this thing. About the angle preference, that is just a peeve of mine personally. FYI. I once wrote a letter to the Discovery Network asking them to at least educate their Narrators on the difference between an Internal combustion Engine and "Motor". I don't mind if the Igmos on the shows call everything a motor, but the show narrator should know the difference. Certainly for a show on the Science Channel.

In the end the same thing is happening anyway. How about being able to initialize a preference such as vector absolute. or vector relative.?

Just for clarity. My criticism wasn't anger. It's just criticism. As I said already, I enjoy this mod a lot and hope it continues to develop and become more friendly to use.

Hm, I don't know, maybe I did. Oh well, not a big deal. It just came off as a bit abrasive at first. No matter, all is well I believe.

I'm going to monitor this thread, not for arguments (heheh..) but for the development of this addon.. It looks great but I'm going to watch for dev updates. This could be the next must-have pilot-assist mod.

[Ratzap]

Could your readme page include a section detailing exactly which part of the rotation/vector is which axis? Meaning

R(0, 10, 90)

is rotation in which axis for each position. I can try things out and figure it out quickly but to save time for others it'd be handy for it to be in the readme. Also is that R(0,0,180) your first video talks about still necessary? The things people are posting here don't seem to include it. If it is still needed that needs to go on the readme page too.

[Jasmir]

I'am trying to get a smooth gravi-turn, but i don't get the point how to use variables in the R(0,0,0) statements:

clearscreen.
set mOrbit to 200000.
set mAtmoHight to 70000.

set pVal to 0.

print "fasten your seatbelts!".
wait 1.

lock steering to UP + R(0,0,180) - R(0,pVal,0).
lock throttle to 1.


print "here we go...".

until apoapsis > mAtmoHight {
print pVal.

set pVal to apoapsis / mAtmoHight * 90.

}.

The problem is the "lock steering to UP + R(0,0,180) - R(0,pVal,0)." Line. Has somebody a idea?

[JewelShisen]

I'am trying to get a smooth gravi-turn, but i don't get the point how to use variables in the R(0,0,0) statements:

clearscreen.
set mOrbit to 200000.
set mAtmoHight to 70000.

set pVal to 0.

print "fasten your seatbelts!".
wait 1.

lock steering to UP + R(0,0,180) - R(0,pVal,0).
lock throttle to 1.


print "here we go...".

until apoapsis > mAtmoHight {
print pVal.

set pVal to apoapsis / mAtmoHight * 90.

}.

The problem is the "lock steering to UP + R(0,0,180) - R(0,pVal,0)." Line. Has somebody a idea?

I see your issue. It only locks the steering once. You need to put your lock steering line into a loop with your code that updates the pVal. Try this instead.

clearscreen.
set mOrbit to 200000.
set mAtmoHight to 70000.

set pVal to 0.

print "fasten your seatbelts!".
wait 1.

lock steering to UP + R(0,0,180) - R(0,pVal,0).
lock throttle to 1.


print "here we go...".

until apoapsis > mAtmoHight {
print pVal.

set pVal to apoapsis / mAtmoHight * 90.
[B]
lock steering to UP + R(0,0,180) - R(0,pVal,0).[/B]
}.

Edited August 26, 2013 by JewelShisen
added code

[KevinLaity]

I'm going to monitor this thread, not for arguments (heheh..) but for the development of this addon..

While I will be checking this thread, the main source of news is here.

[KevinLaity]

Could your readme page include a section detailing exactly which part of the rotation/vector is which axis? Meaning

R(0, 10, 90)

is rotation in which axis for each position. I can try things out and figure it out quickly but to save time for others it'd be handy for it to be in the readme. Also is that R(0,0,180) your first video talks about still necessary? The things people are posting here don't seem to include it. If it is still needed that needs to go on the readme page too.

Sure, I'll update the readme at some point.

The 180 is never strictly necessary, but if you don't have it your craft will flip around to match the 0 degree roll you're asking for (unless you flipped it yourself in the VAB first). The 180 is just to make the takeoff look less ugly. I've tried to find ways of making it ignore roll, but that's significantly harder than it sounds.

[JewelShisen]

so the R(x,y,z) is basically R(pitch,yaw,roll) right?

[Jasmir]

I see your issue. It only locks the steering once. You need to put your lock steering line into a loop with your code that updates the pVal. Try this instead.

That wouln't help. The program die at the first "lock steering..." line, because a did something wrong with putting the variable in the R()-thing. But i don't know what...

[KevinLaity]

That wouln't help. The program die at the first "lock steering..." line, because a did something wrong with putting the variable in the R()-thing. But i don't know what...

Unless you're compiling from source, you don't have the ability to use variables inside R() expressions yet. This will be fixed in 0.35

Edited August 26, 2013 by KevinLaity
Typo

[Astral_Nomad]

This is the German Layout ;-)

A Guy in the German Forum found out that we need to Press SHIFT + Ü for the -> : <- and the -> ; <- ;-)

Now everything works fine!

BUT: The Mod is incompatible with one or more of these:

-RemoteTech

-Chatterer

-ISA MapSat

-DeadlyReentry

Havn't testetd yet wich one makes the Problems ;-)

If you have installed these mods you don't get a complete focus on to the console. If you hit the Spacebar to write you'll Stage... You need to go to DockingMode first, that the Staging does not work. And the Modifier Key to Lock Staging does not work anymore with theses Mods installed....

You can also add Hullcam to that.. it will unlock the keys it uses from the console it seems, which is what I believe is causing me to have issues with entering data.

[nearlyNon]

Am I the only one having issues with getting the terminal to go into focus? It won't come into focus at ALL for me, but it still lets me type into it because of that one bug already listed, meaning I try to get it in focus by clicking on it, and it seems like it works but instead as soon as I have to hit space ("edit launch" for instance)... kaboom.

[Jasmir]

Ok, i've my first progam ready:

clearscreen.
set mAtmoHight to 70000.
set vAtmoDense to 5000.
set minSpeed to 100.

set vThr to 1.
lock throttle to vThr.

until altitude > mAtmoHight {

set tSpeed to altitude + mAtmoHight.
set tSpeed to tSpeed / mAtmoHight.
set tSpeed to tSpeed * minSpeed.
set vFactor to altitude + vAtmoDense.
set vFactor to vFactor / vAtmoDense.
set vScaleFactor to altitude / vAtmoDense.
set vScaleFactor to vScaleFactor / 4.
if vScaleFactor > 1 { 
set vFactor to vFactor * vScaleFactor.
}.
set tSpeed to tSpeed * vFactor.

set pDiff to verticalspeed / tSpeed.
set pDiff to pDiff / 10.

if verticalspeed > tSpeed {
set vThr to vThr - pDiff.
}.
if verticalspeed < tSpeed {
set vThr to vThr + 0.05.
}.
if vThr > 1 { set vThr to 1. }.
if stage:liquidfuel < 1 { print "stage!". }.
print stage:liquidfuel.
}.

It does a simple throttle management, and (theoreticaly) autostaging.

There are 3 issues:

1) The "stage:liquidfuel"-thing dosn't give me the right value back. It says "0" the whole time on my "Apollo Nachbau" Vessel (http://pastebin.com/FCS7h2mK). On a way more simple vessel, it worked. So i have to deactivate autostaging for now.

2) The "VELOCITY"-thing give 3 values back, not only one. Thats weird, so i have to use the "verticalspeed" instead. (A "surfacespeed" would be very nice btw.)

3) It runs incredible slow. With the "apollo nachbau"-vessel, the throttle adjustments came every 3-4 seconds. A more often cycle would be very nice .

[theSpeare]

Minimizing console while editor is open still registers input from keyboard

EDIT: Nevermind, you already addressed this issue in your dev blog

[Desrtfox]

Ok, i've my first progam ready:

clearscreen.
set mAtmoHight to 70000.
set vAtmoDense to 5000.
set minSpeed to 100.

set vThr to 1.
lock throttle to vThr.

until altitude > mAtmoHight {

set tSpeed to altitude + mAtmoHight.
set tSpeed to tSpeed / mAtmoHight.
set tSpeed to tSpeed * minSpeed.
set vFactor to altitude + vAtmoDense.
set vFactor to vFactor / vAtmoDense.
set vScaleFactor to altitude / vAtmoDense.
set vScaleFactor to vScaleFactor / 4.
if vScaleFactor > 1 { 
set vFactor to vFactor * vScaleFactor.
}.
set tSpeed to tSpeed * vFactor.

set pDiff to verticalspeed / tSpeed.
set pDiff to pDiff / 10.

if verticalspeed > tSpeed {
set vThr to vThr - pDiff.
}.
if verticalspeed < tSpeed {
set vThr to vThr + 0.05.
}.
if vThr > 1 { set vThr to 1. }.
if stage:liquidfuel < 1 { print "stage!". }.
print stage:liquidfuel.
}.

It does a simple throttle management, and (theoreticaly) autostaging.

There are 3 issues:

1) The "stage:liquidfuel"-thing dosn't give me the right value back. It says "0" the whole time on my "Apollo Nachbau" Vessel (http://pastebin.com/FCS7h2mK). On a way more simple vessel, it worked. So i have to deactivate autostaging for now.

2) The "VELOCITY"-thing give 3 values back, not only one. Thats weird, so i have to use the "verticalspeed" instead. (A "surfacespeed" would be very nice btw.)

3) It runs incredible slow. With the "apollo nachbau"-vessel, the throttle adjustments came every 3-4 seconds. A more often cycle would be very nice .

I'd be surprised if this is working at all.

All the lines like this:

set vThr to vThr + 0.05.

with a floating point number are going to be interpreted as:

set vThr to vThr + 0.

Unless I'm mistaken. Also, I don't see any DECLARE statements for your intenal variables. Last time I tried this, I got an error until I added the declare statement.

The reason that you're getting three numbers for velocity is that the system is returning velocity not speed, i.e a vector not a scalar.

[nearlyNon]

I'd be surprised if this is working at all.

All the lines like this:

set vThr to vThr + 0.05.

with a floating point number are going to be interpreted as:

set vThr to vThr + 0.

Unless I'm mistaken. Also, I don't see any DECLARE statements for your intenal variables. Last time I tried this, I got an error until I added the declare statement.

The reason that you're getting three numbers for velocity is that the system is returning velocity not speed, i.e a vector not a scalar.

actually the interpreter is smart enough to determine that that's a floating point number rather than an end of command. only through hacky "if the next thing after this is a number" ways though.

[razark]

All the lines like this:

set vThr to vThr + 0.05.

with a floating point number are going to be interpreted as:

set vThr to vThr + 0.

Unless I'm mistaken.

The mod author dropped in a while back and stated that a "." followed by a number would be interpreted as a floating point number. My brief testing tonight shows this to be the case.

Edit:

Post #65

http://forum.kerbalspaceprogram.com/showthread.php/47399-kOS-Scriptable-Autopilot-System-0-35?p=615644&viewfull=1#post615644

Edited August 27, 2013 by razark

[Desrtfox]

The mod author dropped in a while back and stated that a "." followed by a number would be interpreted as a floating point number. My brief testing tonight shows this to be the case.

Edit:

Post #65

http://forum.kerbalspaceprogram.com/showthread.php/47399-kOS-Scriptable-Autopilot-System-0-35?p=615644&viewfull=1#post615644

Great news.

Also, it turns out I was wrong about the need for the declare as well. Set does the declare for you.

So, the only part I was right about was the vector bit. Woohoo, go me!

Edited August 27, 2013 by Desrtfox

[Payload]

Current Version: 0.35

- Bug-fixes

- Resource tags re-enabled

- Variables within R() expressions

Woot! Also I managed a very mechjeb like apoapsis hold and Circ burn in my latest rocket script prototype.

when apoapsis > 99999 then
 {
 lock throttle to 0.
 print "Waiting For Apoapsis".
 until altitude > 69500
  {
  if apoapsis < 99995
  { lock throttle to .05. }.
  if apoapsis > 99999
  { lock throttle to 0. }.
  }.
 }.

when eta:apoapsis < 1 then
 {
 lock throttle to 1.
 print "Orbit Injection Burn!".
 }.

when periapsis > 80000 then
 {
 lock throttle to .1.
 }.

when periapsis > 99000 then
 {
 lock throttle to 0.
 wait .5.
 sas on.
 toggle ag1.
 set orbit to 1.
 print "You Are Now In Orbit!".
 }.

[razark]

Finally having a chance to muck about with this. I like it a lot. Right now, I've got it running on the other monitor, looking out the window of a one-Kerbal capsule, watching the horizon drift by.

Does this save programs between flights?

[GavinZac]

Finally having a chance to muck about with this. I like it a lot. Right now, I've got it running on the other monitor, looking out the window of a one-Kerbal capsule, watching the horizon drift by.

Does this save programs between flights?

The files are only saved if they are on Volume 0. It's a good idea to edit them on Volume 0 and copy them to Volume 1 when you want to run them.

Looking forward to trying the variables in vectors, makes much more sense than lots of if statements. Unfortunately I've just lost another batch of work because of another overheating with the terminal window open. Needless to say it's a bit baffling that a terminal emulator is taxing enough to cause an i7 to crash and burn while calculating the trajectories of 200 or so flights in progress does not.

Edited August 27, 2013 by GavinZac

[razark]

The files are only saved if they are on Volume 0. It's a good idea to edit them on Volume 0 and copy them to Volume 1 when you want to run them.

Thanks for verifying. I figured that's how it worked, so I've been doing mostly that. I saved my programs to v0, then copied them to v1 and made edits for the specific vehicle I'm using.

More than two volumes would be useful, though.

[KevinLaity]

Thanks for verifying. I figured that's how it worked, so I've been doing mostly that. I saved my programs to v0, then copied them to v1 and made edits for the specific vehicle I'm using.

More than two volumes would be useful, though.

Actually, you should be able to quicksave and save the contents of your onboard volume. Although I have heard that this may not be working 100%.

More volumes: you can actually add more kOS units to your craft. Each terminal can see all the attached volumes. This is for transferring programs when craft are docked.

[razark]

More volumes: you can actually add more kOS units to your craft. Each terminal can see all the attached volumes. This is for transferring programs when craft are docked.

Awesome. Ok, looking at that now. Everything has access to v0, and each part adds a numbered volume.

Are you planning to do more sizes of the kOS units, or a radially attached version that could work on any size vehicle?

[theSpeare]

We really need an external edit capability. I've started having larger programs and having to backspace entire chunks of code and being unable to copy and paste is becoming very tedious