kOS Scriptable Autopilot System 0.9

[MSD]

I've used other files/programs as functions, is it possible for a program to have a return value ?

That way we can save on memory space, and all kind of awesome!

None working example:

Printf:

//Working in 0.9.2
DECLARE PARAMETER line.
PRINT "	T+" + round(missiontime) + " " + line.

createNode, executeNode, etc.

Program

target = "mun".

RUN printf("To the mun!").
RUN createNode(target).
RUN executeNode.

WAIT UNTIL SoiChanged.

//continue program. 

The only example here is SoiChanged.

EDIT: mmm... It seems I replied to soon, you can create global variables.

Edited November 13, 2013 by MSD

[Dunbaratu]

EDIT: mmm... It seems I replied to soon, you can create global variables.

In fact, a limitation of the language is that ALL variables are global. Which can be a bit of a problem when trying to write routines to share with other people. You have to warn them "these are the variable names I used. I hope they don't clash with any you used."

[Kerbart]

In fact, a limitation of the language is that ALL variables are global. Which can be a bit of a problem when trying to write routines to share with other people. You have to warn them "these are the variable names I used. I hope they don't clash with any you used."

That's where you have to come up with naming conventions like we did back in the days of Basicode. “All global variables start with ..., all local variables start with ...†You could use the letters G and L for that, but that wouldn't be truly Kerbal of course.

[Dunbaratu]

That's where you have to come up with naming conventions like we did back in the days of Basicode. “All global variables start with ..., all local variables start with ...†You could use the letters G and L for that, but that wouldn't be truly Kerbal of course.

That's exactly what I do. My tfXYZtoENU was written that way with all variables starting with "tf". But that's insufficient if two different people wrote two different subprograms to be later combined together, and one of them took advantage of the persistence of global variables between calls. One of the things local variables do, besides preventing name clashes, is force people to treat the variables as ephemeral and lasting only as long as one pass through the function, unless *explicitly* stated otherwise. The naming convention doesn't fix the problem because the "L" variable you use might be an "L" variable another subprogram uses, and it gets messed up when you change it.

[Dunbaratu]

And the existence of globals, while it does provide a way for a program to give information back to the caller, isn't nearly as nice and clean and intuitive as having actual return values.

This:

 lock steering to run myUpdateSteerFunc.

is way cleaner than:

set resultOfSteerFunc to R(0,0,0). // default starting point.
lock steering to resultOfSteerfunc.
until (something) {
  run steerFunc. // updates resultOfSteerFunc.
}.

Granted, running the subprogram continually in the background (via the lock statement) might be an expensive operation, but it doesn't have to be if it was implemented differently. The KOS computer should parse the program once and store it's pre-parsed version to execute, and then not re-parse it unless the timestamp on the file has been updated since it was last parsed.

Edited November 13, 2013 by Steven Mading

[Sma]

Thanks to the help baloan has provided, I have most of the pieces (almost ready to put them together) to setup my first kerbostationary remotetech network with kOS. I've got a program that get my AP rather close to 2,868.75km, and another one that takes the desired orbital period of 4 hours, works it into a formula that determines that PE needed for a 4hour orbital period, sets it as a node and executes it. I also believe I have another program that I can use on the individual sats to raise their PE to 2,868.75km. The only problem I'm running into may be a kOS/KSP limitation. Ideally I'd like the launcher (which is carrying 3 sats) to be able to automatically deploy each sat when it comes around to AP.

So far in my testing I have the main program copy the individual sat deployment program (they are setup so each sat has a different action group to detach from the launcher and then another to deploy solar panels, though I may switch that to just use panels on. to the individual sats. Then it switches to the first sat and deploys it. Problem is even though its running through the program the panels don't deploy. I guess because the program isn't actually running on that sat after it's been detached from the main craft. Now, if I select the kOS unit on that sat, and run the sat deployment program for that specific one it detaches, focus stays with the main craft and after the given amount of time the solar panels deploy and if I had the circularization program added I imagine it would do that as well.

I guess there is no way right now to make it autonomous the way I want it exactly, unless I'm missing something. It would require some how forcing the program to run on the kOS unit intended. Right now I imagine that the program is running on the launcher kOS unit while connected to the other volume, sort of like using a mapped network drive as opposed to using an SSH shell running on a remote computer. I was hoping to have the whole process from launch to deploy, and then launcher deorbit work by just starting the launcher program while on the pad, but I guess I can't be that lazy yet. lol

[Chestburster]

Is it possible to implement single engine throttle? like main engine is running at 58% while the booster run at 100%? Or is that completely out of the scope of this mod?

[Dunbaratu]

Is it possible to implement single engine throttle? like main engine is running at 58% while the booster run at 100%? Or is that completely out of the scope of this mod?

The mod can only manipulate the controls that exist in the normal game. I don't think this could be possible unless KSP itself provides a way to do that.

[Dunbaratu]

Is anyone else getting the this problem to frequently recur like I am?

I had a script program running on an SCS module on a craft. It doesn't seem to matter what the program was - pretty much any program has the following problem. If the terminal window was ever opened once, and a program had ever been run on the craft, even if it no longer is still running, and the craft goes "on rails" because I went to the tracking center, then ANYTHING that brings the craft back "off rails", whether it's because I select it from the tracking center or because I fly another craft within 2.5 km of it, will make the entire game suddenly BOG down to a standstill, going down to about a 1 FPS framerate, and furthermore it usually triggers the parts disappearing bug (where half the ship is gone but the camera still rotates around where the center of mass WOULD be if the full craft was present - so SOME part of KSP still thinks the rest of the parts are there but you can't manipulate them.) The only way to recover from this is to have had a quicksave you can go back to. The craft is permanently broken in the persistence file at this point.

This seems to happen with great frequency and I don't know why. I suspect it must be something the KOS mod is doing upon loading the vessel into the full physics engine. But it only happens if a program had been run.

So what's different about a SCS part without having run a program and one that had run a program?

The only think I can think of is that if a program had been run, then the mod is probably going to try to remember the state of things - the global variables that have been SET or LOCK'ed. Perhaps its the restoration of those things that makes this problem occur.

I have found that if I turn the SCS module off (via the "toggle power" button) before going on rails, and then power it back on again after coming off from rails, then it doesn't happen. It has to have been turned on when it went onto rails.

Can other people confirm or deny whether they get the same thing happening or is it just me?

[Sma]

Is anyone else getting the this problem to frequently recur like I am?

I had a script program running on an SCS module on a craft. It doesn't seem to matter what the program was - pretty much any program has the following problem. If the terminal window was ever opened once, and a program had ever been run on the craft, even if it no longer is still running, and the craft goes "on rails" because I went to the tracking center, then ANYTHING that brings the craft back "off rails", whether it's because I select it from the tracking center or because I fly another craft within 2.5 km of it, will make the entire game suddenly BOG down to a standstill, going down to about a 1 FPS framerate, and furthermore it usually triggers the parts disappearing bug (where half the ship is gone but the camera still rotates around where the center of mass WOULD be if the full craft was present - so SOME part of KSP still thinks the rest of the parts are there but you can't manipulate them.) The only way to recover from this is to have had a quicksave you can go back to. The craft is permanently broken in the persistence file at this point.

This seems to happen with great frequency and I don't know why. I suspect it must be something the KOS mod is doing upon loading the vessel into the full physics engine. But it only happens if a program had been run.

So what's different about a SCS part without having run a program and one that had run a program?

The only think I can think of is that if a program had been run, then the mod is probably going to try to remember the state of things - the global variables that have been SET or LOCK'ed. Perhaps its the restoration of those things that makes this problem occur.

I have found that if I turn the SCS module off (via the "toggle power" button) before going on rails, and then power it back on again after coming off from rails, then it doesn't happen. It has to have been turned on when it went onto rails.

Can other people confirm or deny whether they get the same thing happening or is it just me?

THat might explain some things...Over the past few days I've started noticing this too. I don't recall experiencing the part disappearing bug before but it's been doing it lately any time I try to load my Remotetech/kos kommsat test vehicle.

Originally it just started as what I thought was part lag and my laptop, although at first it ran semi smooth until I started running a program (had 5 or 6 if not more if statements in a loop), then it seemed to start slowing down more, and stayed slowed down even after the program terminated (either automatically or control c). Then just in the past day or two the part disappearing bug pupped up, which as you said is "fixed" with a quickload, until loading again from the tracking station.

Currently I'm running kOS 9.2 and I believe my remotech version is 1.1.0. Strange though that I haven't experienced this until recently, unless it was some sort of code combination or exception error that causes some kind of corruption in the persistence file but not the save file (I guess presumably because the save was done before the corruption event happened).

[Dunbaratu]

Currently I'm running kOS 9.2 and I believe my remotech version is 1.1.0. Strange though that I haven't experienced this until recently, unless it was some sort of code combination or exception error that causes some kind of corruption in the persistence file but not the save file (I guess presumably because the save was done before the corruption event happened).

I can confirm that remotetech has nothing to do with it, as I get the problem with ONLY KOS and no other mods installed.

And yeah it's just because the quicksave was made before the problem. Quciksaves and persistence files are the same exact thing in the same exact format. The persistence file is just a save that happens automatically at regular intervals and when performing certain actions (like switching to the space center).

I wonder if the mod is perhaps trying to "catch up" in some way when it gets reloaded from rails to full-simulation mode. Imagine if it's trying to go "oh crap I've missed like 3,000 command cycles according to the mission clock, I'd better hurry up and execute them."

(i.e. maybe it's trying to update all the active LOCKs for all the missed time?)

That's pure speculation. I haven't peeked at the C# code in ages. But at any rate the more people who can say they have the problem the more likely it will get attention and be looked at. Up till now I thought it was just me.

And it's definitely not new with 0.92. I first noticed it back in 0.7 and for all I know it was present before then. (I wouldn't know because I hadn't been ever trying to do the things that seem to trigger it until then.)

Edited November 13, 2013 by Steven Mading

[TelluriumCrystal]

I thought it might be a fun idea to see how far people could get using kOS alone to pilot their vessels. So I went ahead and created a challenge for it.

I'm going to leave the link here for anyone who wants to give it a shot (I hope I'm not intruding by doing this): The Automated Mission Challenge

Once again, thanks for making this awesome mod and I hope it continues to grow!

[Camacha]

I have had it happen a couple of times now that I manually entered a command and it would not execute. It often looks like you just typed the wrong syntax and that is sometimes the case, but when I use the up key to enter exactly the same command again, it will work as intended.

There seems to be something off there.

[Dunbaratu]

I have had it happen a couple of times now that I manually entered a command and it would not execute. It often looks like you just typed the wrong syntax and that is sometimes the case, but when I use the up key to enter exactly the same command again, it will work as intended.

There seems to be something off there.

Up-arrow technically doesn't bring up the previous command. It brings up the previous LINE. There's a difference between the two when it's a multi-line command.

I've seen behavior like that when the error was this:

oops this line has no period
lock throttle to 0.5.
(press up-arrow here)
lock throttle to 0.5.

The first one fails because "lock throttle to 0.5" was really part of the poor syntax command: "oops this line has no period\nlock throttle to 0.5.". But when up-arrowing only the last half of the command showed up and was run.

[Camacha]

That would actually make sense, I will check whether that is what is happening.

I think I found a little bug: upon quicksaving, launching the vehicle and quickloading, my program was still there. All the edited out comments were gone though - with empy space where they were before - until I reloaded the program from archive. Happened more than once.

I had another weird thing where any line from a certain program would produce a syntax error, even though it was exactly the same code as before. Whenever I edited something out, the next line would produce the error. Manually entering the same commands would work as intended and other programs with the same commands worked fine too. Making a copy of the broken file in the Archive folder in Windows would not help, this new file produced the same results. I ended up retyping the same code to another program and that fixed it. Not sure where that came from.

Just getting to grips with this language, as I have not had the chance to tinker with it before, so bear with me

Edit: I read back a bit and see the second problem with the syntax error is something that is known.

Edited November 14, 2013 by Camacha

[Draft]

Steven, Sma, it might be that bug with how kOS handles variables in the persistence file. It's an open issue on github, try going through your persistence file manually, searching for 'variables' and getting rid of any strings or scientific notated numbers.

[Dunbaratu]

Does anyone know how the built-in variable "encounter" is supposed to work? I thought it printed the string name of the next upcoming body encounter but it doesn't. Here's a screenshot of what I mean. It's clear from the screenshot that I've got an encounter with the Mun coming up, but "print encounter" still shows "None".

(EDIT: you can't read the text in the screenshot's scaled-down image but you can rightclick it and "view image" to see it at full resolution to read the text.)

Edited November 14, 2013 by Steven Mading
explain getting better resolution on screenshot.

[baloan]

Does anyone know how the built-in variable "encounter" is supposed to work?

encounter works in conjunction with a NODE. IMHO it makes sense to have

SHIP:ENCOUNTER and NODE:ENCOUNTER,

SHIP:ENCOUNTER: PERIAPSIS and NODE:ENCOUNTER: PERIAPSIS,

SHIP:ENCOUNTER: PERIAPSIS:ETA and NODE:ENCOUNTER: PERIAPSIS:ETA

to fine tune injection maneuvers while being out of SOI of the target body.

Easy for Mun equatorial injections, I am wondering what else is need to control a polar orbit injection (or arbitrary inclination injections).

[is there any way to avoid : P to be converted to a in this editor?]

Edited November 14, 2013 by baloan

[Dunbaratu]

encounter works in conjunction with a NODE. IMHO it makes sense to have

SHIP:ENCOUNTER and NODE:ENCOUNTER,

SHIP:ENCOUNTER: PERIAPSIS and NODE:ENCOUNTER: PERIAPSIS,

SHIP:ENCOUNTER: PERIAPSIS:ETA and NODE:ENCOUNTER: PERIAPSIS:ETA

to fine tune injection maneuvers while being out of SOI of the target body.

Easy for Mun equatorial injections, I am wondering what else is need to control a polar orbit injection (or arbitrary inclination injections).

[is there any way to avoid : P to be converted to a in this editor?]

It does seem strange that you can only get the encounter that you MIGHT end up at if you executed a node correctly, but can't get the encounter that you're already on the guaranteed path to if you did nothing from here on out.

It seems like an unnecessary extra step to set an encounter node just to get the encounter name when I don't need the encounter node for the maneuver itself, which I can execute just fine outside of the encounter system.

What I'm trying to do is this:

Step 1. Wait until correct point to start Hohmann transfer (I do the vector math to work this out myself).

Step 2. Start thrusting prograde.

Step 3. Hold the throttle there until I've got an encounter with the Mun.

It looks like I either have to change it to use an manuever node unnecessarily, or I'll just have to wait until my apoapsis is the right height for me to assume I've gotten an encounter, although if I've taken too long to make the burn that assumption may be wrong.

[Sma]

Does anyone know how the built-in variable "encounter" is supposed to work? I thought it printed the string name of the next upcoming body encounter but it doesn't. Here's a screenshot of what I mean. It's clear from the screenshot that I've got an encounter with the Mun coming up, but "print encounter" still shows "None".

**image here**

(EDIT: you can't read the text in the screenshot's scaled-down image but you can rightclick it and "view image" to see it at full resolution to read the text.)

I didn't even know encounter was a thing(guess i need to catch up lol). I'm assuming you tried encounter:eta? or something similar.

[kalizec]

Is anyone else getting the this problem to frequently recur like I am?

I had a script program running on an SCS module on a craft. It doesn't seem to matter what the program was - pretty much any program has the following problem. If the terminal window was ever opened once, and a program had ever been run on the craft, even if it no longer is still running, and the craft goes "on rails" because I went to the tracking center, then ANYTHING that brings the craft back "off rails", whether it's because I select it from the tracking center or because I fly another craft within 2.5 km of it, will make the entire game suddenly BOG down to a standstill, going down to about a 1 FPS framerate, and furthermore it usually triggers the parts disappearing bug (where half the ship is gone but the camera still rotates around where the center of mass WOULD be if the full craft was present - so SOME part of KSP still thinks the rest of the parts are there but you can't manipulate them.) The only way to recover from this is to have had a quicksave you can go back to. The craft is permanently broken in the persistence file at this point.

This seems to happen with great frequency and I don't know why. I suspect it must be something the KOS mod is doing upon loading the vessel into the full physics engine. But it only happens if a program had been run.

So what's different about a SCS part without having run a program and one that had run a program?

The only think I can think of is that if a program had been run, then the mod is probably going to try to remember the state of things - the global variables that have been SET or LOCK'ed. Perhaps its the restoration of those things that makes this problem occur.

I have found that if I turn the SCS module off (via the "toggle power" button) before going on rails, and then power it back on again after coming off from rails, then it doesn't happen. It has to have been turned on when it went onto rails.

Can other people confirm or deny whether they get the same thing happening or is it just me?

Same thing happening here. Checked it out with only KOS installed.

Orbiting a rocket with the KOS part installed but flying it manually is no problem.

Orbiting that same rocket with the KOS part installed, and having it run a script during ascent, results in corrupt saves.

I first bumped into it while decoupling my ascent stage from the orbiter-stage. The orbiter stage has a KOS-part. The ascent stage doesn't.

Switching back and forth between the two stages from map-view causes the bug.

If you then manually edit that save to delete the loaded variables and program the save becomes 'good' again.

Not sure yet whether it is the specific program, the loaded variables or the storing of the program that causes the problem.

How to reproduce:

- Create a rocket with two stages: one ascent stage, one orbiter stage.

- Add a Remote Guidance Unit to both stages.

- Add the KOS-part to the orbiter stage.

- Load a ascend program onto the orbiter.

- Run the program.

- Both stages are now in orbit.

- Decouple the stages.

- Switch to the ascend stage.

- Deorbit the ascend stage.

- Switch back to the orbiter stage.

- Now most parts of the orbiter stage no longer show.

- Save the game anyway.

- Exit KSP.

- Edit the save.

- Lock up the KOS-part.

- Delete the harddisk and variables.

- Start KSP

- Load the save.

- Switch to the orbiter stage.

- Orbiter stage appears normal again.

Possible causes that have been ruled out:

- Other mods (only KOS was installed).

- Bug in KSP itself (doesn't happen when ascending manually)

- Bug in KOS-part (doesn't happen when ascending manually with KOS-part on the craft)

Possible causes not ruled:

- Bug could be specific to the program.

- Bug could be specific to the decoupling.

- Bug could be specific to the on-rails/off-rails switch.

- Bug could be specific to switching between crafts using the Map instead of the Space Center.

- Bug could be specific to the harddrive.

- Bug could be specific to the loaded variables.

Could be I'm seeing:

https://github.com/Nivekk/KOS/issues/220

Edited November 14, 2013 by kalizec

[kalizec]

Is anyone else getting the this problem to frequently recur like I am?

I had a script program running on an SCS module on a craft. It doesn't seem to matter what the program was - pretty much any program has the following problem. If the terminal window was ever opened once, and a program had ever been run on the craft, even if it no longer is still running, and the craft goes "on rails" because I went to the tracking center, then ANYTHING that brings the craft back "off rails", whether it's because I select it from the tracking center or because I fly another craft within 2.5 km of it, will make the entire game suddenly BOG down to a standstill, going down to about a 1 FPS framerate, and furthermore it usually triggers the parts disappearing bug (where half the ship is gone but the camera still rotates around where the center of mass WOULD be if the full craft was present - so SOME part of KSP still thinks the rest of the parts are there but you can't manipulate them.) The only way to recover from this is to have had a quicksave you can go back to. The craft is permanently broken in the persistence file at this point.

This seems to happen with great frequency and I don't know why. I suspect it must be something the KOS mod is doing upon loading the vessel into the full physics engine. But it only happens if a program had been run.

So what's different about a SCS part without having run a program and one that had run a program?

The only think I can think of is that if a program had been run, then the mod is probably going to try to remember the state of things - the global variables that have been SET or LOCK'ed. Perhaps its the restoration of those things that makes this problem occur.

I have found that if I turn the SCS module off (via the "toggle power" button) before going on rails, and then power it back on again after coming off from rails, then it doesn't happen. It has to have been turned on when it went onto rails.

Can other people confirm or deny whether they get the same thing happening or is it just me?

Having the same problem. (Not the FPS issues, but definitely the parts disappearing bug.)

I've narrowed it down to having a KOS-program loaded while switching between craft.

How to reproduce:

- KSP + KOS (no other mods)

- Two stage rocket with KOS module in second stage and both stages having a Remote Guidance Unit.

If you orbit that rocket manually, then seperate the stages and switch between them, nothing happens.

If you orbit that rocket using a program, then seperate the stages and switch between them, the bug occurs.

If you then edit your savegame and remove the variables and stored programs from the KOS part, the bug disappears.

Not sure yet whether it's the stored variables, the locked steering, the powered on KOS-part, the stored programs, or the specific program that's the problem.

[Sacred Aardvark]

[is there any way to avoid : P to be converted to a in this editor?]

Go Advanced, scroll down to Additional Options and tick "disable smilies in text" and it shouldn't

[TelluriumCrystal]

I am having some strange issues, and may have run into a bug. The following happens after I launch my rocket into orbit using a kOS program I wrote:

run BOdeorbit.
Error on line 2: Syntax Error.

The code of the program "BOdeorbit" is as follows:

// This should deorbit the [AUTO] Basic Orbiter

print "Beginning deorbit burn".
lock STEERING to RETROGRADE.
wait 3.
set x to 0.
until x > 1 {
lock THROTTLE to x.
set x to x + 0.05.
wait 0.01.
}
lock THROTTLE to 1.
wait until PERIAPSIS < 0.
lock THROTTLE to 0.
unlock STEERING.

wait until ALTITUDE < 45000.
toggle AG1.
print "Retracting solar panels".

wait until ALT:RADAR < 5000.
stage.
print "Parachute deployed".

wait until ALT:RADAR < 10.
print "Touchdown imminent".

wait 5.

Am I missing something here?

[Skyfoxyz]

missed "." (dot) in line 10

}.