[KSP 1.12.x] kOS v1.4.0.0: kOS Scriptable Autopilot System

[jbakes]

I can only get my log to keep running if its outside my ascent loop but it either runs the entire time of flight and never gets to my ascent profile script or it only runs once if I put it after the script. Is it possible to have a script run within my script like run the log script within my ascent script so it can go on to the rest of the code?

8 minutes ago, kcs123 said:

You need to wait certain interval before writting again. It all depends how your script is configured to execute. For example, if you set it up in endless loop that can be terminated only by CTRL+C or changing some variable on action group toggle. Or, after you have set proper heading of your craft and you just wait for craft to get at certain altitude you may use following structure:

 

I usualy combine several functions and triggers (or events if it is more understandeble for your mindset) with one endless loop for main programme. That endless loop is on purpose, as I don't want my main code to end, just to respond on different input from either, GUI or some action group. Or sometimes just responds on craft state, if it need to be staged for example.

It all depends of what kind of script you write and how you want for your craft to behave. It is hard to give you some piece of code that always need to be exacuted exactly in the same manner all times. Above is just rude, most simple example to ge tyou started.

That didn't work for me every time my ascent loop runs it cuts the cuts the log loop off. Can I run two scripts at once? Basically run a log script inside my ascent script? That way the log loop wont get skipped over the ascent loop.

Edited January 8, 2018 by jbakes

[scimas]

You don't need two scripts, you need to rearrange your script so that a single loop executes both the ascent code and the logging code. I don't think anyone can help you more than that without actually looking through your code.

9 hours ago, jbakes said:

I'm new to KOS and programming in general

Your problem is more about programming concepts than about kOS. I suggest learning the very basics of programming in a real world language, perhaps python, and then coming back to your script. There are a lot more resources freely available online to learn something like python compared to what advice KSP players can give you here on forums on specific problems. Once you have a good understanding of conditionals (if...else) and loops (for, while), go back to your script and kOS documentation and I'm sure you will be able to work through your problem. Perhaps search youtube for 'ksp kos', there are some excellent videos, playlists that can get you started on the right path to correcting your script.

[kcs123]

I missed info:

18 hours ago, jbakes said:

I'm new to KOS and programming in general

 

kOS documentation is reasonably good for anyone who have already learned some basic stuff regarding programming, like variable types, how to execute code in loops, various kind of loops, custom functions, triggers, handfull of keywords you need to learn to get started, etc. It is more than enough for someone that is not absolute begginer, because kOS shared various similarities with other programming languages. If you are familiar with at least one programming language, you will recognize those similarities in kOS too.

There is bunch of basic tutorials for almost any programming language you choose to learn, but most of them lack very important part: "it is not fun enough" to keep any newcomer interested to learn more about it. Those mostly deals with basic input/output stuff and simple sorting algorithm and similar. Have to admit that those kind of thing can be boring to learn.

On the other hand, learning first coding steps in kOS can be something fun to do, due to most probable spectacular craft explosions and fast feedback if your code work properly or not. kOS documentation have quick start tutorial that gives some basic stuff, but again it give bare minimum of info that might not be enough for absoulute beginner.
Learning most common keywords for any programming language and syntax how to use it properly is more/less easy to learn. What is difficult to explain (not necessary difficult to learn) is programm logic (algorithm), or more like "certain way of thinking" that can be easy converted to code for any programming language, not only for kOS.

This is area where kOS can help a lot, at least in my opinion. To get more into that "certain way of thinking", thinking "out of the box" while having fun at the same time. Stuff you learn playing with kOS you can easy apply to other programming language, once you are able to recognize similarities with other languages.

I was thinking to wrote some tutorial for beginners for some time, but never found enough time to do it and publish it. To cover some stuff that is missing or not covered deep enough in documentation for absolute beginners. To explain why some part of code is executed only once, while other can be executed multiple times, why to use loops and when to use loops, condition checkings for multiple branches of code. All that in comparison with some other programming languages and parts of kOS where I stumbled uppon while learning kOS.

Don't know should I post stuff like that here or crete some other thread or should be prepared for easier merging into existing documentation.

[Drew Kerman]

@jbakes feel free to use my logger as an example or basis for your own  - or just rip it straight off whatever, licensing is nonexistent. This is an example of the data it spits out and this is an example of me graphing up some analysis from that data and other telemetry data sets

Edited January 10, 2018 by Drew Kerman

[jbakes]

34 minutes ago, Drew Kerman said:

@jbakes feel free to use my logger as an example or basis for your own  - or just rip it straight off whatever, licensing is nonexistent. This is an example of the data it spits out and this is an example of me graphing up some analysis from that data and other telemetry data sets

Wow thank you!!! I've been trying to write a script that can at least log pitch and position. I can't adjust my ascent profile unless I know whats going on. 

[Drew Kerman]

22 minutes ago, jbakes said:

Wow thank you!!! I've been trying to write a script that can at least log pitch and position. I can't adjust my ascent profile unless I know whats going on. 

yup, I have been using the data to iterate on my ascent also, works good in conjunction with video capture of the ascent as well. I think the next launch will be the final culmination!

Edited January 10, 2018 by Drew Kerman

[jbakes]

23 hours ago, jbakes said:

 

 

22 hours ago, Drew Kerman said:

yup, I have been using the data to iterate on my ascent also, works good in conjunction with video capture of the ascent as well. I think the next launch will be the final culmination!

I'm trying to run your logger or at least parts of it and things like position and pitch aren't working. 

Edited January 11, 2018 by jbakes

[Drew Kerman]

1 hour ago, jbakes said:

I'm trying to run your logger or at least parts of it and things like position and pitch aren't working. 

Oh, right I pulled out some stuff into helpFunc.ks so it'd be more accessible across a range of my projects. If you have any troubles, post an issue here with any code so we're not cluttering up the thread

[APlayer]

Is there a possibility, even if it requires abusing something, to plot raw image data/individual pixels in a kOS GUI, and perhaps even get mouse hover/click coordinates? I am looking for such a thing to create graphs to help visualize and choose trajectories and/or flight plans.

[kcs123]

1 hour ago, APlayer said:

Is there a possibility, even if it requires abusing something, to plot raw image data/individual pixels in a kOS GUI, and perhaps even get mouse hover/click coordinates? I am looking for such a thing to create graphs to help visualize and choose trajectories and/or flight plans.

I'm not sure about custom pixel draws, but some other stuff might be possible. Anyhow, worth to check GUI Style documentation about it.

[APlayer]

19 hours ago, kcs123 said:

I'm not sure about custom pixel draws, but some other stuff might be possible. Anyhow, worth to check GUI Style documentation about it.

From this documentation, I derive, I can at most create a grid of buttons with colored backgrounds and this way plot an image and record click coordinates? I guess this is possible, if the large amount of buttons does not break something. Is there no better way to do this, though?

If so, is perhaps some sort of JavaScript-style Canvas GUI element planned for the future of kOS?

[kcs123]

@Steven Mading or some of other devs should be able to tell more, I don't know what is planed next, I doubt that anything is planed for some kind of drawing. Probably it would be easier to enable some kind of custom drawing on canvas, rather then implement anything from Java.

Don't know would be feasible to do drawinng with some kind of button grids, I'm afraid that having too many GUI buttons will cause FPS slowdown issues. Haven't tested latest kOS version after optimization, but before that having too rich GUI was caused slowdowns. More noticable imediately after switching scene, it was causing KSP clock to change color from green to yelow for couple of sec. New kOS version have noticable improvement, there is no more slowdowns on scene switching, but haven't tested it enough to see other performance impact.

Too much of slowdowns can have impact on script behaviour, especialy time sensitive pieces of code that can have too much time difference between two physical ticks.

We already have options to draw vectors on screen, I guess it would be possible to allow draw inside some kind of canvas box widged, but I can't tell much about unity game engine, what are possible options.

[mox313]

Hi guys,  I just installed this and I'm having a weird problem. I'm going through the tutorial, and I've only managed to get the COPYPATH bit... but as soon as I type that command, not only does it not do anything, the terminal then ignores everything I type after that. I have to toggle the power on the cpu just to get it to acept input again, but then as soon as try to COPYPATH, it happens all over again...

At first I thought it was a mod conflict, so I installed kOS on my unmodded install, and it happened again.

Is this a problem? Or am I dumb as hell and not doing something right?

https://app.box.com/s/lcnc9ff9pu8d9l5s1mgjdln2ib16u6yn

 

[Dunbaratu]

8 hours ago, kcs123 said:

@Steven Mading or some of other devs should be able to tell more, I don't know what is planed next, I doubt that anything is planed for some kind of drawing. Probably it would be easier to enable some kind of custom drawing on canvas, rather then implement anything from Java.

Don't know would be feasible to do drawinng with some kind of button grids, I'm afraid that having too many GUI buttons will cause FPS slowdown issues. Haven't tested latest kOS version after optimization, but before that having too rich GUI was caused slowdowns. More noticable imediately after switching scene, it was causing KSP clock to change color from green to yelow for couple of sec. New kOS version have noticable improvement, there is no more slowdowns on scene switching, but haven't tested it enough to see other performance impact.

Too much of slowdowns can have impact on script behaviour, especialy time sensitive pieces of code that can have too much time difference between two physical ticks.

We already have options to draw vectors on screen, I guess it would be possible to allow draw inside some kind of canvas box widged, but I can't tell much about unity game engine, what are possible options.

I've been trying to wrestle with Unity's docs trying to figure out how to do the extremely simple task of drawing primitives directly onto a texture, so I can then paint that texture onto something in IMGUI, or alternatively, the simple task of drawing primitives into IMGUI directly, or alternatively, drawing primitives onto the newer UI canvas system.  NONE of these 3 techniques are well documented, and the Unity docs keep trying to actively fight against people doing these things at runtime from C# code (rather than making pre-fab things in the game editor tool, which are no good for me since kOS *MUST* do these things at runtime without knowing ahead of time what is in people's scripts.)

As near as I can tell to draw into a Texturee2D, I have to make a Canvas object, then point a Camera object at it, and set the layer mask such that this camera will ONLY see things on the Canvas object and none of the other things in the game.  My roadblock is that all of the possible 32 bits of layer mask are already dedicated to a meaning in KSP - there's none available for me that don't already mean something.  This means (I think) that I need to be very careful to place the canvas and the camera at coordinates that won't see any of the other objects on whatever layer I choose, since all layers are used for *something*.  But there's no public information about what coordinates other elements are already using.  (If I point the camera at (0,0,0), facing (0,1,0), and assign it the UI layermask number, will that end up seeing, say, other UI button elements the game uses?  I have no idea because I don't know where the game draws them in 3-D coords.)

 

 

[Dunbaratu]

26 minutes ago, mox313 said:

Hi guys,  I just installed this and I'm having a weird problem. I'm going through the tutorial, and I've only managed to get the COPYPATH bit... but as soon as I type that command, not only does it not do anything, the terminal then ignores everything I type after that. I have to toggle the power on the cpu just to get it to acept input again, but then as soon as try to COPYPATH, it happens all over again...

At first I thought it was a mod conflict, so I installed kOS on my unmodded install, and it happened again.

Is this a problem? Or am I dumb as hell and not doing something right?

https://app.box.com/s/lcnc9ff9pu8d9l5s1mgjdln2ib16u6yn

 

Your command is missing a quote mark.  That missing quote mark means that instead of doing this:

COPYPATH( openquote ..stuff.. closequote , openquote ..stuff.. closequote ).

Like you meant, you are doing this instead:

COPYPATH( ..stuff..  openquote, closequote ..stuff.. openquote ).

So at the end of that line, you began a string, who's contents so far are a ')' character, a ''.', and an end-of-line return char.  This string isn't closed yet so the system hasn't tried compiling this line of text yet.  Until you close the string with a close quote, the system doesn't see the syntax error because it doesn't think you're done typing it.

(the problem is because it's legal for you to embed return characters inside quotes like so:

PRINT "

---------

hello

----------".

and that works.  So having mismatched quotes in a command in the interpreter doesn't get caught right away because it just means the string isn't done yet so the command isn't finished being typed.

 

[mox313]

thanks.. I suspected I was dumb as hell...

[APlayer]

7 hours ago, Steven Mading said:

I've been trying to wrestle with Unity's docs trying to figure out how to do the extremely simple task of drawing primitives directly onto a texture,

Don't worry! :-) I will meanwhile try the button grid workaround, and see what "resolution" I may achieve before things slow down too much. And if that doesn't work I will simply skip this part - the already existing GUI offers alternatives to images and plots, even if they are not as visually appealing.

Also, from totally zero knowledge on that matter - would it be possible to create a canvas from some element's background image by editing and reloading the image file/object/whatever during runtime?

[kcs123]

On 17. 01. 2018. at 6:02 AM, Steven Mading said:

I've been trying to wrestle with Unity's docs trying to figure out how to do the extremely simple task of drawing primitives directly onto a texture, so I can then paint that texture onto something in IMGUI, or alternatively, the simple task of drawing primitives into IMGUI directly, or alternatively, drawing primitives onto the newer UI canvas system.  NONE of these 3 techniques are well documented, and the Unity docs keep trying to actively fight against people doing these things at runtime from C# code (rather than making pre-fab things in the game editor tool, which are no good for me since kOS *MUST* do these things at runtime without knowing ahead of time what is in people's scripts.)

Well known unknown feeling to me when you have to do something that should be simple but game engine or game build with it does not allow you. kOS is quite good for me even without that feature. However I encountered something else in attempt to develop docking script.

Is it possible to find out what is targeted in reliable way ? In attempt to find relative velocity with target one command work properly when whole vessel is targeted, while other works when docking port is targeted. Example:

lock RelativeVel to ship:velocity:orbit - target:velocity:orbit. // produce error when docking port is target
lock RelativeVel to ship:velocity:orbit - target:ship:velocity:orbit. // error when whole vessel is target

I could do it by checking target name, or tag name on part, but it would require to change script for each created craft, I would rather want to create something more universal.
Also, when distance between crafts change too much, it seems that it also produce error because dockport as target is changed to something else. Need to do more tests to figure out what exactly become broken in code from my side.

[ElWanderer]

52 minutes ago, kcs123 said:

Is it possible to find out what is targeted in reliable way ?

Does TARGET:TYPENAME help?

[kcs123]

2 hours ago, ElWanderer said:

Does TARGET:TYPENAME help?

Thanks for a hint, it pointed me to right part of documentation. Even better command for thing that I looking for is this one:

TARGET:ISTYPE("Vessel")

Have to check out what I would get when I target various docking ports. I'm using stock porta as well as welding ports from USI konstruction, have yet to see how it will perform.

 

[APlayer]

Another problem I encountered is figuring out the aerodynamic properties of a vessel. I have not found any direct command in the documentation which would yield, say, the drag constant given velocity, altitude and atmosphere for a prograde motion. The next step was trying to record it from the stock aerodynamic GUI as a function of Mach number, and from that function calculate it on my own, but I failed at that too, because there is no way to get the temperature (required for Mach number calculation) at a given altitude in a given atmosphere. So I am forced to record both, the drag constant as a function of Mach number and the temperature as a function of altitude in order to calculate basic aerodynamic properties of a vessel. Is there any efficient workaround to this problem? Or am I missing some actually existing command?

[kcs123]

1 hour ago, APlayer said:

Another problem I encountered is figuring out the aerodynamic properties of a vessel. I have not found any direct command in the documentation which would yield, say, the drag constant given velocity, altitude and atmosphere for a prograde motion. The next step was trying to record it from the stock aerodynamic GUI as a function of Mach number, and from that function calculate it on my own, but I failed at that too, because there is no way to get the temperature (required for Mach number calculation) at a given altitude in a given atmosphere. So I am forced to record both, the drag constant as a function of Mach number and the temperature as a function of altitude in order to calculate basic aerodynamic properties of a vessel. Is there any efficient workaround to this problem? Or am I missing some actually existing command?

I don't think that there is better way than you are already doing. Limitations are what is exposed in KSP API for kOS to be able to use at first place. And another limit is what kOS is able to show you from game world to user that is simple to use further.
I recommend to use temperature as function of pressure, rather than altitude as it is more universal for various celestial bodies that have atmosphere.  You can get that info from body:atmosphere structure, if celestial body have atmosphere.

I have encountered different issue, though. It is either, some bug involved with converting between SOI coordinates and game universe raw coordinates or I'm failing to understand something. Or both.
Anyhow, I'm using this piece of code to draw vectors on screen, it seems to be proper, based on how craft is created in VAB and how docking ports were placed on craft.

Spoiler

function DirShow{
    set V1 to SHIP:FACING:VECTOR:NORMALIZED.
    set V2 to SHIP:FACING:UPVECTOR:NORMALIZED.

    // two vectors for current ship
    set ShipArrowF to VECDRAW(
        V(0,0,0), // poriginal point to start draw V(0,0,0) is center of ship or part
        35 * V1, //V(10,10,10), // length of vector or pointing to
        RGB(1,0,0), // color
        "Ship Fwd", // label
        1.0, // scale
        true, // showing
        0.2 // width of line
    ).

    set ShipArrowUp to VECDRAW(
        V(0,0,0),
        15 * V2, //V(10,10,10), // length of vector or pointing to
        RGB(0,1,0), // color
        "Ship Up", // label
        1.0, // scale
        true, // showing
        0.2 // width of line
    ).

   // safety check if ship have target to ensure that script does not throw error
   if HASTARGET {
        // need to check target type to use apropriate commands for drawning
        if TARGET:ISTYPE("Vessel") {
            // ship vectors type
            set VT1 to TARGET:FACING:FOREVECTOR:NORMALIZED.
            set VT2 to TARGET:FACING:UPVECTOR:NORMALIZED.
       
        } else {
            // in case of dock ports, PORTFACING is necessary
            set VT1 to TARGET:PORTFACING:FOREVECTOR:NORMALIZED.
            set VT2 to TARGET:PORTFACING:UPVECTOR:NORMALIZED.
        }.
    
        set TargetArrowF to VECDRAW(
            TARGET:POSITION, // point of origin to draw
            35 * VT1, // length of vector
            RGB(1,0,0), // color
            "Target Fwd", // label
            1.0, // scale
            true, // showing
            0.2 // width of line
        ).
    
        set TargetArrowUp to VECDRAW(
            TARGET:POSITION, // point of origin to draw
            15 * VT2, // length of vector
            RGB(0,1,0), // color
            "Target Up", // label
            1.0, // scale
            true, // showing
            0.2 // width of line
        ).
        
    } else {
        // deleting target lines when ship no longer have target
        set TargetArrowF to VECDRAW(
            V(0,0,0), // point of origin to draw
            V(0,0,0), // length of vector
            RGB(1,0,0), // color
            "Target Fwd", // label
            1.0, // scale
            false, // showing
            0.2 // width of line
        ).
    
        set TargetArrowUp to VECDRAW(
            V(0,0,0), // point of origin to draw
            V(0,0,0), // length of vector
            RGB(0,1,0), // color
            "Target Up", // label
            1.0, // scale
            false, // showing
            0.2 // width of line
        ).
    }.
    
}.

I'm using following command to steer craft in oposite direction of targeted dock port:

lock steering to (-1) * TARGET:PORTFACING:FOREVECTOR:NORMALIZED.

It seems to work properly at first, but when you draw vectors on screen it is noticable that roll is not proper. I have modified "lib_navball.ks" file from kOS library available on github, to be able to get roll angle on targeted docking port. New roll_for() function looks like this:

Spoiler

function roll_for {
  parameter ves.
 
  if ves:ISTYPE("Vessel") {
    // this is OK for ship or if target is Vessel
    if vang(ship:facing:vector,ship:up:vector) < 0.2 { //this is the dead zone for roll when the ship is vertical
        return 0.
    } else {
        local raw is vang(vxcl(ship:facing:vector,ship:up:vector), ves:facing:starvector).
        if vang(ves:up:vector, ves:facing:topvector) > 90 {
        if raw > 90 {
            return 270 - raw.
        } else {
            return -90 - raw.
        }
        } else {
            return raw - 90.
        }
    }
  } else {
  // new piece of code in cases that "ves" is docking port on ship
  if vang(ship:facing:vector,ship:up:vector) < 0.2 { //this is the dead zone for roll when the ship is vertical
        return 0.
    } else {
        local raw is vang(vxcl(ship:facing:vector,ship:up:vector), ves:PORTFACING:starvector).
        if vang(ves:PORTFACING:upvector, ves:PORTFACING:topvector) > 90 {
        if raw > 90 {
            return 270 - raw.
        } else {
            return -90 - raw.
        }
        } else {
            return raw - 90.
        }
    }
  }.
}.

Following picture shows issue:

Funny thing is that roll angle changes, depending on craft position in orbit around celestial body and around sun. Sometimes roll is almost exact, sometimes difference is even more.
I'm able to find out that roll angle difference, but I can't figure out how add only roll to existing direction, to counterpart this issue. Whenever I try to add R(0,0,RelativeRoll) to direction I also got pitch and yaw too, and that is not desired.

I tried using "*" and "+" to add rolling to already set direction, but nothing that I could think of worked:

lock OpositeDir to (-1) * TARGET:PORTFACING:FOREVECTOR:NORMALIZED.
lock MyDir to OpositeDir * R(0,0, -1 * RelativeRoll).

lock steering to MyDir.

Is it possible to add only desired roll to existing direction somehow. Maybe with quanterions or something ? Or it is just limit of KSP and conversion between unity game raw coordinates and SOI/local navball ship coordinates.

 

Regardless, kOS was of huge help in building space station with limited resources and only Lvl 2 of VAB/launchpad. I get two parts close enough with kOS steering and then switched to manual steer, to correct roll issue, just before docking. Gallery shows that manual steering and whole space station with all pieces welded together.

[pellinor]

59 minutes ago, kcs123 said:

I'm using following command to steer craft in oposite direction of targeted dock port:

lock steering to (-1) * TARGET:PORTFACING:FOREVECTOR:NORMALIZED.

This is probably not a coordinate system issue. Target:Portfacing gives you a direction (i.e. a full reference frame). By taking the ForeVector and then converting that to a direction again, you first throw away the roll information and then replace it by something random (because the mapping from a vector to a reference frame is not unique).

You  probably want to lock steering to something like LookDirUp(-PortFacing:ForeVector, PortFacing:UpVector).

Edited January 20, 2018 by pellinor

[kcs123]

2 hours ago, pellinor said:

This is probably not a coordinate system issue. Target:Portfacing gives you a direction (i.e. a full reference frame). By taking the ForeVector and then converting that to a direction again, you first throw away the roll information and then replace it by something random (because the mapping from a vector to a reference frame is not unique).

You  probably want to lock steering to something like LookDirUp(-PortFacing:ForeVector, PortFacing:UpVector).

Thanks a lot, it worked like a charm. Good to know that it is always someone willing to help when other research attempts fails.

Correct syntax for use in script is like this:

lock steering to LookDirUp(-TARGET:PORTFACING:FOREVECTOR:NORMALIZED,TARGET:PORTFACING:UPVECTOR:NORMALIZED).

Just for reference, if someone else encounter similar issue.

Edited January 20, 2018 by kcs123

[Pand5461]

@kcs123, NORMALIZED suffix is redundant for direction components as they already are unit vectors (saves a few bytes in script and some IPU).