[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Trewor007]

if faza=1 {
set target to y.  // y is " duna"
lock steering to ship:prograde. if round(ea)=round((kat21)-(SNS*(BurnTime/2))){lock throttle to 1. wait 1. }.//trigger condition for start
if ship:liquidfuel=0 and huj=0{stage. set huj to 1.}.
if  ship:patches:length>2{ set i to ship:patches:length. print i at (3,20). if ship:patches[i-2]:body:apoapsis<47921949 {lock throttle to 0. wait 2. set faza to 2.}.}.}.//trigger condition for stop the 47921949 is Duna SOI radius..
if faza=2{clearscreen. break.}.// place-holder

Hi i have a little problem witch my newest part of code. the STOP trigger part of the code does not work like I've imagined. It sees Duna, but there's no reaction. Probably the patches are all wrong but they are something new and threes not enough examples to check. If someone see where I made a mistake please tell me.

[Dunbaratu]

print (ship:velocity:surface*v(1,0,1)):mag.

says values of double can't have suffixes.

That looks correct to me. The "*" operator on vectors is mapped to the dot product. So you took the dot product of two vectors, which is already a scalar - not a vector, and tried to take its :mag suffix.

[Dunbaratu]

So apparently http://ksp-kos.github.io/KOS_DOC/summary_topics/gettingStarted/index.html is missing? Was really looking forward to poking at kOS and trying to figure it out, but it's a touch difficult without a starting point to familiarize myself. Guess I'll do it the hard way and throw myself in.

It's there now. The documentation builder software failed to export that file to the public site and I have no clue why, because the second time I re-ran the builder just now (to try to diagnose this problem and see what happened), it just worked correctly this time around. I have no clue why it didn't the first time. I didn't change anything.

[erendrake]

New Release v0.15.1

On Github Also available on kerbalstuff and curse

You guys gave some great bug reports and we could quickly knock some of them out so there is the first part of the post v0.15 cleanup releases

Bugfixes:

* All Lists have suffixes again
* in the config panel, IPU no longer gets stuck at 50

On Github Also available on kerbalstuff and curse

[Dunbaratu]

There should be a fix for the syntax problem @ouch discovered soon:

SET arrows[x]:vec to v(0,0,0).

I found the problem and fixed it in my own private copy but there's Real Life events that may interfere with the process of getting it merged into the main repository and released, because of... uhm.... things.

In the meantime, if you need a workaround, in places where you try to do a thing like this:

  set foo[x]:suffix to whatever.

You'll have to split apart the expression into component parts like so:

  set fooX to foo[x].
  set fooXSuffix to fooX:suffix.
  set fooXSuffix to whatever.

in order to avoid the part where the parser is currently doing the wrong thing when its all combined together.

Edited November 17, 2014 by Steven Mading

[Sinza]

Hey together,

just tried to use the new module functionality and ran into a problem.

I tried to do something simple and wanted to switch on an engine on my vessel on the launchpad.

I did the following:

SET mainengine TO SHIP:PARTSTAGGED(mainengine).

and so far it worked, but when I tried this:

SET enginemodules TO mainengine:MODULES. (to be able to print the available modules and to decide which one i have to activate by :DOEVENT)

it Returned that the suffix MODULES either can't be used with the get operation or that no ListValue ever has such a one.

I also tried :ALLMODULES and he operations get and print...

I have to say I'm quite new to kOS, but my first attempts worked after a short time as they should.

But until now I havent been able to figure out what to Problem is with the above mentioned Problem, even under the help of all the documentation and the wiki.

Any answers are appreciated,

greetigns.

[rdwulfe]

It's there now. The documentation builder software failed to export that file to the public site and I have no clue why, because the second time I re-ran the builder just now (to try to diagnose this problem and see what happened), it just worked correctly this time around. I have no clue why it didn't the first time. I didn't change anything.

Thanks so much for the quick response! You rock, Steven!

[Dunbaratu]

Hey together,

just tried to use the new module functionality and ran into a problem.

I tried to do something simple and wanted to switch on an engine on my vessel on the launchpad.

I did the following:

SET mainengine TO SHIP:PARTSTAGGED(mainengine).

and so far it worked, but when I tried this:

SET enginemodules TO mainengine:MODULES. (to be able to print the available modules and to decide which one i have to activate by :DOEVENT)

it Returned that the suffix MODULES either can't be used with the get operation or that no ListValue ever has such a one.

I also tried :ALLMODULES and he operations get and print...

I have to say I'm quite new to kOS, but my first attempts worked after a short time as they should.

But until now I havent been able to figure out what to Problem is with the above mentioned Problem, even under the help of all the documentation and the wiki.

Any answers are appreciated,

greetigns.

did you get the zip before or after this post was made by erendrake: http://forum.kerbalspaceprogram.com/threads/68089-0-25-kOS-Scriptable-Autopilot-System-v0-15-0-2014-11-16?p=1547229&viewfull=1#post1547229 ?

it sounds exactly like the problem that it fixed.

[Reddy]

I've been getting a strange behavior upon trying to rotate my craft using a LOCK STEERING TO statement. The rocket can only use RCS to change its attitude, and what I get instead is a lot of wiggling its engine's gimbal, thrusters firing everywhere and a very, very slow rotation. Best explained with the video:

(In case the HD version isn't available just yet: in 0:08 I'm calling a LOCK STEERING TO UP, then unlocking in 0:40, then locking to PROGRADE in 0:44.)

Any ideas what's going on?

EDIT: I have found the issue to be reprocudable on a clean 32-bit KSP 0.25.0.642 with only kOS v0.15.1 installed. You can grab the persistence file under this link, or the rocket itself here; to check it out, just open the terminal and try:

LOCK STEERING TO PROGRADE.

You could as well do RETROGRADE or UP or whatever instead.

EDIT2: Just for the record, the issue was there in the previous version of the mod (0.14.2 IIRC).

Edited November 18, 2014 by Reddy

[Joe32320]

Dumb question, but where is the archive now, when I save files from the ingame editor I can't for the life of me find that file on my system... :/

[Dunbaratu]

EDIT2: Just for the record, the issue was there in the previous version of the mod (0.14.2 IIRC).

Added as an issue on github. I guess nobody tried doing it in the hardmode where the craft has no torque power.

[Dunbaratu]

Dumb question, but where is the archive now, when I save files from the ingame editor I can't for the life of me find that file on my system... :/

If you assume that ${KSP_HOME} is the place where your KSP game is installed, it's here:

${KSP_HOME}/Ships/Scripts/

(replace "/" with "\\" if on Windows).

[Sinza]

did you get the zip before or after this post was made by erendrake: http://forum.kerbalspaceprogram.com/threads/68089-0-25-kOS-Scriptable-Autopilot-System-v0-15-0-2014-11-16?p=1547229&viewfull=1#post1547229 ?

it sounds exactly like the problem that it fixed.

Yes, i think i worked with version 0.15.1. I'll check that this evening and report than.

A video tutorial with a step by step explanation from someone whos familiar with this feature would be great to see.

[Sinza]

Ok, back again I just downloaded the latest Version of kOS but the problem still exsists.

I tried to following with a new "clean" install of KSP 32-bit.:

SET shipsparts TO SHIP:PARTS.
PRINT shipsparts.
SET mainengine TO SHIP:PARTSDUBBED("liquidEngine2").
PRINT mainengine.
SET enginemodule TO mainengine:MODULES.
PRINT enginemodule.

but it still returns the problem I reported in my first post

it Returned that the suffix MODULES either can't be used with the get operation or that no ListValue ever has such a one.

I also tried :ALLMODULES and he operations get and print...

http://forum.kerbalspaceprogram.com/threads/68089-0-25-kOS-Scriptable-Autopilot-System-v0-15-0-2014-11-16?p=1547961&viewfull=1#post1547961

[Dunbaratu]

Yes, i think i worked with version 0.15.1. I'll check that this evening and report than.

A video tutorial with a step by step explanation from someone whos familiar with this feature would be great to see.

I've just verified what the problem you reported is and I see why it happened:

https://github.com/KSP-KOS/KOS/issues/392

It should be a very quick fix but I don't know when it will get out in a release.

Edited November 18, 2014 by Steven Mading

[Dunbaratu]

Has anyone been using "part:facing" yet? It looks like it's aimed out the side of the part, which is not consistent with vessel:facing, which faces out the top of parts, by default.

I'd like to fix it so they both mean the same thing, but am afraid this could mess up other people if they have old scripts that used it. I don't think it was used much because if it was people would have reported this as a bug. It's been this way a while.

The proper thing for it to do is have part:facing changed to aim out the top of the part, so it coincides with vessel:facing. (i..e to get the facing of a docking port, it tells you which way it's dockable direction is aimed. Right now it tells you a direction out the side of the part).

[Reddy]

Added as an issue on github. I guess nobody tried doing it in the hardmode where the craft has no torque power.

Thank you. I'm willing to help in testing or whatever I could be of use in, as my space program relies on this feature Can't spare any kilogram on my reusable SSTO lifters, and with FAR and DR installed I'd have a hard time squeezing the SAS modules in the rocket while still maintaining its aerodynamic properties.

[Dr_Goddard]

It's entirely possible I am just stupid... when I launch my KOS and IR robot I can't access IR in-game controls. Editor still works.

Edit: yes, it was me being stupid. The window was appearing out of range.

Edited November 22, 2014 by Dr_Goddard

[erendrake]

New Release v0.15.2

On Github Also available on kerbalstuff and curse

You guys gave some great bug reports and we could quickly knock some of them out so there is the first part of the post v0.15 cleanup releases

Features:

* Added :PORTFACING to docking ports that should always have the correct facing for the port itself #398 

Bugfixes:

* BREAKING: Partfacing should now come out of the top rather than the side #394
* :MODULESNAMED returns something useful now #392
* array syntax bugs #387

On Github Also available on kerbalstuff and curse

Edited November 19, 2014 by erendrake

[Trewor007]

set y to Duna.
set i to ship:patches:length. print i at (5,19).
set k to 0.
if i>{
 until k=i { print SHIP:PATCHES[k-1]:body at (5,21+k).
 set destynacja to SHIP:PATCHES[k-1]:body. set k to k+1.}.
 lock throttle to 0.5. if destynacja=y{lock throttle to 0.
 set faza to 2.}.}.

Hi this is my interplanetary transfer code. The problem witch it is when i get a duna encounter i get a message saying "Argument is out of range. Parameter name index. (Cannot show kOS error location - error might realy be internal. see kOS devs.)" is this a kOS problem or bad code?

[Dunbaratu]

I'm going to fiddle with your indentation to make it easier to follow what's going on:

set y to Duna.
set i to ship:patches:length. print i at (5,19).
set k to 0.
if i>{
  until k=i {
    print SHIP:PATCHES[k-1]:body at (5,21+k).
    set destynacja to SHIP:PATCHES[k-1]:body. set k to k+1.
  }.
  lock throttle to 0.5.
  if destynacja=y{
    lock throttle to 0.
    set faza to 2.
  }.
}.

Look at what will happen on the first pass through the loop, where k = 0.

If k = 0, then getting the [k-1]'th element from the list will be getting the -1'th element. That's probably the "argument is out of range" that it's complaining about.

[Trewor007]

OK now i see it.

I have 1 more question. I set y to Duna, and when I use the " print y. " command i get body("Duna").

if i use the "print ship:patches[2]:body." i get 'body("Duna").'.

But when i type:

if ship:patches[2]:body=y {print "true".} else {print "false".}.

i get the false result, despite the fact that "set target to y." will target duna.

I'm assuming the problem is in the "set y to Duna." method. But I don't understand what is the nature of this type of error in KOS.

[Dunbaratu]

OK now i see it.

I have 1 more question. I set y to Duna, and when I use the " print y. " command i get body("Duna").

if i use the "print ship:patches[2]:body." i get 'body("Duna").'.

But when i type:

if ship:patches[2]:body=y {print "true".} else {print "false".}.

i get the false result, despite the fact that "set target to y." will target duna.

I'm assuming the problem is in the "set y to Duna." method. But I don't understand what is the nature of this type of error in KOS.

You're not doing anything wrong. You are encountering an annoying "feature" of the way kOS is wrapping things around the underlying C# api. It's complex to explain, but every time you ask kOS for a "body", it generates a new wrapper around squad's "body" and gives you that new wrapper. The equality operator is returning false because although these are the same body, they are two different wrappers around the same body and it's comparing the wrappers, not the bodies. We can probably fix that and should. Two kOS wrappers around the same SQUAD object should be treated as equal by the equality operator, but currently aren't. I'll make an issue for it.

(EDIT: The issue is here, if you want to track progress on it: https://github.com/KSP-KOS/KOS/issues/405 )

In the meantime, here's an idea that might work: It may seem daft, but give it a try:

Change this:

if ship:patches[2]:body = y

to this

if ("" + ship:patches[2]:body) = ("" + y)

It forces the two body-things to produce a string output of themselves (like the PRINT statement does), and then just compares if the two strings they produce are the same. (i.e. if there were hypothetically two different bodies both named "duna" in the solar system, it would produce a fake "true" when comparing them, for example, because it's just looking at the string names and nothing else. But since that can't occur, this is a good workaround for now.)

Unfortunately that same fix doesn't work everywhere that has this problem. For example, comparing two vessel variables to each other has the same problem, but it can't be fixed by the 'string' trick since it's perfectly legal to have two vessels with the same name that are different vessels.

Edited November 19, 2014 by Steven Mading

[Trewor007]

Steven Mading

That method its "ugly" but effective:P

BTW: on http://ksp-kos.github.io/KOS_DOC/structure/part/index.html in the discription of the :GETMODULE the link is broken the link is http://ksp-kos.github.io/KOS_DOC/structure/partmodule.html instead of http://ksp-kos.github.io/KOS_DOC/structure/partmodule/index.html

[Dunbaratu]

Steven Mading

That method its "ugly" but effective:P

BTW: on http://ksp-kos.github.io/KOS_DOC/structure/part/index.html in the discription of the :GETMODULE the link is broken the link is http://ksp-kos.github.io/KOS_DOC/structure/partmodule.html instead of http://ksp-kos.github.io/KOS_DOC/structure/partmodule/index.html

okay. noted. It will be a while before I get to it, because fiddling with the documentation requires a reboot. (The docs are using a unix system and I normally run KSP in windows. I have to do a reboot to change the docs.).