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

[theJesuit]

23 minutes ago, ColKlonk2 said:

KOS automatic launch to orbit with burntime calculation - not bad ... within 4Km of Eccentricity = 0.

https://www.youtube.com/watch?v=a1VB07B4hrg&feature=youtu.be

I'll try next with pure vectors and calcs.

Nice... so much rocket wooshing past

Is that what the terminal looks like now?

[ColKlonk2]

9 hours ago, theJesuit said:

Nice... so much rocket wooshing past

 ..Playing around and too lazy to edit it out.. for sake of continuity.

Recorded video at 6 fps and accelerated (compressed) final result to 24 fps.. so yes.. whooooooooosh  

Quote

Is that what the terminal looks like now?

I've just blanked the terminal background images, as I would like to get only a green text overlay.

KOS seems to have the grey background embedded in code, so cannot get rid of it.  I'll look at KOSs dialog boxes next.

 

Edited December 9, 2017 by ColKlonk2

[Dunbaratu]

13 hours ago, ColKlonk2 said:

KOS seems to have the grey background embedded in code, so cannot get rid of it.  I'll look at KOSs dialog boxes next.

It's not embedded in code.  It's from these image files:

GameData/kOS/GFX/monitor_minimal.png

GameData/kOS/GFX/monitor_minimal_frame.png

GameData/kOS/GFX/monitor_minimal_frame_active.png

There's no guarantee those files will still be used in this way in future releases, but for now if you edited them they'd change what the background looks like.

Edited December 9, 2017 by Steven Mading

[guitarxe]

On 12/8/2017 at 3:11 PM, ColKlonk2 said:

KOS automatic launch to orbit with burntime calculation - not bad ... within 4Km of Eccentricity = 0.

https://www.youtube.com/watch?v=a1VB07B4hrg&feature=youtu.be

I'll try next with pure vectors and calcs.

That looks beautiful. What engines and tanks are that? I don't recognize it...

[ColKlonk2]

SteveM:  KOs doesn't seem to like a transparent terminal background pic for some reason and still produces the shade. 

 

Rocket details:

Both LHLOX engines

RD-0120s from the Russian Engines pack

LR87s for upper stage use.. RD-0120s are too powerful and would pancake everything in the payload

 

The payload is SSTUs habitat with it's own engines and goodies. I had to factor a Cos(30) into the burntime calcs as these engines point outwards.

[ColKlonk2]

On 12/9/2017 at 10:08 PM, Steven Mading said:

It's not embedded in code.  It's from these image files:

Decided to do a check.. afraid it is embedded in code.

Most likely in setting the background window colour in some API

I changed those three images to just blank colours.. one can still see the window border is still grey ?

While the three colours are seen in the screen active area

[Dunbaratu]

11 hours ago, ColKlonk2 said:

Decided to do a check.. afraid it is embedded in code.

If by "it" you mean only the outer border, yes.  But your post I was replying to said "background", not "border", so that's the part I thought you cared about when I said "it" can be overridden by changing the image files.

The grey outer border is being inherited from KSP's standard GUI theme.  The image is overriding what the standard theme would do within the rectangle where the terminal background image goes, using a 9-slice image.

 

[scimas]

On 07/12/2017 at 10:53 PM, ElWanderer said:

My slope library is here:  https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/scripts/lib_slope.ks / https://github.com/ElWanderer/kOS_scripts/blob/v1.1_draft_changes/documentation/lib_slope_readme.md though all the hard work was taken from episode 42 or 43 of Cheers Kevin's Kerbal Space Programming series on YouTube.

I had figured out a basic method to calculate slope at current spot, but your library does provide better functionality, thanks!

[APlayer]

Hi there!

I've been wondering for some time, is there a library, or even a command, to calculate the total available RCS/Reaction Wheel torque? I found this Reddit post, but this seems like re-inventing the wheel and not really reliable. Is there something people already created?

[hvacengi]

v1.1.4.0 Does faster compilation break a work flow?

 

Downloads:

• Github: https://github.com/KSP-KOS/KOS/releases/tag/v1.1.4.0
• Curse: https://kerbal.curseforge.com/projects/kos-scriptable-autopilot-system/files/2512889
• Spacedock: [pending]

This release was primarily focused on speedups and smoothness
of execution. We welcomed a new developer (github username @tsholmes)
who contributed a lot of bottleneck analysis and code speedups. The
goal was to reduce the burden kOS causes to the physics rate of the
game, and consequently also allow tech tree scaled performance by era
for the kOS computer parts themselves (slow at first, faster later).

BREAKING CHANGES:

• If you use the compiled script feature YOU MUST RECOMPILE ALL KSM FILES,
  USING KSM FILES COMPILED IN A PREVIOUS VERSION WILL RESULT IN AN ERROR.
• Files now have an implied local scope, causing the following change:
  • Previously: If you declared a variable as local at the
    outermost scope of a program file (outside any curly braces),
    then it had the same effect as global, creating a variable
    that you could see from anywhere outside that program file.
  • New behavior: Now that there is an outermost scope for a file,
    local actually means something in that scope. To get the
    old behavior you would need to explicitly call the variable
    global.
    (The variables magically created via the lazyglobal system will still
    be global just like they were before.)
• Parameters to programs now have local scope to that program file.
  (Previously they were sort of global and visible everywhere, which
  they shouldn't have been. If you relied on this behavior your
  script might break.) This is of particular note when working with locks and
  triggers as the local parameters may conflict with the global scope of these
  features.
• Functions declared at the outermost scope of a program will now
  keep proper closure, making them see variables local to that program
  file even when called from outside that file. This may hide a global
  variable with a more local variable of the same name, when previously
  the global variable would have been accessible from the function.
  (You probably weren't relying on this buggy behavior before, but
  if you were, this fix will break your script.)

NEW FEATURES:

• File scope: Previously, kerboscript did not wrap program files
  in their own local scope. (Declaring a local in a file had
  the same effect as declaring a global there). Now each program file
  has its own scope (and also the parameters passed to a program file
  are local to that file scope).
  • NOTE: For backward compatibility, there is one important exception
    to the file scope - functions declared at the outermost level by
    default can be globally seen in other programs. You CAN get functions
    that are local to the file's scope, but you have to explicitly include
    the local keyword in the function declaration to make that happen.
    pull request

OPTIMIZATIONS:

• The regular expression syntax used to compile programs has been heavily
  modified to speed up file parsing using start string anchors and eliminating
  string copying.
  pull request
  pull request
• Suffix lists are no longer initialized on every call, saving both execution
  time and memory.
  pull request
• Various string operation optimizations for internal string lookups.
  pull request
  pull request
• The cpu stack was re-written to use two stacks instead of using a single stack
  with hidden offsets.
  pull request
• Cache type lookup data for suffix delegates.
  pull request
• Begin encoding identifiers directly in opcodes instead of pushing a string
  identifier prior to executing the opcode.
  pull request
  pull request
• General optimizations for the C# source code, including for unit tests.
  pull request
  pull request
  pull request
  pull request

BUG FIXES:

• Functions at the outermost file scope level now have closures that can
  see the file scope variables properly. Previously they could not (but
  this did not matter since there was no file scope to matter. This bug
  got exposed by the other file scope changes.)
  pull request
• Fixed inability to use flight controls on a craft with local control when
  RemoteTech is installed, both with and without a probe core installed.
  pull request
• Fixed a crash to desktop when attempting to parse very large numbers.
  pull requst
• Fixed syntax errors in the exenode tutorial documents. The code as displayed
  has been tested to work correctly as of this release.
  pull request
• Parsing numbers on host computers that normally expect the , character to
  be used as a decimal symbol will no longer be blocked. kOS now forces the use
  of CultureInvariant when parsing numbers, so all locales will be required
  to use the . character for decimals.
  pull request
• Action Groups Extended support should once again work as the the method used
  to detect that the mod is installed has been repaired.
  pull request
• Attempting to delete a path that does not exist no longer throws a null
  reference error.
  pull request
• Documentation was added for part:hasmodule suffix.
  pull request

[scimas]

@hvacengi Thanks for the update! How much time does it usually take to show up on CKAN?

[kcs123]

2 hours ago, scimas said:

How much time does it usually take to show up on CKAN?

That is not something any mod developer can tell. CKAN developers are responsible for this and it depends how much time is passed from last check of CKAN robot script that cares about automatization. It usualy takes few hours up to one day.

[scimas]

Ok, I had thought that maybe mod devs have to update their own configuration files with CKAN or something like that.

[hvacengi]

On 12/23/2017 at 8:32 AM, scimas said:

Ok, I had thought that maybe mod devs have to update their own configuration files with CKAN or something like that.

We do maintain a configuration file, but the CKAN web crawl to look for those updates is out of our control.  The good news is that it appears to have updated now.  Usually it takes between 12 and 24hrs for the update to hit CKAN.  (I want to say CKAN does an update every 12 hours, which would align with my past experience).

[Dunbaratu]

There's a known bug with function declarations in the latest kOS 1.1.4.0 release.

The short version is this:  If you have inner functions (functions nested inside other functions), it is falsely defaulting them to be global scope rather than local scope like they should be.

A temporary workaround is to insert the keyword "local" in front of your inner functions (nested functions) for now.  (don't do this with the outermost ones, though - they need to stay global or you can't call them from outside the file).  The bug only affects the default the compiler chooses when you leave it unspecified.  If you mention it explicitly, that still works right.

 

[Dunbaratu]

Hotfix release v1.1.5.0 Ready

This fixes the problem with function declaration default scoping that was introduced in v1.1.4.0.

There is no other change in this.  It is a hotfix.

Get it at all the usual locations.

Edited January 1, 2018 by Steven Mading

[jbakes]

Can anyone tell me how to log some flight data? I'm creating an ascent profile script and I need to log some data to tell how efficient I am. For instance knowing like my pitch and altitude throughout the flight or even velocity. Just so I can graph it. Thanks in advance. 

Edited January 8, 2018 by jbakes

[ElWanderer]

39 minutes ago, jbakes said:

Can anyone tell me how to log some flight data? I'm creating an ascent profile script and I need to log some data to tell how efficient I am. For instance knowing like my pitch and altitude throughout the flight or even velocity. Just so I can graph it. Thanks in advance. 

LOG my_variable TO log_file_path.

If log_file_path is on the archive (e.g. "0:/log/testrun1.txt") you'll need to have a connection back to KSC (assuming you're playing with CommNet enabled or Remote Tech installed), but it will persist after mission end.

If you want to make it easier to graph it, you can concatenate the various values with commas into a single string variable, then log that into a .CSV file e.g.

LOG ALTITUDE + "," + SHIP:VELOCITY:SURFACE:MAG TO "0:/log/ascent.csv".

[jbakes]

12 hours ago, ElWanderer said:

LOG my_variable TO log_file_path.

If log_file_path is on the archive (e.g. "0:/log/testrun1.txt") you'll need to have a connection back to KSC (assuming you're playing with CommNet enabled or Remote Tech installed), but it will persist after mission end.

If you want to make it easier to graph it, you can concatenate the various values with commas into a single string variable, then log that into a .CSV file e.g.

LOG ALTITUDE + "," + SHIP:VELOCITY:SURFACE:MAG TO "0:/log/ascent.csv".

I'm new to KOS and programming in general so I don't really understand these commands. I'm guessing LOG ALTITUDE + "," + SHIP:VELOCITY:SURFACE:MAG TO "0:/log/ascent.csv". is going to log my data to some file. Where would that file be located?

Edit: I actually found a file named "ascent" in a folder called "log" I entered that line of code at the end of my script and it logged the numbers but it did it only once. How do I get it to log throughout the flight? Also can I get it to log at certain intervals of time or altitude?

Edited January 8, 2018 by jbakes

[ElWanderer]

5 minutes ago, jbakes said:

I'm new to KOS and programming in general so I don't really understand these commands. I'm guessing LOG ALTITUDE + "," + SHIP:VELOCITY:SURFACE:MAG TO "0:/log/ascent.csv". is going to log my data to some file. Where would that file be located?

The root of 0: aka the archive is your Ships/Script directory inside your KSP install. So that example would save to something like C:\Program Files (x86)\Steam\Steamapps\common\Kerbal Space Program\Ships\Script\log\ascent.csv

[kcs123]

11 minutes ago, jbakes said:

"0:/log/ascent.csv". is going to log my data to some file. Where would that file be located?

Answer is in your question. "0:" drive or "archive" drive is located in your "..\KSP\Ships\Script" folder.

Edit:

ninja'd by ElWanderer by couple of seconds.

Edited January 8, 2018 by kcs123

[jbakes]

1 minute ago, ElWanderer said:

The root of 0: aka the archive is your Ships/Script directory inside your KSP install. So that example would save to something like C:\Program Files (x86)\Steam\Steamapps\common\Kerbal Space Program\Ships\Script\log\ascent.csv

Ya I found it, idk if you saw my edit but it only logged it once. How would I get it to log throughout the entire flight? Also can I set intervals for the log such as time or altitude?

9 minutes ago, kcs123 said:

Answer is in your question. "0:" drive or "archive" drive is located in your "..\KSP\Ships\Script" folder.

Ya I found it, it only logs it once though, How do I get to log throughout the entire flight?

[kcs123]

Interval depends on how fast your script is and where you have put loging in your code. You can use time from Kerbal world to print it in log.
Log should always append in same file new line of text unless something is terrible wrong with latest kOS.

You can find more info about log in documentation: http://ksp-kos.github.io/KOS_DOC/commands/files.html?highlight=log

You should try some very simple script like five rows to log, something like this:

Quote

LOG ALTITUDE + "," + SHIP:VELOCITY:SURFACE:MAG TO "0:/log/ascent.csv". 
LOG ALTITUDE + "," + SHIP:VELOCITY:SURFACE:MAG TO "0:/log/ascent.csv".
LOG ALTITUDE + "," + SHIP:VELOCITY:SURFACE:MAG TO "0:/log/ascent.csv".
 

That would reveal if it something went wrong with kOS, or you put loging in wrong part of your script.

EDIT:

You can use some trigger like this:

Quote

set deltaTime to 0.

when deltaTime > 2 then {
LOG ALTITUDE + "," + SHIP:VELOCITY:SURFACE:MAG TO "0:/log/ascent.csv".
}.

// in some other part of code increase deltaTime trough loop

Don't know exact command for time variable from top of my head, have to look for that in documentation.

Edited January 8, 2018 by kcs123

[jbakes]

3 minutes ago, kcs123 said:

Interval depends on how fast your script is and where you have put loging in your code. You can use time from Kerbal world to print it in log.
Log should always append in same file new line of text unless something is terrible wrong with latest kOS.

You can find more info about log in documentation: http://ksp-kos.github.io/KOS_DOC/commands/files.html?highlight=log

You should try some very simple script like five rows to log, something like this:

That would reveal if it something went wrong with kOS, or you put loging in wrong part of your script.

I put that command at the end 4 times and it logged it 4 times but all at the same time so all the numbers are the same. How do I create an interval for the log to run on?

[kcs123]

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:

Quote

until SHIP:ALTITUDE > 30000 {

// print some output data to terminal if you just need quick temporary data
LOG ALTITUDE + "," + SHIP:VELOCITY:SURFACE:MAG TO "0:/log/ascent.csv".
wait 1. // you will wait 1 sec. before this part of loop start again and write another line in log. You can use lower time than 1 sec or more, depending of your preference

}.

 

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.