[1.3] kOS Scriptable Autopilot System v1.1.3.0

oliverjrose99 · April 6, 2015

You have to click the "go advanced" button when editing, and there will be an option to disable smileys. Franky, I think that's utterly backward. Actually showing the text you *really did* type is what I'd call basic vanilla mode and invoking the option to do something fancy with it is what' I'd call "advanced". Not the other way around.

Thanks. any idea how to fix my part problem?

ThreePounds · April 7, 2015

Hello! I've been playing around with kOS last night and wrote a few test scrips to get a feeling for how they are written. I have come across an issue when writing a simple logging script which writes altitude and speed to a file every second.

Is there a way to tell a script to listen to user input? My program is a loop (UNTIL FALSE {}). The only way to terminate it is ctrl+c, which isn't very elegant. So how do you terminate, lets say an auto-pilot which keeps altitude constant?

As far as user input goes, is running a program with parameter input (or setting global values before executing it) the only way to feed data to the computer? Is there a way for the script to request user input? ("Here is a list of possible options." Type 1 for option 1 etc.)

Is there an option to auto-execute a command upon boot? This would be useful to have a probe continue with a script / attempting to re-establish communications after an power-outtage.

Is there an option to write information to disk for later access? All I can think of is using the "LOG" command to write something like "LOG "SET variabletostore TO " + variabletostore TO storage.ks" and then running the storage script to get it back. This would be useful if a probe is powered down to sleep and upon waking up can read mission parameters from disk.

Edited April 7, 2015 by Three_Pounds

LN400 · April 7, 2015

Hello! I've been playing around with kOS last night and wrote a few test scrips to get a feeling for how they are written. I have come across an issue when writing a simple logging script which writes altitude and speed to a file every second.
Is there a way to tell a script to listen to user input? My program is a loop (UNTIL FALSE {}). The only way to terminate it is ctrl+c, which isn't very elegant. So how do you terminate, lets say an auto-pilot which keeps altitude constant?
As far as user input goes, is running a program with parameter input (or setting global values before executing it) the only way to feed data to the computer? Is there a way for the script to request user input? ("Here is a list of possible options." Type 1 for option 1 etc.)
Is there an option to auto-execute a command upon boot? This would be useful to have a probe continue with a script / attempting to re-establish communications after an power-outtage.
Is there an option to write information to disk for later access? All I can think of is using the "LOG" command to write something like "LOG "SET variabletostore TO " + variabletostore TO storage.ks" and then running the storage script to get it back. This would be useful if a probe is powered down to sleep and upon waking up can read mission parameters from disk.

Hello, I am new to this place and just came across this post. I just recently started looking at KOS so there are quite possibly better solutions than this but I have made a program, "term", that lets me store 2 3-digit numbers in a "verb/noun" way, kinda like the Apollo style, using 2 of the action groups (just 2 for now since it's only a test) for inputs. So I end up with a total of 64 combinations that could be "if"-ed to run various other programs, functions etc. It's not really optimal as I need to set aside 2 of the 10 AG's for this when running the script but as a nice side effect, I get to use the Raster Prop Monitor MkI pod IVA's AG buttons as input keys, which is kinda neat.

The whole script is really a test of various ideas so it's not aimed at being optimal but it might give you an idea how to have a UI with that program.

Mind you it's rather large but by removing all newlines, spaces that are not needed, removing comments and cutting down the variable names, you can shave off quite a lot and again, this is just a test of varius ideas so any tips on improvements would be greatly appreciated.

clearscreen.unset all.


//this sets up a fake 'shift register' memory.
declare store_value.//value to be stored in register cell 0 (store:z).
set store to v(0,0,0).//fake 3 cell shift register memory
set store_count to 1.
set store_en to false.//enable storing to shift register
set sum1 to 0.//decimal interpretation of first 3 digits in shift register.
set sum2 to 0.//decimal interpretation of next 3 digits in shift register.


set exe to false.//enabled when prog and mode set.
set prg to 1.//0 error 1 nominal


ag1 off.
ag2 off.


trig on.
set prog to true.


until prog = false
{
	if trig
	{
		trig off.


		on ag1
		{
			set store_value to 1.
			set store_en to true.
			trig on.
			ag1 off.
		}


		on ag2
		{
			set store_value to 2.
			set store_en to true.
			trig on.
			ag2 off.
		}
	}


	if store_en = true
	{
		//shift logic.		
		set store:x to store:y.
		set store:y to store:z.
		set store:z to store_value.


		if store_count = 3//interprets the stored digits and sets(sum1) which program to run.
		{
			set sum1 to 100*store:x+10*store:y+store:z.


			print "V "+sum1 at (0,8).


			if sum1 = 111
			{
				print "PRG1" at (7,8).
			}
			else if sum1 = 112
			{
				print "PRG2" at (7,8).
			}
			else if sum1 = 121
			{
				print "PRG3" at (7,8).
			}
			else if sum1 = 222
			{
				clearscreen.
				print "Shutting down..." at (0,8).
				wait 1.
				set prog to false.
			}
			else
			{
				set prg to 0.
				print "INVL" at (7,8).
			}
		}


		else if store_count = 6//interprets the next 3 digits and sets (sum2) which mode to run.
		{
			set sum2 to 100*store:x+10*store:y+store:z.
			print "N "+sum2 at (0,9).

			if sum2 = 122
			{
				//set exe to true.
				print "MOD1" at (7,9).
			}
			else if sum2 = 121
			{
				//set exe to true.
				print "MOD2" at (7,9).
			}
			else if sum2 = 212
			{
				//set exe to true.
				print "MOD3" at (7,9).
			}

			else
			{
				set prg to 0.
				print "INVL" at (7,9).
			}


			set store_count to 0.
			wait 0.1.
		}


		if prg = 0//if invalid program or mode selected
		{
			wait 0.7.
			clearscreen.
			set prg to 1.
			set store to v(0,0,0).
			set store_count to 0.
		}


		set store_count to store_count+1.			
		set store_en to false.
	}


	print store:x at (0,6).
	print store:y at (2,6).
	print store:z at (4,6).	
}


unset store_value.
unset store.
unset store_count.
unset store_en.
unset exe.
unset prg.
unset sum1.
unset sum2.
clearscreen.

Dunbaratu · April 7, 2015

The short answer is that kOS doesn't implement input streams from the user yet. You can only get sort of kludge solutions involving using the action groups.

I'd like to fix it but fixing the annoying presumed global-ness of everything was higher on my list - and it's thorny because it looks like it inevitably results in breaking some backward compatibility because the original language design had some annoying presumptions hardcoded into its design.

akrasuski1 · April 7, 2015

Some weird stuff is going on with ship:control. Consider the following command:

SET ship:control:pitch to 0.

Then, nothing happens (as expected). If I press W, I can normally control my ship (it rotates). But if I type:

SET ship:control:pitch to 0.02.

Then, the ship starts to very slowly accelerate (also, as expected). But now, I'm locked out of control of the ship. I don't think this is consistent behaviour. Normally this wouldn't be a problem, since usually you want to control to be either yours or script's (with you not touching the controls at all). But I want to use WASD input (using pilotpitch, etc. sufixes) to control some things in kOS without rotating my ship at all. I already tried neutralizing input from script in a few combinations, and setting pitch to 0 (as above). Due to the above "undocumented behaviour", I don't think I'm able to lock manual steering. Any way to do that?

Also, as a side thing, printing ship:control:pilotneutral yields True or False, while printing ship:control:neutral gives "kOS.Safe.Utilities.Flushable`i[system.Boolean]]" whatever it means.

EDIT:

As a workarond, I can use "lock steering to ship:facing" which will lock any user WASD input from triggering rotation. Still, this is just a workaround.

Edited April 7, 2015 by akrasuski1

akrasuski1 · April 7, 2015

Sorry for a double post, but I want to separate this (my creation) from the issues described above.

I created a nice small utility that enables people to input numbers to their scripts - for example, you can ask to enter desired apoapsis and such. The second script is similar, but instead creates a menu to be chosen from. Since we don't have functions yet, they are still made as scripts, but when functions come, it would be trivial to rewrite it for the new function syntax.

1. Numpad:

// This script shows a numpad on the terminal allowing user to
// type in any number (including floating point ones) and return
// it to calling script.
clearscreen.
set finished to false.
set number_so_far to 0.
set dot_encountered to 0.
set digits_so_far to 0.
set current_x to 0.
set current_y to 0.
set was_pause to true.
lock steering to ship:facing.
//print calculator once
print "+===================+" at (0,0).
print "|                   |" at (0,1).
print "|                   |" at (0,2).
print "|                   |" at (0,3).
print "+===================+" at (0,4).
print "|                   |" at (0,5).
print "| +---+---+---+---+ |" at (0,6).
print "| |   |   |   |   | |" at (0,7).
print "| | 7 | 8 | 9 | C | |" at (0,8).
print "| |   |   |   | l | |" at (0,9).
print "| +---+---+---+ e | |" at (0,10).
print "| |   |   |   | a | |" at (0,11).
print "| | 4 | 5 | 6 | r | |" at (0,12).
print "| |   |   |   |   | |" at (0,13).
print "| +---+---+---+---+ |" at (0,14).
print "| |   |   |   |   | |" at (0,15).
print "| | 1 | 2 | 3 |   | |" at (0,16).
print "| |   |   |   |   | |" at (0,17).
print "| +---+---+---+   | |" at (0,18).
print "| |   |   |       | |" at (0,19).
print "| | . | 0 | Enter | |" at (0,20).
print "| |   |   |       | |" at (0,21).
print "| +---+---+-------+ |" at (0,22).
print "|                   |" at (0,23).
print "+===================+" at (0,24).
print "|                   |" at (0,25).
print "| Outside terminal, |" at (0,26).
print "| press:            |" at (0,27).
print "|                   |" at (0,28).
print "| - WASD to move    |" at (0,29).
print "| - E to select     |" at (0,30).
print "|                   |" at (0,31).
print "+===================+" at (0,32).
until finished{ 
    //only update important bits
    wait 0.001.
    print "|                   |" at (0,2).
    print "| |   |   |   |   | |" at (0,7).
    print "| | 7 | 8 | 9 | C | |" at (0,8).
    print "| |   |   |   | l | |" at (0,9).
    print "| +---+---+---+ e | |" at (0,10).
    print "| |   |   |   | a | |" at (0,11).
    print "| | 4 | 5 | 6 | r | |" at (0,12).
    print "| |   |   |   |   | |" at (0,13).
    print "| |   |   |   |   | |" at (0,15).
    print "| | 1 | 2 | 3 |   | |" at (0,16).
    print "| |   |   |   |   | |" at (0,17).
    print "| +---+---+---+   | |" at (0,18).
    print "| |   |   |       | |" at (0,19).
    print "| | . | 0 | Enter | |" at (0,20).
    print "| |   |   |       | |" at (0,21).
    print number_so_far at (10-floor(digits_so_far/2+0.001),2).

    //print selection around current key
    if current_x=3 {
        if current_y=1{
            print "+-+" at(15,7).
            print "|C|" at(15,8).
            print "|l|" at(15,9).
            print "|e|" at(15,10).
            print "|a|" at(15,11).
            print "|r|" at(15,12).
            print "+-+" at(15,13).
        }
        else{
            print     "+-+" at(15,15).
            print     "| |" at(15,16).
            print     "| |" at(15,17).
            print     "| |" at(15,18).
            print "+---+ |" at(11,19).
            print "|Enter|" at(11,20).
            print "+-----+" at(11,21).
        }
    }
    else{
        print "+-+" at(4*current_x+3,4*current_y+7).
        print "|" at(4*current_x+3,4*current_y+8).
        print "|" at(4*current_x+5,4*current_y+8).
        print "+-+" at(4*current_x+3,4*current_y+9).
    }
    //input from user
    set going_up to -(SHIP:CONTROL:PILOTPITCH).
    set going_right to SHIP:CONTROL:PILOTYAW.
    set push to SHIP:CONTROL:PILOTROLL.

    set key_pressed_now to false.
    if going_up<-0.5 or going_up>0.5 or going_right>0.5 or going_right<-0.5 or push>0.5{
        set key_pressed_now to true.
    }
    if not key_pressed_now{
        set was_pause to true.
    }
    else if was_pause{
        //only allow button press after at least a frame without button
        set was_pause to false.
        if going_up>0.5{
            set current_y to current_y-1.
        }
        else if going_up<-0.5{
            set current_y to current_y+1.
        }
        if going_right>0.5{
            set current_x to current_x+1.
        }
        else if going_right<-0.5{
            set current_x to current_x-1.
        }
        //boundary checks:
        if current_x<0{
            set current_x to 0.
        }
        if current_x>3{
            set current_x to 3.
        }
        if current_y<0{
            set current_y to 0.
        }
        if current_y>3{
            set current_y to 3.
        }
        //check for clear
        if current_x=3 and current_y<=1{
            set current_y to 1.
        }
        //check for enter
        if current_x=3 and current_y>1{
            set current_y to 2.
        }
        if current_x=2 and current_y=3{
            set current_y to 2.
            set current_x to 3.
        }
        //done with moving.
        //now check if key is pressed
        if push{
            if current_x=3 and current_y=1{//clear
                set number_so_far to 0.
                set dot_encountered to 0.
                set digits_so_far to 0.
            }
            else if current_x=3 and current_y=2{//enter
                set finished to true.
            }
            else if current_x=0 and current_y=3{//dot
                set dot_encountered to 1.
                set digits_so_far to digits_so_far+1.
            }
            else{//digit
                set digits_so_far to digits_so_far+1.
                set digit to 0.
                if current_x=0 and current_y=0{set digit to 7.}
                if current_x=1 and current_y=0{set digit to 8.}
                if current_x=2 and current_y=0{set digit to 9.}
                if current_x=0 and current_y=1{set digit to 4.}
                if current_x=1 and current_y=1{set digit to 5.}
                if current_x=2 and current_y=1{set digit to 6.}
                if current_x=0 and current_y=2{set digit to 1.}
                if current_x=1 and current_y=2{set digit to 2.}
                if current_x=2 and current_y=2{set digit to 3.}
                if dot_encountered=0{
                    set number_so_far to number_so_far*10+digit.
                }
                else{
                    set number_so_far to number_so_far+digit*0.1^dot_encountered.
                    set dot_encountered to dot_encountered+1.
                }
            }
        }
    }
}


clearscreen.
unlock steering.
set retVal to number_so_far.

2. Menu:

// This script shows a simple menu on the terminal allowing user to
// select one of the options and return its index to calling script.
declare parameter list_of_names.


set current_option to 0.
set len to list_of_names:length().
set finished to false.
set was_pause to true.
lock steering to ship:facing.


clearscreen.
print "+================Menu================+" at(0,0).
set i to 0.
until i=len+2{
    print "|                                    |" at(0,i+1).
    set i to i+1.
}
print "+====================================+" at(0,len+3).
print "|                                    |" at(0,len+4).
print "| Use W/S outside terminal to move   |" at(0,len+5).
print "| and E to select an option.         |" at(0,len+6).
print "|                                    |" at(0,len+7).
print "+====================================+" at(0,len+8).


until finished{
    wait 0.001.
    //print list
    set i to 0.
    until i=len{
        if i=current_option{
            print " ===> " + list_of_names[i] + " <===" at(2,i+2).
        }
        else{
            print "    - " + list_of_names[i] + " -   " at(2,i+2).
        }
        set i to i+1.
    }
    //get input
    set going_up to -(SHIP:CONTROL:PILOTPITCH).
    set push to SHIP:CONTROL:PILOTROLL.

    set key_pressed_now to false.
    if going_up<-0.5 or going_up>0.5 or push>0.5{
        set key_pressed_now to true.
    }
    if not key_pressed_now{
        set was_pause to true.
    }
    else if was_pause{
        //only allow button press after at least a frame without button
        set was_pause to false.
        if going_up>0.5{
            set current_option to current_option-1.
        }
        if going_up<-0.5{
            set current_option to current_option+1.
        }
        if(current_option<0){
            set current_option to 0.
        }
        if(current_option>len-1){
            set current_option to len-1.
        }
        if push{
            set finished to true.
        }
    }
}


clearscreen.
unlock steering.
set retval to current_option.

I don't think there's currently any way to provide direct input to kOS, so instead I made user select options or move around the numpad via their WASD keys and use E as Enter key.

Images:

Note: if the code doesn't work for you, make sure you aren't in docking mode - I thought there's a bug in my code for over an hour due to that.

Edited April 7, 2015 by akrasuski1

Reisdal · April 8, 2015

could someone please help me. I had a launch script which worked perfectly fine but when i edited it as a new script to take me up to a geosych apoapsis it says program ended just after the print "launch". what is wrong? tried everything it seems...

here's the script: http://pastebin.com/1XYB0sK8

PS. just so you know, I'm a novice at scripting

ThreePounds · April 8, 2015

Thanks for the answers concerning user input and data storage. You've presented me with new and exciting workarounds that seem extremely smart to me. I'm still wrapping my head around both of them.

I have made my first simple launch script. The script works fairly well but it's really only good for launching the exact type of vehicle I am using.

//Zephyrus launch script intended to be used by Triton craft//script assumes two solid stages with a liquid stage motor
//but may support different Zephyrus configurations in the future.
clearscreen. unset all.


//declaring triggers
declare complete.
declare guidetrigger.


//loading script dependencies
copy triton.apcirc.ks from 0.
copy triton.exenode.ks from 0.
print "script dependencies loaded.".


complete off.


//launch countdown
print "initiating launch countdown".
set countdown to 5.
until countdown = 0 {
    print "..." + countdown.
    set countdown to countdown - 1.
    wait 1.
    }
print "launch!".
stage.


//staging control
when stage:solidfuel = 0 then {
    set guidetrigger to ship:solidfuel.    
    print "detecting resource depletion. staging.".
    stage.
    when stage:solidfuel = 0 then {
        print "detecting resource depletion. staging.".
        stage.
        when ship:altitude > 70000 then {
            print "detecting safe altitude. deploying antenna".
            lights on.
            stage.
            }
        }
    }

//steering control
when stage:number = 3 AND stage:solidfuel < 0.5 * guidetrigger then    {
    print "locking steering to velocity vector".
    lock steering to ship:velocity:orbit.
        //final guidance
    when ship:altitude > 40000 then {
        print "locking steering to east".
        lock steering to heading(90,0).
        }
    }


//thrust control
when ship:obt:apoapsis < 70000 then {
    print "locking throttle to 100%".
    lock throttle to 1.
    when ship:obt:apoapsis > 70000 then {
        print "locking throttle to 30%.".
        lock throttle to 0.3.
        when ship:obt:apoapsis > 80000 then {
            print "shutting down engines.".
            lock throttle to 0.
            complete on.
            }
        }
    }


wait until complete.
wait 3.
print "executing triton.apcirc.ks script".
run triton.apcirc.ks.
print "executing triton.exenode.ks script".
run triton.exenode.ks.
print "target orbit reached.".

However, once it gets to this "run triton.apcirc.ks." part, it throws an error at me:

Undefined Variable Name Ã‚Â´program-triton.apcirc.ks*Ã‚Â´.

it does not print anything else. (The verbose version is an exact copy of the above error.)

So far I have had no luck in narrowing down the problem:

this problem does not occur when I paste the 6 lines into a separate script and execute it mid-flight
this problem does occur when I load the embedded script into memory before starting the main script.
this problem does occur when I use or not use parameters to call the embedded script.

After nearly three hours of trying different stuff I have no idea what is going on any more. Can someone help?

- - - Updated - - -

could someone please help me. I had a launch script which worked perfectly fine but when i edited it as a new script to take me up to a geosych apoapsis it says program ended just after the print "launch". what is wrong? tried everything it seems...
here's the script: http://pastebin.com/1XYB0sK8
PS. just so you know, I'm a novice at scripting

Your script is basically a short loop (launch countdown) and a whole bunch of triggers and one check at the end. There is nothing stopping the script from ending once it reaches the bottom. You need to either put in a "WAIT UNTIL false." or at least set up a trigger variable at the very end.

Blu_C · April 8, 2015

I have just started using kOS and am building a fairly simple launch script and am running into a very strange problem. Everything works perfectly up until the current stage runs out of fuel and the program goes to stage. At this point for whatever reason the staging logic never happens. Here is the code I've written to handle the situation:


if STAGE:LIQUIDFUEL < 0.1 { //Stage fuel exhausted.
     lock throttle to 0.
     stage.
     wait 2.                //Wait for stage separation.
     lock throttle to TVAL.
}

Note that this snippet of code happens inside the main (and only) while loop that runs for the duration of my launch, which is why it doesn't have PRESERVE. In any case, I do not think the lack of PRESERVE is the cause because it isn't even staging once.

From what I can tell, for some reason KSP or kOS (or both) is misreading the amount of fuel remaining in the stage. I was able to verify this by looking at the resources with the STAGE ONLY flag set. For some reason the value of fuel always includes the current stage AND the next stage. Initially I thought this was because of some faulty logic dealing with radial stages and tried to rebuild using only vertical decouplers which worked for my first test run, but then after redesigning the initial lift stage I found the problem returned.

Has anyone else encountered this problem? Is there a solution or a problem with how I am approaching staging code/building my rocket which causes the issue to occur?

Edited April 8, 2015 by Blu_C

Tabris · April 9, 2015

I have just started using kOS and am building a fairly simple launch script and am running into a very strange problem. Everything works perfectly up until the current stage runs out of fuel and the program goes to stage. At this point for whatever reason the staging logic never happens. Here is the code I've written to handle the situation:
if STAGE:LIQUIDFUEL < 0.1 { //Stage fuel exhausted.
     lock throttle to 0.
     stage.
     wait 2.                //Wait for stage separation.
     lock throttle to TVAL.
}
Note that this snippet of code happens inside the main (and only) while loop that runs for the duration of my launch, which is why it doesn't have PRESERVE. In any case, I do not think the lack of PRESERVE is the cause because it isn't even staging once.
From what I can tell, for some reason KSP or kOS (or both) is misreading the amount of fuel remaining in the stage. I was able to verify this by looking at the resources with the STAGE ONLY flag set. For some reason the value of fuel always includes the current stage AND the next stage. Initially I thought this was because of some faulty logic dealing with radial stages and tried to rebuild using only vertical decouplers which worked for my first test run, but then after redesigning the initial lift stage I found the problem returned.
Has anyone else encountered this problem? Is there a solution or a problem with how I am approaching staging code/building my rocket which causes the issue to occur?

it's a known bug due to how kOS gets the data about stages.

this is the code that i use


LIST ENGINES IN engines.
    FOR eng IN engines
    {
        IF eng:FLAMEOUT
        {
            STAGE.
            WAIT 0.1.
            BREAK.
        }
    }
    WHEN SHIP:LIQUIDFUEL < 1 THEN
    {
        clearscreen.
        PRINT "Out of Fuel".
        PRINT "Terminating Program".
        set mode to 0.
    }

TDW · April 9, 2015

However, once it gets to this "run triton.apcirc.ks." part, it throws an error at me:
Undefined Variable Name Ã‚Â´program-triton.apcirc.ks*Ã‚Â´.
it does not print anything else. (The verbose version is an exact copy of the above error.)
So far I have had no luck in narrowing down the problem:

This looks like the same issue as here:

https://github.com/KSP-KOS/KOS/issues/745

Remove the unset all. command from the script and it should work.

From what I can tell, for some reason KSP or kOS (or both) is misreading the amount of fuel remaining in the stage.
[...]
Has anyone else encountered this problem? Is there a solution or a problem with how I am approaching staging code/building my rocket which causes the issue to occur?

From several pages back.

Here's one possible staging script:




set stagemaxthrust to ship:maxthrust.
when status <> "PRELAUNCH" and (ship:maxthrust<stagemaxthrust or ship:maxthrust<1) then {
    print "Stage!".
    stage.
    set stagemaxthrust to ship:maxthrust.
    preserve.
}

DrMax · April 9, 2015

I registred on this forum only so I could write this message full of love and respect for your work and that of your predecessors.

I love programming, I love KSP, and so I love this, thank you !

Blu_C · April 9, 2015

Thanks for the help. Ended up fixing it with the following code (that in retrospect I suspect is better than what I had originally since it should work with SRB's too):


set maxT to SHIP:MAXTHRUST

(logic foo)

IF SHIP:MAXTHRUST < maxT {
          lock throttle to 0.
          STAGE.
          set maxT to SHIP:MAXTHRUST.
          WAIT 2.
          lock throttle to TVAL.
}

Reisdal · April 9, 2015

@Three Pounds

Thanks! I cleaned up the script aswell as taking out the countdown, put a wait until false in the end and it works! Can I somehow end a program via the script or do I have to break it manually after a wait until false?

TDW · April 9, 2015

Can I somehow end a program via the script or do I have to break it manually after a wait until false?

If at the start of the script you do [declare done to false.] Then you can use [wait until done.] and have the finish condition include the statement [set done to true.].

Reisdal · April 9, 2015

@TDW

Where should I put wait until done? In the end before set done to true?

TDW · April 9, 2015

@Reisdal

Use wait until done as a direct replacement for wait until false. (I'm guessing at the end of your script) the set done to true needs to go above it inside whatever trigger you want to end the script.

ThreePounds · April 9, 2015

@TDW
Where should I put wait until done? In the end before set done to true?

My scripts usually look like this:


DECLARE complete.
complete OFF.
{stuff happening}
//this is the last trigger for the last action of all the actions expected of the script
WHEN {last condition} THEN {{last action} complete ON.}
WAIT UNTIL complete.
//end of script.

If you want an example, check the last page. Look for the above lines (you can use ctrl+F on your keyboard).

TDW · April 9, 2015

With the new access to the right click menu is there a way of reading an actions current state? it can be set with module:doaction(name,bool) and i can read fields with module:getfield(name) but as far as I can tell there is no module:getaction(name) to return the current bool state of an action. eg. no way for 1 cpu to see if another cpu is powered on or off.

Edit:

Also actions that are also listed as events (eg. "toggle power" on "kosprocessor") for a part module seem to toggle no matter what is set:


set cpuList to ship:modulesnamed("kospsocessor").
cpuList[0]:doaction("toggle power",false).  //this will shut down the processor.
cpuList[0]:doaction("toggle power",true).  //this will also shut down the processor.

Edited April 9, 2015 by TDW

ThreePounds · April 9, 2015

Also actions that are also listed as events (eg. "toggle power" on "kosprocessor") for a part module seem to toggle no matter what is set:
set cpuList to ship:modulesnamed("kospsocessor").
cpuList[0]:doaction("toggle power",false).  //this will shut down the processor.
cpuList[0]:doaction("toggle power",true).  //this will also shut down the processor.

Isn't that exactly what toggle is? :huh:

- - - Updated - - -

This looks like the same issue as here:
https://github.com/KSP-KOS/KOS/issues/745
Remove the unset all. command from the script and it should work.

Thank you so much! You literally turned kOS around from "maybe I should uninstall this ..." to "wow, I'm so happy with it."

I can get easily frustrated after toying with something for hours and not achieving anything.

This is actually a quite evil bug because normally when I have code misbehaving, my first action is to increase it's unambiguousness. Removing "unset all." would have been the very last step in stripping the script down to find the error.

Diazo · April 9, 2015

Isn't that exactly what toggle is?

The issue is that you can "activate" or "deactivate" an action.

What TDW is asking is "Why does activating the toggle action turn the processor off?" when TDW is expecting that to do nothing because the processor is already activated (so turning on an object that is already on should do nothing).

The issue is that there are two schools of though around this:

1) Activating a Toggle action is a "Turn On" command, deactivating a toggle action is a "Turn Off" command.

2) Activating/Deactivating the toggle command does not matter, when the toggle command is executed, it changes the state of the associated action. (So "toggle-activating" an already running object means deactivating it.)

In this case, the kOS Processor "Toggle Power" will switch state regardless of if it's told to activate or deactivate. (Type 2 on the list above.)

It is a matter of opinion how this should work, but that is why this is happening.

D.

Edited April 9, 2015 by Diazo

TDW · April 9, 2015

Isn't that exactly what toggle is?

Yep that's what toggle means, but it's name is just a string and could be anything. The bit that's confusing me is that it is toggle power is turning up in both the event list and the action lists for the module. As I understood it form the docs events were just toggle-able (as you only specify a name) where as actions where settable as you had to specify a name and a state.

What I am trying to do is turn other cores on and off from a master core. By adding a boot file to all volumes containing the command [log 1 to flag.ks.] then rebooting the cores 1 at a time to find the volume containing the flag. Write a file in it called my_name.ks that contains [set name to //the corresponding part tag//.]. Repeat this process with all cores so that all volumes contain a file that connects the volume with the part.

The master core is selected by a random number race the losers all turn off. This was intended to allow the master to identify it's self as the only one still running. however unless i can find a way to read the power state of the cpu I will need to think of something else.

Dunbaratu · April 9, 2015


cpuList[0]:doaction("toggle power",false).  //this will shut down the processor.
cpuList[0]:doaction("toggle power",true).  //this will also shut down the processor.

Out of curiosity, what do you get if you keep giving it the same state over and over:


cpuList[0]:doaction("toggle power",true).
wait 1.
cpuList[0]:doaction("toggle power",true).
wait 1.
cpuList[0]:doaction("toggle power",true).
wait 1.

or:


cpuList[0]:doaction("toggle power",false).
wait 1.
cpuList[0]:doaction("toggle power",false).
wait 1.
cpuList[0]:doaction("toggle power",false).
wait 1.

I suspect it *needs* the state to change to notice anything happened, but that once the state changes the thing that happens is just a call to the toggle, which does a toggle, not an absolute set.

I blame KSP itself. It implemented action groups first for stuff like Lights, Gear, and so on -things for which having two boolean states makes sense. But then it added the ability to make your own action groups for which you just fire-once, but piggybacked that on the same system as for things it makes logical sense to have two states - so you now have actions triggered by changing a state of the GROUP, which then trigger a method that itself changes a state with a toggle, making it possible for the two to become out of sync in what they mean.

TDW · April 9, 2015

Out of curiosity, what do you get if you keep giving it the same state over and over:

it just toggles the power on and off in both cases.

Warp11 · April 10, 2015

Is it possible to get the programming functions on a craft that's already in flight? I'd like to use it in an existing save. I tried copying the processor module from the mod parts but it didn't work.

Thx for you help. Awesome mod.

[1.3] kOS Scriptable Autopilot System v1.1.3.0

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites