kOS Autopilot

[baloan]

I am having a hard time aligning the different clocks in the system.

Missiontime: self-explanatory.

Time: I though I knew what it is.

UT time display: Hm, what the heck...?

Anyone knows how UT and kos:time relate?

[Dunbaratu]

Anyone knows how UT and kos:time relate?

What do you mean by the abbreviation "UT"?

[erendrake]

I am having a hard time aligning the different clocks in the system.

Missiontime: self-explanatory.

Time: I though I knew what it is.

UT time display: Hm, what the heck...?

http://ksp.baldev.de/kos/screenshots/time-mismatch.PNG

Anyone knows how UT and kos:time relate?

By UT I assume you mean UniversalTime?

TIME is UT with a structure around it, really missiontime should have the same structure but i havent gotten around to it.

if you want to get UT in seconds its TIME:SECONDS

[baloan]

There is a time difference between the UT time display in the left upper corner and the time variable in kOS.

UT: Y1, D02, 4:30:54

kOS time: Y1, D01, 10:29:53

Difference by about 18 hours (assuming Kerbin day has 24 hours).

Does this have to do with game time and saved game time?

[CaptainKipard]

That looks identical to me. A day is 6 hours so "day 1 hour 10" is the same as "day 2 hour 4".

[Dunbaratu]

(assuming Kerbin day has 24 hours).

That right there is the problem.

A Kerbin day is 6 hours.

[erendrake]

There is a time difference between the UT time display in the left upper corner and the time variable in kOS.

http://ksp.baldev.de/kos/screenshots/time-mismatch2.PNG

UT: Y1, D02, 4:30:54

kOS time: Y1, D01, 10:29:53

Difference by about 18 hours (assuming Kerbin day has 24 hours).

Does this have to do with game time and saved game time?

This has to do with me never switching to UT in the map view before. Now its me staring at the useless time code and adding a bug to Github.

Thank you @baloan.

[erendrake]

NEW PRE-RELEASE

Up on Github

After v12.0 we started finding a lot of bugs with steering and the "revert to launch" button. This is the first pre-release of v12.1

On Github

* Fixed Terminal linewrap @ the bottom of the terminal

* Fixed "Revert to Launch" button, it was blowing up the world and not allowing control before

* Fixed LOCK s in subprograms

* Fixed RemoteTech integration blowing up everything

* Fixed flight controls not releasing when they should

[baloan]

I am looking for documentation on:

1. how to use thrusters?

For a Kerbin Minmus transfer I need to align inclination. The challenge is to find the right point in Kerbin orbit where to do inclination change. When setting a target the inclination and the axis where orbital planes cross is visible in the UI.

2. Which variables in kOS show the two points in my ship's orbit where ship and target orbital planes cross?

My guess would be something like:

TARGET:OBRIT:INCLINATION

TARGET:ORBIT:ASCENDING:ETA

TARGET:ORBIT:DESCENDING:ETA

I checked the Orbit and Node descriptions in the git KOS/Docs directory which was helpful but not conclusive.

Thanks, baloan

Edited May 13, 2014 by baloan
REPLACED POSITION BY ETA.

[erendrake]

I am looking for documentation on:

1. how to use thrusters?

For a Kerbin Minmus transfer I need to align inclination. The challenge is to find the right point in Kerbin orbit where to do inclination change. When setting a target the inclination and the axis where orbital planes cross is visible in the UI.

2. Which variables in kOS show the two points in my ship's orbit where ship and target orbital planes cross?

My guess would be something like:

TARGET:OBRIT:INCLINATION

TARGET:ORBIT:ASCENDING:POSITION

TARGET:ORBIT:DESCENDING:POSITION

I checked the Orbit and Node descriptions in the git KOS/Docs directory which was helpful but not conclusive.

Thanks, baloan

This is something i have been noodling on for a few weeks on. once you have a target there are quite a few important bits of info we should add. For this example you could work it out if we added the "Longitude of AN" for the craft and minimus. However this might be a pretty big barrier to calculate that for a lot of younger scripters.

What does everyone think about this? This would be additional data exposing more of the numbers that the KSP interface gives us

* ETA to and/or Longitude of AN/DN

* Rotational delta

* translational delta

* rotational rate of change

* translational rate of change

* Closest approach distance and ETA

* Relative motion vector

Any or all of these or others could be good. Sound off, tell us what you think.

[Dunbaratu]

This is something i have been noodling on for a few weeks on. once you have a target there are quite a few important bits of info we should add. For this example you could work it out if we added the "Longitude of AN" for the craft and minimus. However this might be a pretty big barrier to calculate that for a lot of younger scripters.

What does everyone think about this? This would be additional data exposing more of the numbers that the KSP interface gives us

* ETA to and/or Longitude of AN/DN

* Rotational delta

* translational delta

* rotational rate of change

* translational rate of change

* Closest approach distance and ETA

* Relative motion vector

Any or all of these or others could be good. Sound off, tell us what you think.

Detecting whether or not you are at one of the ascending or descending nodes is detectable with vector cross product math.

my normal = my velocity crossed with my soi body position.

targets normal = its velocity crossed with (my soi body position - targets position relative to me)

node line direction = my normal crossed with targets normal.

keep updating them in locks, and wait until my soi body position is parallel to node line direction.

What isn't easily detectable because it requires integration by numerical approximation, is the *time* it takes to get to that spot. In general, solving the problem of "how long does it take to get to point X in my orbit" is only easy when dealing with perfectly circular orbits. Once your orbit has any eccentricity to it, that problem becomes messier, so it's better to let the KSP engine do that for you (as it has the logic for this built-in).

I'm not in favor of adding easily derivable things, like relative motion vector, which is literally your velocity minus the target's velocity.

Closest approach distance, on the other hand, is a pain to derive and it makes sense to show that. (In general I'm annoyed with the fact that the KSP manual flying interface refuses to show that either unless it's near. If your inclination is far off it won't tell you where your nearest approach is. That makes it impossible to efficiently combine inclination correction with transfer burn because you have to correct inclination first just to even see how you're doing on the transfer orbit.)

@erendrake - are you thinking that the primary goal for the next feature update should be rendezvous and docking support?

Edited May 14, 2014 by Steven Mading

[SolarLiner]

TL;DR the thread, so this may have been answered already.

I'm coming home from a loong break off of KSP, and kOS was the first mod I thought about when planning flights.

Does kOS still have the binding to external modules? (ie: you had to pass to kOS module via SendMessage a special command that allows to trigger functions in your own module)

Also how would it be possible to send kOS commands from some other module (ie: send "run FooScript")?

[sirkut]

TL;DR the thread, so this may have been answered already.

I'm coming home from a loong break off of KSP, and kOS was the first mod I thought about when planning flights.

Does kOS still have the binding to external modules? (ie: you had to pass to kOS module via SendMessage a special command that allows to trigger functions in your own module)

Also how would it be possible to send kOS commands from some other module (ie: send "run FooScript")?

This is what I'm interested in. I want to get Infernal Robotics working again. I had limited success with the original plugin but now that I have the plugin for IR rewritten it should be easier for me to implement.

[erendrake]

TL;DR the thread, so this may have been answered already.

I'm coming home from a loong break off of KSP, and kOS was the first mod I thought about when planning flights.

Does kOS still have the binding to external modules? (ie: you had to pass to kOS module via SendMessage a special command that allows to trigger functions in your own module)

Also how would it be possible to send kOS commands from some other module (ie: send "run FooScript")?

This is what I'm interested in. I want to get Infernal Robotics working again. I had limited success with the original plugin but now that I have the plugin for IR rewritten it should be easier for me to implement.

I would be happy to help you both get to executing code. We dont have the features now but lets figure out what the smallest bit is and we will get it in for 12.2

Would you both like to talk about this feature over in the github tracker? https://github.com/KSP-KOS/KOS/issues/103

[Hukehrs Engineering]

Hey guys,

first of all: Thank you so much for all your hard work.

1.) Are there any plans to implement a list of parts and direct control over them? (For example shut down engine X, or disable RCS thruster Y, general access to a parts right click menu actions).

2.) How 'bout a random number generator?

I want to make missions more exciting by having random stuff "brake" on missions. kOS seems like a good place to start, rather than implementing my own plugin. From what I've seen and tried plugin development seems to be....very kerbal.

[Dunbaratu]

1.) Are there any plans to implement a list of parts and direct control over them? (For example shut down engine X, or disable RCS thruster Y, general access to a parts right click menu actions).

2.) How 'bout a random number generator?

#1 - Might be doable but it's on a far-flung "would be nice" future list. The ability to open up a generic "do whatever options are on the rightclick menu of a part" is in principle posisble, but its certainly not there yet.

#2 - Sounds pretty easy to implement. If you make an issue for it on the github page here: https://github.com/KSP-KOS/KOS/issues as a reminder, people are far more likely to remember the request and get it into the TODO list at some point.

[erendrake]

1.) Are there any plans to implement a list of parts and direct control over them? (For example shut down engine X, or disable RCS thruster Y, general access to a parts right click menu actions).

2.) How 'bout a random number generator?

1. there are already a few of these controls available, but there is no way to "break" parts

2. we already have a Random number generator

[erendrake]

New pre-release

https://github.com/KSP-KOS/KOS/releases/tag/v12.2P1

* BREAKING: All direction references are now relative to the controlling part, not the vessel, this will only break on vessels there these two directions are not the same.

* Added a 3d Drawing tool for letting you draw https://www.youtube.com/watch?v=Vn6lUozVUHA
* Added a new and improved file editor so the edit command actually works again in game!
* Added the ability to switch to MapView and back in code
* Other bug fixes

[CaptainKipard]

Does this mean I can launch inverted payloads?

[erendrake]

Does this mean I can launch inverted payloads?

I imagine it will make it easier conceptually but was there something that blocked you before?

[CaptainKipard]

If the root was up-side-down, even "controlling from" a correctly oriented part on a lower stage would cause kOS to not lock steering at all. The rocket would try to align but never settle.

[erendrake]

If the root was up-side-down, even "controlling from" a correctly oriented part on a lower stage would cause kOS to not lock steering at all. The rocket would try to align but never settle.

Well then this would likely help. Please let us know if it doesnt and we will get it on the list of fixes!

EDIT: Mariano knew the truth

Edited May 21, 2014 by erendrake

[marianoapp]

Actually the only thing that changed was the FACING suffix but the steering code was not modified. I'll add a ticket for that.

[Dunbaratu]

As the one who's taken on the documentation hat for the project, I'm sorry that the new features aren't in the documentation pages yet (I don't want to put pre-release stuff there that's not fully released, as the documentation system is a bit inflexible about how it names the git branches and it's hard to have the new documentation in a separate branch to merge in later.)

So in this forum post I'll give the quick and dirty user-level documentation for the pre-release features erendrake just announced:

Added a 3d Drawing tool for letting you draw

The URL given above (

) shows a demo of it, but here's the features written down:

Make a new vector drawing object: There are two "constructors":

  // null constructor that makes default zeroed-out fields that have to be filled one at a time:
  set myArrowDrawing1 to VECDRAW().

  // constructor with arguments that fills in fields up front:
  set myArrowDrawing2 to VECDRAWARGS( <start>, <vector>, <color>, <label>, <scale>, <show> ). 

SUFFIX fields you can set to change behavior:

  set myArrowDrawing1:START to _vector_. // the origin to draw the vector tail from - default v(0,0,0). 
  set myArrowDrawing1:VEC to _vector_. // the vector you'll actually be drawing on the screen.
  set myArrowDrawing1:COLOR to _color_. // The color to show the vector arrow with.  can be spelled COLOUR for all the non-Americans out there.
  set myArrowDrawing1:LABEL to _string_. // The text label to show on the vector arrow.
  set myArrowDrawing1:SCALE to _number_. // The scalar multiplier for the size of drawing the arrow. 1 = 1 meter per unit.
  set myArrowDrawing1:SHOW to _boolean_. // True = show the arrow, False = hide the arrow.
  set myArrowDrawing1:WIDTH to _number_. // if you want to force it to draw wider you can set this.  default 0 = let kOS dynamically pick it.

For all the above places where you can pick a color, there is a new color object:

// You can use the following predefined color names for the basic primary and secondary colors:
set col to RED.
set col to GREEN.
set col to BLUE.
set col to YELLOW.
set col to CYAN.
set col to MAGENTA.  // Can also say "PURPLE" for the same thing.
set col to WHITE.
set col to BLACK.  // Here for completeness, but probably useless as you can't see it against space.

// To pick any arbitrary color you can do this:
// The function RGB() returns a color from manually picking the red,green,blue values
// (each value spans from 0.0 to 1.0):
set col to RGB( 1.0, 0.6, 0.0 ).  // an orange-ish color.

// You can also set the color transparency with RGBA() (A for alpha channel):
set col to RGBA( 1.0, 0.6, 0.0, 0.5 ). // a more transparent orange-ish color.

It may seem overkill to make a color type for this, but its there to aid in potential future eye-candy features that might need colors.

Added a new and improved file editor so the edit command actually works again in game!

Run the

EDIT _filename_.

command, like you used to be able to do, and something like the screenshot below now appears. The font is proportional-width, which is less than optimal, but that's very hard to fix. A fuller explanation is here.

Also the scrollbar doesn't let you scroll with mouse - you have to use PageUP and PageDown. But that was considered minor enough of a problem to still pre-release anyway.

Added the ability to switch to MapView and back in code

The syntax for this is simple:

  // Querying:
  if MAPVIEW { print "I am on map view". } else { print "I am in flight view". }.

  // Setting:
  set MAPVIEW to true.
  print "Now looking at the map".
  wait 5.
  set MAPVIEW to false.
  print "Now looking at flight view".

Edited May 23, 2014 by Steven Mading
Added the section describing how to set a color.

[Waz]

I have implemented a boot (or "autorun") system for kOS. It's intended to be simple and stick to the "1970s computer" style. It works like this:

1. The user creates multiple files starting with "Boot" in the Archive. (ideally they'd be in a "boot" subdir but Archive doesn't have that AFAIK)
   
2. In the VAB for each rocket, the boot code for each CPU can be selected via a Tweakable.
   
3. At launch, the named Boot file is copied from the Archive to volume 1 as "boot".
   
4. At CPU boot, if a file named exactly "boot" exists, it is executed.
   

Typically the Boot file would check the STATUS and if PRELAUNCH it would launch the vehicle into orbit or whatever it's mission is. If not in PRELAUNCH it's probably a system reboot (eg. loss of power), and so it would do nothing. I would like to ship two simple boot files, one that simply prints the version like the hard-coded stuff, and another that initiates a REALLY simple autolaunch, however the Archive is still in a really silly place so I'd rather wait until it moves, and worse, the simplest of all launches:

set thrust to 1.
sas on.
stage.

Of course cannot work because thrust returns to the user's previous value once a fly-by-wire disconnects. I'd rather not ship a quality autolauncher - the whole fun of kOS is writing your own, otherwise you might as well just use MechJeb or something.

I would later like to add user inputs (eg. buttons) such that the boot program would instead be a menu, so the boot program in the non-prelaunch state would then be something more interesting.

What is the best way to submit the patch for review/inclusion, if this is something useful?