[1.3] kOS Scriptable Autopilot System v1.1.3.0

[steddyj]

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.)

I must be doing a poor job of explaining myself, because that's the second time someone has asked why I'm trying to target multiple objects. I am not.

I'm trying to target my lifter, which has no command core, after I decouple my satellite from it. The purpose is for a deployment script that will make sure it's far enough away before deploying antennas and solar panels to ensure they do not collide with the lifter. The lifter is now called "SHIPNAME Debris", along with my discharged fairings and the docking clamps back at KSC. When I try to set target to "SHIPNAME Debris" I end up targeting the first instance of an orbital with that name that appears in list targets. If I use a for loop (quoted earlier) to iterate through the output of list targets to find the one I want, I cannot simply set the target to that orbital, because set target appears to only accept a string of a valid ship name. If I use orbital:name it's just the same "SHIPNAME debris" string and gets me back to step one.

I don't see any unique values in the orbital structure, which is odd. I'm pretty sure that ksp itself uses a unique I'd code, I'm not sure why it's not exposed in the structure. My guess is because the original developer had no idea just how far this mod could go, and painted himself in a corner much in the same way as the changes you are making in .15 have shown. By requiring only the name string for setting a target, it's like trying to describe to someone which specific slice of pizza you want by saying "give me pizza" and nothing else.

Unless I'm completely missing something here, which is entirely possible.

[Trewor007]

if I read the steddyj problem right...

The debris You are targeting will be the closes on, so its model has to be loaded. knowing that I would set my "targeting" criteria to "name of the ship" and if the ship in mind is :LOADED . This will narrow the search to about 2,5km.

[Dunbaratu]

When I try to set target to "SHIPNAME Debris" I end up targeting the first instance of an orbital with that name that appears in list targets. If I use a for loop (quoted earlier) to iterate through the output of list targets to find the one I want, I cannot simply set the target to that orbital, because set target appears to only accept a string of a valid ship name. If I use orbital:name it's just the same "SHIPNAME debris" string and gets me back to step one.

You are confusing the issue by using the word "Target" which has special meanings.

It sounds like the real problem has nothing to do with whether or not you decide to set the vessel to "target", but rather it's about whether you can even get a handle on the vessel you want in the first place.

In other words you'd have the same problem if you did this:

   set thatship to vessel("SHIPNAME debris").

/

as you have when you try to do this:

   set target to vessel("SHIPNAME debris").

The fact that's its the magic "TARGET" ship has nothing to do with the problem. It's the inability to tell the Vessel constructor function which "SHIPNAME debris" you meant.

While I understand that it's annoying I still put the primary blame on SQUAD, because the ridiculous rule that you cannot rename a debris vessel was their idea, and it's the main reason you're having the problem. If you could just rename the target vessel the problem would go away.

In the meantime, you could try LIST TARGETS IN MyTargetList, and then see if you can go through them and find the one you want based on some known criterion like part count, or a known command core, or something like that.

[kcs123]

I'm just started to look at this mod, still need to learn lot about it, but I got suggestion if it is not already covered for future update: help button with list of reserved words and built in variables.

Small GUI that could read variable names when you right click on some part of vesel could be nice too, but it is not of highest importance.

Simple window with list of commands/variables that could be marked and copy-pasted to main console window will be of great help to noobs of mod.

Good work on this mod, btw. I misinterpreted this mod with Kerbin Shuttle Orbiter System (KSOS vs kOS) so it didn't bring my attention earlier. I see lot of potential with this mod, once I learn basics.

[Dunbaratu]

I'm just started to look at this mod, still need to learn lot about it, but I got suggestion if it is not already covered for future update: help button with list of reserved words and built in variables.

Small GUI that could read variable names when you right click on some part of vesel could be nice too, but it is not of highest importance.

Simple window with list of commands/variables that could be marked and copy-pasted to main console window will be of great help to noobs of mod.

Good work on this mod, btw. I misinterpreted this mod with Kerbin Shuttle Orbiter System (KSOS vs kOS) so it didn't bring my attention earlier. I see lot of potential with this mod, once I learn basics.

In the past the mod was begun in a sort of ad-hoc way and when others took it over and helped further its development after the original author left, we've all been thinking of how to make the sorts of things you're referring to better.

It's not quite there yet, but there's the glimmer of an inkling in recent refactors of the code to make the internals more self-aware in a fully "reflective" way, such that automatic generation of the information you're talking about should become possible some day. Having just gone through all the docs in prep for a v0.15 release, I can say that doing it all manually by hand is no way to do it. It's better if some of it can be autogenerated with reflection techniques, and that would also allow us to think about automatic help techniques too.

In the meantime, ask away here. Lots of people give helpful advice to the new kOS user.

And welcome to kOS.

[kcs123]

With large amount of mods aront this game and goal for this mod to blend in between all other mods, "reflective" support is definitely better way to handle things.

I still need to read trough all documentation before I start to asks questions, I don't wont to bother you with suff that was answered before.

I will probably ask more when I start to write scripts, but for now I would like to know if it is possible to accomplish following:

- I want to write script that will have to move some IR pistons to certain position and turn off IR parts. Currently if you assign AG to move IR parts to center, they keep consuming electricity when they come to desired postion. How that script will look like is not of highest importance at the moment.

- I want to assign in some action group to do stuff:

1) activate kOS console if it is in off state

2) Load premade script in console and execute it

3) after script is finished turn off kOS console

All that should be executed in background, user does not have to be aware that everthing is executed trough scripts.

Next demand is a bit tricky, but I think that could be done. Script have to be aware of state(position) of IR pistons and execute movement in one direction or another depending on previous state.

What I want to accomplish with this is that I have some landing gears on IR pistons and I want to move them in one direction or another whenever "gear" action group is toggled trough "G" key or with mose on GUI. I think that it will be good small project for me to start with kOS, not too complicated but it will still offer some chalange to learn basic scripting with kOS.

[erendrake]

NEW RELEASE v0.15.0

We have a huge new release with fun toys for you all to play with.

https://github.com/KSP-KOS/KOS/releases/tag/v0.15.0

NEW FEATURES:

Please follow the links to see the full information on the new features.

* Added new kOS GUI panel to the KSP Applauncher system. With this you can alter config values, and open/close terminals from one common panel. Just click the little kOS logo button in either the editors (VAB/SPH) or in flight view.

* Added pilot input to flight controls which lets you read/write the users control state, you can use this to set the exit behavior for the mainthrottle.

* Several suffixes are now methods that you can call with arguments.

* eg before to add to a list it was SET LIST:ADD TO "FOO". Now it would be LIST:ADD("FOO").

* Suffix methods that perform an action do not need to be assigned to anything. No more having to say SET DUMMY TO MYLIST:CLEAR. You can now just say MYLIST:CLEAR. like it was a statement.

* Added suffixes to OBT for walking orbit conic patches

* ORB:HASNEXTPATCH - A boolean that shows the presence of a future patch

* ORB:NEXTPATCH - The next OBT patch

* Added better techniques for selecting the Part you want from a Vessel:

* Ability to give any part any name you like with the new nametag feature.

* Directly querying a vessel for parts, searching for nametags, or part names or part titles.

* SHIP: PARTSDUBBED(string)

* SHIP: PARTSNAMED(string)

* SHIP: PARTSTAGGED(string)

* SHIP: PARTSTITLED(string)

* SHIP: PARTSINGROUP(string)

* SHIP: MODULESNAMED(string)

* Walking the parts Tree:

* PART: CHILDREN - A ListValue of parts that are descendant from the current part

* PART: PARENT - A PART that is the ancestor of the current part

* PART: HASPARENT - A boolean that shows the presence of a Parent PART

* SHIP: ROOTPART - The first part of a ship. The start of the tree of parts. identical to SHIP: PARTS[0].

* SET MyList TO SHIP: PARTS. now does the same thing as LIST PARTS IN MyList.

* A new system lets you access the PartModules that the stock game and modders put on the various parts. Through this, you now have the ability to manipulate a lot of the things that are on the rightclick menus of parts:

* PART Suffixes:

* GETMODULE(string)

* ALLMODULES.

* PartModule Suffixes:

* GETFIELD(field_name) - read a value from a rightclick menu

* SETFIELD(field_name, new value) - change a value on a rightclick menu, if it would normally be adjustable via a tweakable control.

* DOACTION(name_of_action_) - cause one of the actions that would normally be available to action groups *even if it hasn't been assigned to an action group*.

* DOEVENT(event_name) - "presses a button" on the rightclick part menu.

* Several others..

* Lists are now saner to work with with no longer needing to use weird side effects to get things done, now that there's proper methods available:

* :ADD has changed:

* Old Way: SET MyList:ADD TO NewVal.

* New Way: MyList:ADD(NewVal).

* :REMOVE has changed:

* Old Way: SET MyList:REMOVE TO indexnumber.

* New Way: MyList:REMOVE(indexnumber).

* :CLEAR has changed:

* Old Way: SET Dummy to MyList:CLEAR.

* New Way: MyList:CLEAR().

* Added ENGINE:AVAILABLETHRUST suffix. A value that respects the thrust limiter

* Added SHIP:AVAILABLETHRUST suffix. A sum of all of the ship's thrust that respects thrust limiters

* Added a new experimental COMPILE command, for making smaller executable-only programs to put on your probes without punishing you for writing legible code with comments and indenting.

* Filename convention changes:

* Commands that deal with filenames will now allow any arbitrary expressions as the filename, except for the RUN command.

* *Exception*: The above does NOT apply to the ``

[code single]RUN

`` command. The run command requires that the filenames are known at compile time, and it cannot allow arbitrary expressions evaluated later at runtime.

* Program files are now called *.ks instead of *.txt. When you first run the new version, it will give you an option to rename your files to the new name for you as they are moved to the new location.

* Although the default script filenames use *.ks, you can override this and explicitly mention filename extensions in all the filename commands. What you can't do is have filenames with no extensions.

* Added support for CKAN

* Added config file so kOS will now show up in Automatic Version Checker (AVC)

CHANGES BREAKING OLD SCRIPTS:

* BREAKING: .txt files are now .ks files: The new assumed default file extension for files used by kOS is *.ks rather than *.txt. This may confuse old IDE's, or your computer's assumed file associations.

* BREAKING: VesselName: Removed previously deprecated term "VESSELNAME", use "SHIPNAME"

* BREAKING: SHIP:ORB: PATCHES: Moved SHIP:ORB: PATCHES to SHIP: PATCHES and it now contains all orbit patches

* BREAKING: Lists: New syntax for using :ADD, and :REMOVE suffixes for lists requires old code to be altered. See features above for the new way.

* WARNING: Bundled ModuleManager: Because kOS now needs ModuleManager, and ModuleMangaer complains about being run on Windows 64bit, you now see a new warning message if you run kOS on Windows 64bit, but the message is ignorable and kOS still runs.

* BREAKING: identifiers as filenames: If you use the same name for a filename as the name of a variable, in a file command such as COPY, DELETE, etc, then kOS will no longer use the variable's name as the filename but will now use the variable's contents as the filename.

BUG FIXES:

* PartValue: POSITION not using ship-relative coords

* Boot file name is case sensitive

* Engine reports maxthrust on :ISP suffix

* LIST VOLUMES IN <list> makes an empty list.

* Parser doesn't understand THING[num]:THING[NUM] or thing[index]:suffix(arg)

* ship:obt: patches seems to be missing some of the patches (Note: in addition to fixing it, the patches list was moved to just ship: patches, which makes more sense).

* Compiler should throw exception on trying to put a WAIT in a trigger.

Edited November 17, 2014 by erendrake

[Cairan]

Wooohooo! And now on to adding some nice features in the next release ...

[Trewor007]

i see that the new KOS does not like when I put no space between commands like this:

set x to 0.set y to 0.wait 1.

It says something about a unexpected token. that's a bug or something intentional?

[erendrake]

i see that the new KOS does not like when I put no space between commands like this:

set x to 0.set y to 0.wait 1.

It says something about a unexpected token. that's a bug or something intentional?

dont do that. its an error

[Joe32320]

Awesome release guys! Thanks for all the hard work

[Trewor007]

dont do that. its an error

but my error or KOS? i also noticed it not always complaining about that despite the fact 90% of my code is build that way(disk space saving)

[steddyj]

Hooray for the new version, if I knew that .15 was so close to being released I wouldn't have bugged you so much over the past few days.

However, I have something new to bug you for.

I'm not sure if this is intentional, but I cannot seem to use the new list operators with lists generated by the list parts command. New lists created with list() work fine, as does say list targets. If I do something like list parts in foo, I get an error using the operators like foo:length.

An attempt was made to get a suffix called:

LENGTH

from an object of type:

ListValue

when that object does not have that suffix usable in that way

....

Since I can't copy from the terminal, please excuse any typos. I get the same error when trying to manipulate lists from other part functions like GetPartsTagged(). Are parts lists a special type of list? I'm trying to check the number of fields returned for error-checking in my script.

[Drew Kerman]

Wooohooo! And now on to adding some nice features in the next release ...

Nay, more bug fixes! Ok just one

[Cairan]

Nay, more bug fixes! Ok just one

Actually I am writing that because I am right now working on adding some features at the moment, but it was a certainty that it was not going to be released with this update. However credit must be given to the people actually doing the hard work right now, so far I've been more of a bugger ... as in "finding bugs and creating some of my own"

Thanks for the update.

[erendrake]

Hooray for the new version, if I knew that .15 was so close to being released I wouldn't have bugged you so much over the past few days.

However, I have something new to bug you for.

I'm not sure if this is intentional, but I cannot seem to use the new list operators with lists generated by the list parts command. New lists created with list() work fine, as does say list targets. If I do something like list parts in foo, I get an error using the operators like foo:length.

Since I can't copy from the terminal, please excuse any typos. I get the same error when trying to manipulate lists from other part functions like GetPartsTagged(). Are parts lists a special type of list? I'm trying to check the number of fields returned for error-checking in my script.

That is interesting, ill have a look. the next few weeks will see a drop in my code output, the time i do have i plan on using to fix bugs.

Update: new github issue https://github.com/KSP-KOS/KOS/issues/382

Edited November 17, 2014 by erendrake

[SnappingTurtle]

Thanks for the update. Doaction and doevent alone should go a long way to making kOS scripts more compatible with mods.

[Trewor007]

I think there might be problem with setting IPU thou the App Control Panel, when i wanted to rise it I managed to delete the number but i can't type in a new value it stays on 50 and its grey every time i click on it. changing it with the console works.

[Cairan]

I think there might be problem with setting IPU thou the App Control Panel, when i wanted to rise it I managed to delete the number but i can't type in a new value it stays on 50 and its grey every time i click on it. changing it with the console works.

I confirm this issue.

[ouch]

Found what looks to be a bug with lists, here is the code:

clearscreen.
list targets.
list targets in tar.
set arrows to list().
set x to 0.

for t in tar
{
    arrows:add(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]:vec to v(0,0,0). //(t:position - ship:position).
        set x to x + 1.
    }.
    set x to 0.
}.
for arrow in arrows
{
    set arrow to "".
}.
arrows:clear().

The set arrows[x]:vec to v(0,0,0). fails saying that "values of type system.int32 cannot have suffixes"...

However:

    set tester to VECDRAWARGS(v(0,0,0), target:position-ship:position, rgb(1,0,0), target:name, 1.0, true).
    set tester:vec to v(0,0,0).

Works, so I assume the problem has to do with lists.

also code stored on a ship are not being saved. The file has size 0 after loading a saved game.

Edited November 17, 2014 by ouch

[Laie]

I've got a problem where an asteroid changed its orbit without apparent reason. Which would have gone unnoticed if it wasn't for an asteroid redirect mission that is now going nowhere.

I do have savegames from before and after, and hope that I can change the current savegame to put the asteroid back to where it belongs. Would it be possible to use kOS in the old savegame to predict the asteroids' position at the time of the current save, in terms that are suitable to be put into the savegame?

Question originally posted here: http://forum.kerbalspaceprogram.com/threads/100378-How-to-restore-a-messed-up-orbit

Any input would be appreciated.

[Dunbaratu]

        set arrows[x]:vec to v(0,0,0). //(t:position - ship:position).

Can you try splitting that out into these two lines and see if that makes the bug go away?

        set arr to arrows[x].
        set arr:vec to v(0,0,0). //(t:position - ship:position).

If that makes it go away, then it tells me the problem is entirely in the syntax parsing.

If that does not make it go away, then it tells me the problem is elsewhere in the system.

also code stored on a ship are not being saved. The file has size 0 after loading a saved game.

Oh crud. I just had an idea. Are you talking about code that was saved on the ship while running an earlier version of kOS and now the newer version of kOS says it has zero size after the update? Or is it code you added to the craft after the update was already installed?

[ouch]

ok so the code now looks like this:

clearscreen.
list targets.
list targets in tar.
set arrows to list().
set x to 0.

for t in tar
{
    arrows:add(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 arr to arrows[x].
        set arr:vec to (t:position - ship:position).
        set arrows[x] to arr.
        //set arrows[x]:vec to (t:position - ship:position).
        set x to x + 1.
    }.
    set x to 0.
}.
for arrow in arrows
{
    set arrow to "".
}.
arrows:clear().

I'm getting a new error at "set x to x + 1." it's pointing to the plus sign and it says that it can't add VectorRenderer to int32... I don't even know what it's talking about, it's just a simple "x++;" equivalent... lol, I think you guys broke KOS's brain...

Oh crud. I just had an idea. Are you talking about code that was saved on the ship while running an earlier version of kOS and now the newer version of kOS says it has zero size after the update? Or is it code you added to the craft after the update was already installed?

both sadly... my existing pre patch drone died after I tried running my code on it but the file was blank... So I went to the VAB and got fresh one. And after saving and reloading, that too was blank.

also a new suffix problem:

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

says values of double can't have suffixes.

on the plus side it my drone seems to know exactly where stuff is now once I strip out all the code with errors.

Edited November 17, 2014 by ouch

[Dunbaratu]

I'm getting a new error at "set x to x + 1." it's pointing to the plus sign and it says that it can't add VectorRenderer to int32... I don't even know what it's talking about, it's just a simple "x++;" equivalent... lol, I think you guys broke KOS's brain...

Actually that's quite revealing.

It seems to be thinking that 'x' is of type VectorRenderer now. Which means that here:

set arrows[x] to arr.

It did something wrong, and put 'arr' into the 'x' instead of into the 'arrows[x]'. I suspect as I look into it I'm going to find it's a problem with any generic "set somelist[idx] to anything' is going to end up trying to set the 'anything' into idx instead of into somelist because it mangled how it used the stack.

In the meantime to get code working, try building the arrows list from scratch each loop instead of overwriting the values in-place and see if that gets you what you need for now. (i.e. just before the "for t in tar" loop, do arrows:clear(), and then inside the for loop do arrows:add( stuff ) instead of arrows[x] = stuff.

[rdwulfe]

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.