[1.3] kOS Scriptable Autopilot System v1.1.3.0

[TDW]

is "ship:heading" broken? It always displays minuscule numbers for me no matter my compass heading. Does that sound familiar or should I make a bug report?

Vessel:Heading gives a heading to that vessel. So ship:heading is asking for the heading to yourself, hence the realy small number.

[Blu_C]

Or perhaps is he referring to the fact that sometimes the last few bits of fuel are not used up for some reason so the tank technically isn't empty and if that's what the code is waiting for, then it won't stage.

It could also have to do with the fact that KSP's logic for measuring the fuel in a stage is currently sketchy at best.

[Sideswiper22]

It could also have to do with the fact that KSP's logic for measuring the fuel in a stage is currently sketchy at best.

I got the problem fixed. I was setting it to "...stage:kerosene = 0" instead of < 0.001. I remembered that 0 is sometimes a problematic number.

Edited April 18, 2015 by Sideswiper22

[Dunbaratu]

is "ship:heading" broken? It always displays minuscule numbers for me no matter my compass heading. Does that sound familiar or should I make a bug report?

The vessel:heading suffix is telling your your heading to travel at to get TO the vessel in question. It's meant for helping you aim toward a target vessel.

Watch this space. When 0.17.0 is released, there will be a fledgling user functions library link that has a function to get your compass heading using entirely user-land code.

- - - Updated - - -

I got the problem fixed. I was setting it to "...stage:kerosene = 0" instead of < 0.001. I remembered that 0 is sometimes a problematic number.

I don't know realfuels. Is it like stock in that there's two types of fuel you have to burn in unison (i.e. like liquidfuel and oxidizer). If so it could be the very same problem, and it's really a "bug" in main KSP rather than in kOS (although not really a bug, just the way you'd naturally expect it to work).

When people get the remaining drop of liquidfuel that won't go all the way to zero, it's usually because the oxidizer HAS gone all the way to zero and the engine cannot burn that last bit of liquidfuel without the associated oxidizer to go with it.

Think of it as a slight measurement error where the engineering cannot possibly be precise enough to get the amount of the two types of fuel to match each other *exactly* and burn down *exactly* at the same time.

In actuality it's accumulated floating point error from subtracting tiny amounts of fuel repeatedly in very tiny time slices 25 times per second. That can become just off enough that the two fuels don't hit zero together. While you could call that a computer error, I figure it actually makes perfect real-world sense. You're never going to have a system engineered so precisely that it gets the two fuel types to run to zero at the same time, to within a factor of a fraction of a gram of fuel.

In general, if you're trying to test for running out of fuel, and you're using a bi-fuel system like liquidfuel plus oxidizer, then always build your check so it checks if *either one or the other* has become zero, not just one of them.

[Sideswiper22]

@Steven Mading

RealFuels gives you a wider range of fuel types that have different efficiencies. So you get more delta v compared to stock, which is helpful if you have rss installed so you wouldn't need huge rockets just to get to lko.

Maybe it's due to it's realism that makes the plugin go haywire. instead of a ratio of 9:11 in stock, the ratios in Realfuels are different and with many decimals. so maybe there is 0.00000000000001 left after the oxidizer ran out that makes 0 unreachable.

[erendrake]

NEW VERSION! v0.17.0

Github

Kerbal Stuff

Curseforge

Big feature: You can make your own user-defined functions, that

can handle recursion, and can use local variable scoping. You can

build a library of your own function calls and load them into your

script.

New Documentation change page:

For those users who just want to see what new features

exist without reading the entire documentation again

from scratch, we have created a changes page in the main documentation:

• New Changes Page: http://ksp-kos.github.io/KOS_DOC/changes.html
  

For the features mentioned below, you can go to the page above

and get a more verbose description of the new features.

[h=3]New Features:[/h]A brief list of what's new:

• Variables can now be local
  
• Kerboscript has User Functions
  
• Community Examples Library
  
• LIST() now takes args to initialize the list.
  
• Physics Ticks not Update Ticks
  
• Ability to use SAS modes from KSP 0.90
  
• Blizzy ToolBar Support
  
• Ability to define colors using HSV
  
• Ability to highlight a part in color
  
• Better user interface for selecting boot scripts
  
• Disks can be made bigger with tweakable slider
  
• You Can Transfer Resources
  
• Kerbal Alarm Clock support
  
• Query the docked elements of a vessel
  
• Support for Action Groups Extended
  
• ISDEAD suffix for Vessel
  

This update is so full of new features that instead of describing all of their

details here, you can go see them on the main docs page at the following link:

http://ksp-kos.github.io/KOS_DOC/changes.html

[h=3]Bug Fixes:[/h]

• Using the same FOR iterator in two loops no longer name clashes because it's not global anymore.
  
• Repaired a number of boot file selection bugs.
  
• Removed a few unnecessary debug log spamming message.
  
• Fixed a minor issue with the special hidden file .DS_Store that Macs insert into the Scripts folder.
  
• Fixed bug spamming nullrefs when panel was open in the VAB/SPH editor.
  
• Fixed bugs where setting warp could crash KSP. Now it clamps warp to valid values.
  
• Fixed bug where kOS CPU's were drawing power from the batteries even when the game was paused.
  
• Fixed bug where rate of power consumption varied depending on animation frame rate.
  
• Fixed bug where WAIT 0 crashed scripts. Now WAIT 0 waits the min. possible time (1 physics tick).
  
• Fixed small order of operations problem with expressions containing unary operators like '-', '+', and 'not'.
  
• Fixed problem where SET TARGET didn't really set it until the next physics tick. Now it sets immediately.
  
• Fixed some issues with the use of Action Groups above 10, when Action Groups Extended is installed.
  
• Fixed bug where VOLUME:RENAMABLE returned the name string, rather than a boolean.
  
• Fixed bun when printing a VOLUME to the screen and failing to "stringify" it properly.
  
• Using the unary negation '-' on vectors and directions now works.
  
• Fixed some major bugs in how the kOS toolbar panel was dealing with scene changes and getting "stuck" on screen.
  
• Fixed some bugs with the kos Name Tag typing window getting stuck on screen and locking the user out of the UI.
  
• Fixed bug with reboot not clearing out the state properly.
  
• Fixed bug where any syntax error caught by the compiler resulted in bogus additional second error message.
  

[h=3]BREAKING:[/h]

• RECOMPILE YOUR KSM FILES!!! - If you used the COMPILE command in
  the past, changes to the kOS machine code that were needed to support
  variable scoping ended up invalidating any existing compiled KSM files.
  
• KSM FILES ARE BIGGER - compiled KSM files are now larger than
  they used to be for the same source code. They might not be an
  efficient way to pack your code down to a small disk footprint
  anymore.
  
• CONFIG:IPU should be slightly increased The new default
  we ship with is 200, to reflect both the change in ML code, and the
  movement to Unity's FixedUpdate for physics ticks. However if you
  have played kOS in the past, your settings don't get automatically
  overwritten. You will need to change the setting manually.
  
• DECLARE has a new syntax
  DECLARE VARNAME now requires an initializer syntax as follows:
  
  • DECLARE VARNAME TO VALUE. If you leave the TO VALUE off, it will now be a syntax error. Also, you can say LOCAL or GLOBAL instead of, or in addition to, the word DECLARE.
    

  [*]DECLAREd variables are now local

  Using the DECLARE VARNAME TO VALUE statement now causes the

  variable to have local scope that only exists within the local block

  of curly braces ('{'...'}') that it was declared inside of. To get

  the old behavior you can explicitly say:

  DECLARE GLOBAL VARNAME to _VALUE.

  [*]FOR iterator now is local

  The VARIABLE in loops of the form FOR VARIABLE IN SOMELIST now

  has local scope to just that loop, meaning it stops existing after

  the loop is done and you can't use it outside the loop's body.

Edited April 18, 2015 by erendrake

[Drew Kerman]

I'm dead and gone to heaven

[Paulestrada]

Hi, I'm fairly new to kOS, is there a way to save the code and edit it in notepad or other program?

Edited April 19, 2015 by Paulestrada

[Dunbaratu]

Hi, I'm fairly new to kOS, is there a way to save the code and edit it in notepad or other program?

Outside of KSP, use any text editor like notepad, to write files that end in *.ks into the folder Ships/Scripts that's under your Kerbal Space Program folder. (The folder is outside of GameData because it's your content you created, not the mod's content the devs created).

When you do that, those files can be seen in the game as your "archive" folder, as in SWITCH TO ARCHIVE. or SWITCH TO 0. ('0' and 'archive' mean the same thing).

[Snoman314]

FUNCTIONS!!!!1 WOOOO!!!

Thanks guys!

[trnt]

Sorry for stupid question, but is there any way to make functions like 'swap two values'?

For example I want to make something like this:

If ap < pe swap(ap, pe).

But because of this rue I don't know how to make function swap(a, ..

[Wolf Baginski]

Too late to change, I suppose, but my Naval Syndicate colleagues tell me that "heading" is the direction a ship is pointing and "bearing" is the direction to the target, either relative to the bow, magnetic, or true.

[LN400]

Thanks tons for the new version. Quick test and it seems my boot issue has been completely solved. Awesome work and I can't wait to explore the new features. User defined functions, here I come!

- - - Updated - - -

Thanks tons for the new version. Quick test and it seems my boot issue has been completely solved. Awesome work and I can't wait to explore the new features. User defined functions, here I come!

EDIT: trnt: If I understand your question correctly, you can use a variable (let's call it temp) to temporarily store one of the values, say a, copy a to temp, copy b to a then copy temp to b.

[trnt]

EDIT: trnt: If I understand your question correctly, you can use a variable (let's call it temp) to temporarily store one of the values, say a, copy a to temp, copy b to a then copy temp to b.

Yes I know that but.. What I want to know is, how to make it INTO function of kOS.

For example, Let's define function Swap like this:

Function swap
{
    declare parameter alpha.
    declare parameter beta.
    declare local temp to 0.


    set temp to alpha.
    set alpha to beta.
    set beta to temp.
}

and call it like this:

set a to 1.
set b to 2.


swap(a, .


print a.

Then the result I wish is 2, but actually it prints 1, because changing values in function does not effect the original variable.

Of course, I can make it done using alternative way, like what you said, but I think kOS coding will be much easier if I can make it..

Edited April 19, 2015 by trnt

[Benji]

Hi.

I'm just starting to use kOS. I do, because I want to write a procedure to launch any vessel into kerbins orbit automatically.

Now I was wondering if it's possible to build a rover that drives around on it's own (it definitly is) and reports back if it ends up in an "unsciented" biome. Or even does science on it's own in a new biome.

Can kOS detect a biome in any way? By just checking a "current locations biome" or doing for example a temperature scan every now and then, checking the biome for this experiment?

[Ziw]

It is because non-complex parameters (numbers, strings and such) are passed by value. Only complex parameters (like Vessel, List and such) are passed by reference.

[Dunbaratu]

If ap < pe swap(ap, pe).

Hmm. here's a possible workaround - make it take a single argument which is a list of 2 things. THe list's contents get effectively passed by reference, sort of, that way.

so you make it called like so:

swap( list( ap, pe ) ).

EDIT: I just discovered from a new github issue that apparently the version of the DLL that was released doesn't have the LIST() that takes arguments in it. It is working in the develop source code repository's version so the one that was published must be a day out of date or so from the development one. (The LIST() with arguments was the very last thing changed in the code before we froze.)

We'll have to see if we can get erendrake to update the ZIP file that's on the various sites.

Edited April 19, 2015 by Steven Mading

[trnt]

Hmm. here's a possible workaround - make it take a single argument which is a list of 2 things.

Thanks for reply and after compiling new version myself from source code, I redefined "swap" like this:

function Swap
{
	declare parameter swaplist.
	declare local temp to 0.

	set temp to swaplist[0].
	set swaplist[0] to swaplist[1].
	set swaplist[1] to temp.
}

Is this right? If so, It seems it doesn't work too. I called function like :

set a to 1.
set b to 2.


print a.                       // it of course prints 1.
swap(list(a,).
print a.                       // This command should print 2, but unfortunately it prints 1.


set x to list(a, .
print x[0].                   // it prints 1.
swap(x).
print x[0].                   // finally it prints 2.

Maybe the function only changed the list "list(a,b)". I mean, what were swapped are list(a,[0] and list(a,[1], so now it became list(b, a), which soon disappears. Not a and b.

I think I should give it up now.. It seems to be impossible yet.

[LN400]

I don't know if this is of any use but here is a short code for 2 files, func3a and func3b where 3a is main and 3b has the function.

3a

@lazyglobal off.

run func3b.


declare local a to 1.
declare local b to 2.


print a.
set a to swap().
print a. 

3b

function swap{
declare local temp to 0.


set temp to a.
set a to b.
set b to temp.


return a.
}

EDIT: I'm still a bit curious why the local in main could be manipulated by func3b. Oh well, every day is a chance to learn something.

Edited April 19, 2015 by LN400
Adding the latest.

[thegreatgonz]

NEW VERSION! v0.17.0

Wow, Christmas came really​ early this year...

[frencrs]

Wow, Christmas came really​ early this year...

Seriously!!! Functions man! FUNCTIONS!

[Dunbaratu]

Thanks for reply and after compiling new version myself from source code, I redefined "swap" like this:

function Swap
{
	declare parameter swaplist.
	declare local temp to 0.

	set temp to swaplist[0].
	set swaplist[0] to swaplist[1].
	set swaplist[1] to temp.
}

Is this right? If so, It seems it doesn't work too. I called function like :

set a to 1.
set b to 2.


print a.                       // it of course prints 1.
swap(list(a,).
print a.                       // This command should print 2, but unfortunately it prints 1.


set x to list(a, .
print x[0].                   // it prints 1.
swap(x).
print x[0].                   // finally it prints 2.

Maybe the function only changed the list "list(a,b)". I mean, what were swapped are list(a,[0] and list(a,[1], so now it became list(b, a), which soon disappears. Not a and b.

I think I should give it up now.. It seems to be impossible yet.

Try it again after erendrake makes a patch release. I suspect it might be the out-of-dateness of the ZIP mentioned earlier. We'll see. I'm not on my kerbal computer at the moment so I can't test anything.

[Dr_Goddard]

This is the first part of the code I am porting from C#

Thanks to lunarnexus at:

http://forums.trossenrobotics.com/archive/index.php/t-1605.html

for the original code.

This is for my hexapod robot craft.

With functions it should be possible to make a leg subroutine for each leg. This will greatly simplify the programming required for complex movements.

THIS CODE IS COMPLETELY UNTESTED AND IS PROBABLY FULL OF ERRORS.

declare function FootPosition{
declare x is 0.
declare y is 0.
declare z is 0.
declare coxaAngle is 0.
declare shoulderAngle is 0.
declare elbowAngle is 0.

SET servoGet to ship:partsdubbed("RFFoldatron1 ").
SET servoMods To List(). 
for L In servoGet{servoMods:add(L:getmodule("mumechtoggle"))}.
SET shoulderAngle to servoMods:GETFIELD("Rotation:").
SET radshoulderAngle to (Constant():PI / shoulderAngle * 180).

//value of 2 is random. normally is length of spars, in my case even #s
SET x to 2*SIN(radshoulderAngle).
SET y to 2*COS(radshoulderAngle).

declare ElbowPos2Dx is x.
declare ElbowPos2Dy is y.

SET theta3 to 180 - shoulderAngle.
SET servoGet1 to ship:partsdubbed("RFFoldatron2").
SET servoMods1 To List(). 
for L In servoGet1{servoMods1:add(L:getmodule("mumechtoggle"))}.
SET theta to (servoMods1:GETFIELD("Rotation:") - theta3).
SET radTheta to (Constant():PI / shoulderAngle * 180).

SET x to (2*COS(radTheta)+ElbowPos2Dx).
SET y to (2*SIN(radTheta)+ElbowPos2Dy).

declare FootPos2Dx is x.
declare FootPos2Dy is y.

SET shoulderDistanceOffset to FootPos2Dx.
SET servoGet2 to ship:partsdubbed("RFRotatron").
SET servoMods2 To List(). 
for L In servoGet2{servoMods2:add(L:getmodule("mumechtoggle"))}.
SET coxaAngle to servoMods2:GETFIELD("Rotation:").
SET radCoxaAngle to (Constant():PI / coxaAngle * 180).
SET z to FootPos2Dx * COS(radCoxaAngle).

SET FootPos3D to List().
FootPos3D:ADD(x).
FootPos3D:ADD(y).
FootPos3D:ADD(z).

return FootPos3D.
}.

[leviathan01]

I have a idea for KOS add a default warp command so when the script ends it will set the warp to what default warp was set to, even if the code ends in a error.

[johnsonwax]

Boy, if you can get inverse kinematics working, then manipulator arms get way, way more interesting. Though my guess is you'd still need some kind of bounding box/collision detection as mechjeb docking autopilot has. But still much closer.