Steven Mading

[1.7.3] kOS v1.1.9.0 : kOS Scriptable Autopilot System

Recommended Posts

9 hours ago, theJesuit said:

Nice... so much rocket wooshing past :D

:):) ..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 by ColKlonk2

Share this post


Link to post
Share on other sites
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 by Steven Mading

Share this post


Link to post
Share on other sites

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

kgAO5MT.jpg

 

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.

7IrC8PQ.jpg

Share this post


Link to post
Share on other sites
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

sjs0AEx.jpg

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites
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.kshttps://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!

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

for KSP v1.3.1 Downloads this release

Downloads:

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

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 by Steven Mading

Share this post


Link to post
Share on other sites

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 by jbakes

Share this post


Link to post
Share on other sites
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".

Share this post


Link to post
Share on other sites
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 by jbakes

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 by kcs123

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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 by kcs123

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.