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

[Dunbaratu]

2 hours ago, linuxgurugamer said:

Injust installed kOS into a new game., using CKAN.  A dialog popped up about terminal fonts.

It doesnt go away.  I have it plastered on the screen.  It just sits there, clicks go through, etc.  and when on a new screen, it is still there.  Clicking the button doesnt do anything

Not sure what is going on, but its makes the game unplayable

Update: After selecting a font in the flight scene, it went away. IMHO this is terrible.  Im planning on starting an intense, difficult career, and I shouldnt have to go to the flight scene (which, because of KCT, will take a while) to dismiss the dialog

Log file here:  https://www.dropbox.com/s/lqi789862kqlk0c/kOSissue.zip?dl=0

You're right, you shouldn't have to.

Because it's not supposed to happen like that.  It is supposed to be dismiss-able as soon as it appears.  I went through the long output log and couldn't find kOS throwing any exceptions, although it was hard to tell for sure because kOS is mentioned a zillion times because of module manager, and there's hundreds of other exceptions from TweakScale, so I may have missed it - but I couldn't find kOS making any complaints.  (The message is supposed to go away after you dismiss it, and the record of the fact that you've dismissed it once is saved in kOS's config file so I was looking for evidence that maybe it didn't write the config file out, but I saw no such complaints.)

Were there any other dialog windows open at the time you were trying to click on the kos font warning window?  I have seen cases where other mods interfere with the mouseclick events in such a way that kOS can't see them, when multiple mods pop up initial messages like that.  I haven't seen this happen when kOS is the only mod.  I have no idea which other mod it may be clashing with.

EDIT:  In retrospect, that window isn't really needed anymore.  It refers to a change kOS went through a few years ago, and was there to inform players about that change who may have last played under an older version, and at this point it shouldn't matter anymore because that was years ago.  It can probably just be totally stripped out.

Edited August 28, 2019 by Steven Mading

[Dunbaratu]

@linuxgurugamer - https://github.com/KSP-KOS/KOS/issues/2606

You are right that this is annoying, but it doesn't seem to happen consistently.  I can't get it to recur when I try.  But at any rate the dialog box shouldn't even exist anymore anyway, which is the solution I'm going to go with.

[linuxgurugamer]

10 hours ago, Steven Mading said:

Were there any other dialog windows open at the time you were trying to click on the kos font warning window?  I have seen cases where other mods interfere with the mouseclick events in such a way that kOS can't see them, when multiple mods pop up initial messages like that.  I haven't seen this happen when kOS is the only mod.  I have no idea which other mod it may be clashing with.

There were a number of other dialogs at the same time,so that was probably the issue.  Anyway, removing it should solve the issue permanently.

[Omnipius]

I'm getting strange behavior from kOS on a simple sounding rocket script for use in RO/RP-1:

LOCK THROTTLE TO 1.0.
STAGE.
WAIT 1.0.
STAGE.
WAIT 0.7.
STAGE.

What's weird is that the throttle appears to unlock and drop back to zero every time the rocket stages. So, the rocket stops flying after the first stage. If I comment out the lock and set the throttle manually, everything works out just fine. 

Any thoughts on what could be causing this and how to fix it? Could it be a bug?

 

Edited September 2, 2019 by Omnipius

[Dunbaratu]

11 hours ago, Omnipius said:

I'm getting strange behavior from kOS on a simple sounding rocket script for use in RO/RP-1:

LOCK THROTTLE TO 1.0.
STAGE.
WAIT 1.0.
STAGE.
WAIT 0.7.
STAGE.

What's weird is that the throttle appears to unlock and drop back to zero every time the rocket stages. So, the rocket stops flying after the first stage. If I comment out the lock and set the throttle manually, everything works out just fine. 

Any thoughts on what could be causing this and how to fix it? Could it be a bug?

 

If it's a sounding rocket (as in not good enough avionics to steer) then what's happening is that RP-1 locks out the gradient throttle, allowing only max/min throttle.  But the gradient throttle is how kOS moves the control lever when you LOCK THROTTLE.  kOS doesn't have a special exception to act differently when  the value is 1.0 or 0.0.  It still uses the gradient throttle lever for those.  Until RP-1 added this strange behavior, it was never a problem.

To work around it - you can use these:

// Use these instead when RP-1's avionics denies control over
// varying throttle and all it allows is max/min throttle:

set ship:control:pilotmainthrottle to 1. // instead of lock throttle to 1.
set ship:control:pilotmainthrottle to 0. // instead of lock throttle to 0.

 

Edited September 2, 2019 by Steven Mading
typo

[MacLuky]

Pretty amazing mod. 

I'm trying to find out which of my parts is draining so much electricity, but there is not much to go on. I can find what makes electricity, has electricity, but draining is harder. In the KSP API docks I can find that e.g. a light has a usesResources method and variables that indicate how much is  consumed. iResourceConsumers have a getConsumedResources method, but @JPLRepo was not using it in AmpYear so there is probably a good reason for that.

Anyway, any ideas on how I could tackle this using KOS?

[Dunbaratu]

11 hours ago, MacLuky said:

Pretty amazing mod. 

I'm trying to find out which of my parts is draining so much electricity, but there is not much to go on. I can find what makes electricity, has electricity, but draining is harder. In the KSP API docks I can find that e.g. a light has a usesResources method and variables that indicate how much is  consumed. iResourceConsumers have a getConsumedResources method, but @JPLRepo was not using it in AmpYear so there is probably a good reason for that.

Anyway, any ideas on how I could tackle this using KOS?

Sadly, every mod has its own way to drain power.  There's not a universal system for mods to tag their resource usage with ownership.  There's no "I'm the one that consumed this resource".  Each mod, during its Update, tells the KSP system, "I am in this part, and I am consuming X amount of resource foo.  Please follow the connection and crossfeed rules to remove that much resource from wherever the rules find it starting the search here."  But no record is kept of WHICH mod asked to do that, once it's been done.  So kOS can't universally ask "who consumed electriccharge just now, and how much?" Some mods make an effort to show the user a number about it, but those mods are doing that with their own unique homemade systems.  There's not a universal one for kOS to hook into.  At least, I don't think there is.  I'd love to be wrong about that.

Edited September 10, 2019 by Steven Mading

[RizzoTheRat]

Hi foilks.  Is there some oddity with the way stage:liquidfuel is calculated when it comes to Nukes or Liquid Fuel only tanks?

My staging function fires when  stage:liquidfuel=0 and stage:solidfuel=0 and ship:liquidfuel>0 

Up to now this has worked fine for solid and liquid fuelled stages as well as drop tanks.

However I've just launched my first ship with Nukes and it's not working as I expected.  The first staging works fine (Liquid/Ox boosters), but the second staging (from Liquid/Ox main engine to Liquid fuel only Nuclear powered upper stage) goes a bit wrong.  Even if I put in a 10 second delay after the staging event, it seems to think there's no liquid fuel present, despite the fact that the nukes are firing so there's clearly fuel present, so it stages again and then decides there is liquid fuel, despite having just jettisoned the payload and it's fuel tanks so it's not gained any fuel anywhere.

The below code shows 0 stage fuel for the full 10 seconds, but shows the ship fuel decreasing as the Nukes burn it.

	when stage:liquidfuel=0 and stage:solidfuel=0 and ship:liquidfuel>0 then {
		print " pre-StageL: " + stage:liquidfuel + "  StageS: " + stage:solidFuel + "  ShipL: " + ship:liquidfuel.
		Stage.
		set t to time:seconds.
		until time:seconds>t+10 or stage:liquidfuel>0{
			print "  time: " + (time:seconds-t) at (0,20).
			print "StageL: "+ stage:liquidfuel at (0,21).
			print " ShipL: " + ship:liquidfuel at (0,22).
		}
		preserve.
	}

 

[MacLuky]

I have a question, while running this script: 

function rcsDV {
	local amount is ship:monopropellant.
	local fuelMass is amount * 0.004. // monopropellant density
	local shipMassWet is ship:mass.
	local shipMassDry is shipMassWet - fuelMass.
	local isp is 260.
	local dv is isp * 9.80665 * ln(shipMassWet / shipMassWet).
	local x is (shipMassWet / shipMassWet).
	print x.
	return dv.
}

print "Estimated dv from monopropellant is " + rcsDV() + " m/s".

x gets rounded to 1. Where it should be something like 34.4453243/33.011122123 so how do I force a scalar ?

[meyerweb]

12 minutes ago, MacLuky said:

I have a question, while running this script: 

function rcsDV {
	local amount is ship:monopropellant.
	local fuelMass is amount * 0.004. // monopropellant density
	local shipMassWet is ship:mass.
	local shipMassDry is shipMassWet - fuelMass.
	local isp is 260.
	local dv is isp * 9.80665 * ln(shipMassWet / shipMassWet).
	local x is (shipMassWet / shipMassWet).
	print x.
	return dv.
}

print "Estimated dv from monopropellant is " + rcsDV() + " m/s".

x gets rounded to 1. Where it should be something like 34.4453243/33.011122123 so how do I force a scalar ?

It looks like you’re dividing the ship’s wet mass by the ship’s wet mass, so a result of 1 is to be expected.

[MacLuky]

15 minutes ago, meyerweb said:

It looks like you’re dividing the ship’s wet mass by the ship’s wet mass, so a result of 1 is to be expected.

I would expect a bit larger than 1

1.04344602924 to be precise

Sorry for the font size, copy paste on mobile

 

 

 

Edited September 26, 2019 by MacLuky

[meyerweb]

7 minutes ago, MacLuky said:

I would expect a bit larger than 1

This line:

local x is (shipMassWet / shipMassWet).

…should always produce 1, should it not?  You’re literally dividing a variable by that same variable.

[MacLuky]

*bangs head on screen* thank you. That should have been dry mass of course.

[fulgur]

Sorry to bother you: I know this thread is for reporting bugs and discussing the development, so is there anywhere on the forums I can ask people how to calculate [insert whatever I'm working on]? Because the only place I could find is Reddit, and I don't really want to use that.

EDIT: thanks kcs123!

Edited September 28, 2019 by fulgur

[kcs123]

54 minutes ago, fulgur said:

Sorry to bother you: I know this thread is for reporting bugs and discussing the development, so is there anywhere on the forums I can ask people how to calculate [insert whatever I'm working on]? Because the only place I could find is Reddit, and I don't really want to use that.

Feel free to ask here. There is not so many people hanging around here like on reddit, but there is still some that are willing to help. IIRC, there is also few threads in craft exchange forum, but not frequently visited as this one.

[fulgur]

I just found a small bug in kOS. I named a script 'executeNode.ks'. It is designed to execute nodes, rather obviously. When I went to run it, it denied that 'executenode.ks' exists. This is because while kOS does not care about case, and presumably makes entries like that lower case, the file system does, and therefore it tried to run 'executenode.ks' while the file was called 'executeNode.ks'.

[ElWanderer]

On 9/25/2019 at 9:42 PM, RizzoTheRat said:

Hi foilks.  Is there some oddity with the way stage:liquidfuel is calculated

Yes.

kOS was changed a fair while ago and this behaviour became really noticeable (reporting 0 fuel, or fuel within SRBs that aren't firing, for a stage), but my understanding is that it matches the way KSP itself calculates it.

Trying turning on the resources view in KSP and tick the "stage only" (from memory) box. See if that reports any fuel at the time kOS says it is zero.

It's something to do with confusion as to what is in a stage. I tend to notice it when I have sepratrons that will fire on stage separation, that are attached to the stage that will be discarded.

[Chabadarl]

I'm testing to improve a trajectory by small step and it's seems that this does not work for whatever reason and it's getting me crazy. 

  local index is 0.
  local candidates is list().

  until index =data:length {
    local candidate1 is data. //data is a list.
    local candidate2 is data.
		  PRINT "new".
          PRINT candidate1[index].
          PRINT step.
          PRINT candidate1[index] +step. //this works fine.
    set candidate1[index] to (candidate1[index]+step).  //this doesn't work
    set candidate2[index] to (candidate2[index]-step).  //this doesn't work
          PRINT candidate1[index]. //value has not change
          PRINT candidate2[index].
    candidates:add(candidate1).
    candidates:add(candidate2).
    set index to index +1.
  }

 

I'm posting here in desesperation. It's probably a syntax error but I don't understand why the set to doesn't work in this case....

 

[Dunbaratu]

1 hour ago, Chabadarl said:

I'm testing to improve a trajectory by small step and it's seems that this does not work for whatever reason and it's getting me crazy. 

  local index is 0.
  local candidates is list().

  until index =data:length {
    local candidate1 is data. //data is a list.
    local candidate2 is data.
		  PRINT "new".
          PRINT candidate1[index].
          PRINT step.
          PRINT candidate1[index] +step. //this works fine.
    set candidate1[index] to (candidate1[index]+step).  //this doesn't work
    set candidate2[index] to (candidate2[index]-step).  //this doesn't work
          PRINT candidate1[index]. //value has not change
          PRINT candidate2[index].
    candidates:add(candidate1).
    candidates:add(candidate2).
    set index to index +1.
  }

 

I'm posting here in desesperation. It's probably a syntax error but I don't understand why the set to doesn't work in this case....

 

I don't know what this code is *meant* to do, but what it *does* do is this:

candidate1[index] and candidate2[index] are the exact same object.  So you are adding +step then in the very next line -step, putting it right back where it started, each time.

The reason they are the same exact object is this part here at the top:
 

local candidate1 is data. //data  is a list.
local candidate2 is data.

 

[Chabadarl]

9 minutes ago, Steven Mading said:

I don't know what this code is *meant* to do, but what it *does* do is this:

candidate1[index] and candidate2[index] are the exact same object.  So you are adding +step then in the very next line -step, putting it right back where it started, each time.

The reason they are the same exact object is this part here at the top:
 

local candidate1 is data. //data  is a list.
local candidate2 is data.

 

thanks... I knew I forgot something obvious....

I meant to write...

local candidate1 is data:copy. //data  is a list.
local candidate2 is data:copy.

the code is slighty changing data to test for improvement. and hill climbing to the best solution...

Edited October 5, 2019 by Chabadarl

[squidgeny]

Hi, wondering if someone could answer a quick question for me. I'm fairly inexperienced with KOS.

I have a probe going to minmus and I won't be able to communicate with it when it gets there. So I've written a simple program to automate its orbital insertion, and intend to run that program just before it goes out of comm range. It'll get there 7 days later, so the program will be running for 7 days, waiting for the right moment before performing the insertion.

In that time window, I intend to switch to other vessels and do other stuff. I've read conflicting information around the internet that KOS will and won't work in such situations. So perhaps you can clarify: will my plan work?

Thanks!

[zer0Kerbal]

depends upon how it will handle being rebooted. switcheding vessels and coming back (IIRC) will cause it to reboot the kOS processors.

RunMode might be one way to handle it - or just make sure you have the right run mode.

another way might be to set up a maneuver node, and just use a noderunner.ks program as the bootstrap file to run the maneuver node.

Edited October 8, 2019 by zer0Kerbal

[Drew Kerman]

2 hours ago, squidgeny said:

In that time window, I intend to switch to other vessels and do other stuff. I've read conflicting information around the internet that KOS will and won't work in such situations. So perhaps you can clarify: will my plan work?

no, but like zer0kerbal said it can work if you do it right. You need to send the craft the instructions, have it store them on the vessel and then run them when it boots up after you switch to it. You can find more about boot files (not bootstrap) in the kOS docs.

I have a general-purpose control system that can do what you want, if you want to use it or just want a practical example

[zer0Kerbal]

https://ksp-kos.github.io/KOS_DOC/tutorials/exenode.html

 

[squidgeny]

Thanks both! It sounds like a "boot file" is what I want. I think I've found the relevant bit in the docs: https://ksp-kos.github.io/KOS_DOC/general/volumes.html#special-handling-of-files-in-the-boot-directory

If I understand this correctly (and i probably don't, because the docs are way beyond my layman knowledge!), I need to do the following:

• create a "boot" directory on the ship's CPU volume, and put my program in it
• switch to the vessel (thus causing the program to begin running immediately) before it reaches the relevant point where a manoeuvre needs to be made
• sit back and wait for the program to execute all its code
• then I can safely switch out to another vessel / space centre or whatever

If I've got that right then that's more than good enough