kOS Scriptable Autopilot System 0.9

[Dunbaratu]

Edit: Did someone else recognized that print at now works with variables?

Kevin's been making some changes to try to make it so that expressions work universally the same everywhere instead of this weird thing where valid expressions are recognized in SET statements but not in other places. I suspect this ended up being part of that. Once PRINT AT is changed to expect (expr,expr) instead of (num,num) then you get the use of variables for "free" with that.

[Dunbaratu]

In numerous examples and code the ON command has been used wrongly.

Very Wrongly.

I suspected it didn't make sense how people were using it when I first saw it but since everyone was already doing things this way I assumed it must just not work the way I intuitively guessed it did. A recent issue raised in the github made me go back and revisit that assumption. I started suspecting again that my original suspicions were right, given a complaint about how loops get very slow and memory usage leaks when a loop has an ON statement in it.

I made a test to see if it works the way I originally thought it did, and it does, and the way we've been using it is VERY wrong.

This small example program illustrates the problem:

done off.
until done {
  on ag1 print "action group 1!".
  on ag2 done on.
  wait 1.
  print "loop iteration.".
}.

Looking at the code and thinking the way people writing their KOS code have been thinking, you'd think it would just loop forever one second per iteration, and then when you press ALT-1 it will print "action group 1!" and then when you press ALT-2 it ends, like so:

loop iteration.
loop iteration.
loop iteration.
loop iteration.
loop iteration.
action group 1!  [color=red]<- user pressed ALT-1[/color]
loop iteration.
loop iteration.
loop iteration.
action group 1!  [color=red]<- user pressed ALT-1[/color]
loop iteration.
Program ended.  [color=red]<- user pressed ALT-2[/color]

This is in fact NOT what it does. Each time you execute the ON command it inserts a brand NEW event trigger into the watchlist even though one was already there. Therefore what the code actually does is this:

loop iteration.
loop iteration.
loop iteration.
loop iteration.
loop iteration.
action group 1!  [color=red]<- user pressed ALT-1[/color]
action group 1!
action group 1!
action group 1!
action group 1!
loop iteration.
loop iteration.
loop iteration.
action group 1!  [color=red]<- user pressed ALT-1[/color]
action group 1!
action group 1!
loop iteration.
Program ended.  [color=red]<- user pressed ALT-2[/color]

It prints out the statement once per iteration of the loop that had previously occurred since the last time AG1 was pressed.

This is because each time ON... is being executed it's inserting a NEW hook into the condition watcher.

My example makes sure the numbers are small so you can see what's happening, but now try it again with the "wait 1" removed. Now it spews out a LOT of "action group 1!" lines because the loop was running at full speed and running the "ON" command a lot of times.

It also was inserting lots of the action group 2 triggers as well, but since all that trigger does is set the boolean variable "done" to true, you don't notice. If it sets "done" to true once or does so 100 times the effect is that same in the end. So this has been happening all along and we didn't notice.

This goes back to a comment I made a long time ago in this thread about how we don't REALLY have the ability to set up a trigger that re-executes EACH time a condition is true. This practice of putting an ON inside a loop is NOT enough to fix that problem, as it creates this new problem of clogging the mod with zillions of redundant pointless trigger hooks.

I think we really could use a way to differentiate "EACH TIME X is true do Y" from "JUST THE NEXT TIME X is true do Y just once". in the language.

In the meantime, I *THINK* this might fix the problem (I don't have KSP running right now so I can't test it. But you can see what the logic is meant to be):

Change instances of this:

until blah {
  on AG1 someCommandHere.

  restOfLoopBodyHere.
}.

To this instead:

insertAG1Hook on.
until  blah  {
  if insertAG1Hook {
    insertAG1Hook off. 
    on AG1 insertAG1Hook on. 
    on AG1 someCommandHere.
  }.

  restOfLoopBodyHere.
}

Basically it only inserts a new AG1 if an AG1 hook has just happened. If the previous one has not triggered it won't make another one.

[Motokid600]

Now that im using

lock steering to heading x by x.

It seems kOS can now control the craft with SAS on. I could never do this in the past with

lock steering to up + R(0,0,180) + R(0,-10,0).

And this seems to have solved the problem so far. But.. damn if this thing wont rip itselt to pieces now with it off. kOS simply had no control with SAS ofd and after the first stage separated the thing spins like a top. Ive tried a few of the ways Ive seen posted here, but so far no luck.

[G0rk1ll]

Is it possible to change WHEELSTEERING to another value than TARGET? I've tried headings, vectors, quaternions, eulers...nothing!

[check]

Is it possible to change WHEELSTEERING to another value than TARGET? I've tried headings, vectors, quaternions, eulers...nothing!

You can lock it to a geoposition.

Lock wheelsteering to latlng(0,-75).

should work. If not, try

Set x to latlng(0,-75).
Lock wheelsteering to x.

[Sma]

Now that im using

lock steering to heading x by x.

It seems kOS can now control the craft with SAS on. I could never do this in the past with

lock steering to up + R(0,0,180) + R(0,-10,0).

And this seems to have solved the problem so far. But.. damn if this thing wont rip itselt to pieces now with it off. kOS simply had no control with SAS ofd and after the first stage separated the thing spins like a top. Ive tried a few of the ways Ive seen posted here, but so far no luck.

Not like this makes a difference but why use

lock steering to up + R(0,0,180) + R(0,-10,0).

instead of

lock steering to up + R(0,-10,180).

I don't think it'll fix your problem of it ripping its self to pieces ("moar struts") but assuming it does the same thing it should help save space if that becomes an issue at some time. Also have you tried disabling gimble on some or all of your engines? I haven't had a rocket fall apart due to shaking with kOS yet, but I know when I Have one that I launch manually and it shakes its self apart turning gimble off tends to help.

In numerous examples and code the ON command has been used wrongly.

Very Wrongly.

I suspected it didn't make sense how people were using it when I first saw it but since everyone was already doing things this way I assumed it must just not work the way I intuitively guessed it did. A recent issue raised in the github made me go back and revisit that assumption. I started suspecting again that my original suspicions were right, given a complaint about how loops get very slow and memory usage leaks when a loop has an ON statement in it.

I made a test to see if it works the way I originally thought it did, and it does, and the way we've been using it is VERY wrong.

This small example program illustrates the problem:

done off.
until done {
  on ag1 print "action group 1!".
  on ag2 done on.
  wait 1.
  print "loop iteration.".
}.

...

Change instances of this:

[B][I]...[/I][/B]

To this instead:

insertAG1Hook on.
until  blah  {
  if insertAG1Hook {
    insertAG1Hook off. 
    on AG1 insertAG1Hook on. 
    on AG1 someCommandHere.
  }.

  restOfLoopBodyHere.
}

Basically it only inserts a new AG1 if an AG1 hook has just happened. If the previous one has not triggered it won't make another one.

Would this also apply to using ifs inside of loops? or is it really only a problem if using the on command? I haven't really used "on do something" as it seems, to me anyway, a waste of action groups. My SSTO plane I made a while back (before kOS) uses almost all of the action groups to toggle the turbojets, rocket engine and air intakes.

An example of what I do in loops:

//using this to test best settings to get into orbit using 4 parts, hence the logging
until periapsis > 70000 {
	if altitude > altStartPitch {lock steering to up + R(0,pitch,180).}
	if stage:liquidfuel < 1 and logged < 1 {log altitude+"|"+apoapsis+"|"+periapsis+"|"+throttle+"|"+pitch+"|"+altStartPitch to kosc1log.set logged to 1.}
}.

Edited October 5, 2013 by Sma

[rejooh]

Hello everyone,

I'm currently trying to map the surface of minmus to the console. By simply converting latitude / longitude coordinates to screen coordinates and subtracting alt:radar from altitude. Everything expect the print at function works fine. print at(x,y) doesn't seem to accept values that aren't integers. But the coordinates aren't.

Now, I need to know whether there is any way of converting floating point numbers to integers or apply floating point values to the print at(x,y) function.

Thanks for your help, rejooh.

[Sma]

Hello everyone,

I'm currently trying to map the surface of minmus to the console. By simply converting latitude / longitude coordinates to screen coordinates and subtracting alt:radar from altitude. Everything expect the print at function works fine. print at(x,y) doesn't seem to accept values that aren't integers. But the coordinates aren't.

Now, I need to know whether there is any way of converting floating point numbers to integers or apply floating point values to the print at(x,y) function.

Thanks for your help, rejooh.

That sounds like a cool idea, although if you haven't heard about it there is a mod for that, ISA MapSat. I don't have the link to it handy right now, but you can search for it in the forums. The development has kinda slowed down but they have a Dev version that works with 0.21. Might be worth checking out.

[PatriotBob]

Ok, maybe I'm just dumb here. But I can't get the archive to work for the life of me.

Using the COPY TO, LIST VOLUMES, or SWITCH TO commands just causes the terminal to hang. Listing the volumes gets as far as putting up the header and stuff but no volumes are listed.

I have the folder at <KSP DIR>/Plugins/PluginData/Archive/ but still just hangs...

Any suggestions?

[JewelShisen]

Ok, maybe I'm just dumb here. But I can't get the archive to work for the life of me.

Using the COPY TO, LIST VOLUMES, or SWITCH TO commands just causes the terminal to hang. Listing the volumes gets as far as putting up the header and stuff but no volumes are listed.

I have the folder at <KSP DIR>/Plugins/PluginData/Archive/ but still just hangs...

Any suggestions?

Turn the kOS unit off and then back on and try again.

[devanmedrow]

1) I would really like to see an external window that you could use on a second monitor. Or even a web page display like the telemetry mod. it doesn't have to be type-able, but that would a plus. You have the termanle on the second monitor and you press "~" now your keyboard is set to the termanle. You type your commands then press "~" aging and your keyboard is back to KSP control's. The "~" key could be what ever you like it to be.

2) A command to set the power used by RCS thrusters/Control surfaces/Wheel turn from 100% to 0%. Able to adjust the % of total thrust RCS use, speed your Control surfaces move or haw far they move, The angle your wheels rotate. Sometimes you have a lot of control surface for high altatude flights but at low altatude it is to much so you get the bouncing effect. Or you are building a space station and while docking you wont the RCS to just nudge you here or there.

This is the best mod out there for ship control!!! Thank you very much.

[PatriotBob]

Turn the kOS unit off and then back on and try again.

:|

Ok great. The terminal is back, still don't have access to the archive. Still locks up if I try.

[Dunbaratu]

You can lock it to a geoposition.

Lock wheelsteering to latlng(0,-75).

should work. If not, try

Set x to latlng(0,-75).
Lock wheelsteering to x.

Oh THAT is how you use wheelsteering!!

I kept trying to use it like you use steering - to lock it to a direction rather than a location. I assumed it was just like steering, but in 2D instead of 3D, so you just give a heading compass angle only. That would make sense (and actually be useful).

Any chance we can make wheelsteering work by a heading too? Since KOS knows the types of objects it should be able to distinguish between being given a string (a named target), a LATLNG( A location), or a single number (a heading) and behave accordingly.

[Dunbaratu]

Ok, maybe I'm just dumb here. But I can't get the archive to work for the life of me.

Using the COPY TO, LIST VOLUMES, or SWITCH TO commands just causes the terminal to hang. Listing the volumes gets as far as putting up the header and stuff but no volumes are listed.

I have the folder at <KSP DIR>/Plugins/PluginData/Archive/ but still just hangs...

Any suggestions?

No, you're not dumb. This is a bug that's not your fault. All KOS CPU modules have a concept of "SelectedVolume" stored internally. (It's the variable that tracks the result of the SWITCH TO command.) The bug is that when a ship is first loaded onto the launchpad, although it has a Volume on it, it hasn't had its SelectedVolume variable initialized to point to it yet. It still points to null. There is a fix for this in the development version so I think we'll see it in the next release.

In the meantime, to avoid it, just make sure the very first thing you do when you start off a new craft is go to all of the KOS-enabled parts installed on it and bring up their terminals and have them all do a SWITCH TO 1.

Edited October 5, 2013 by Steven Mading

[PatriotBob]

No, you're not dumb. This is a bug that's not your fault. When a ship is first loaded onto the launchpad, it hasn't had its current selected volume initialized yet. It's still null. There is a fix for this in the development version so I think we'll see it in the next release.

In the meantime, to avoid it, just make sure the very first thing you do when you start off a new craft is go to all of the KOS-enabled parts installed on it and bring up their terminals and have them all do a SWITCH TO 1.

Ok, I'll give that a try. i'm guess that fix was the pull request that initializes the HardDisk before calling initCPU().

I really love this mod, but I hate the syntax sooooooooo much.

[Sma]

No, you're not dumb. This is a bug that's not your fault. All KOS CPU modules have a concept of "SelectedVolume" stored internally. (It's the variable that tracks the result of the SWITCH TO command.) The bug is that when a ship is first loaded onto the launchpad, although it has a Volume on it, it hasn't had its SelectedVolume variable initialized to point to it yet. It still points to null. There is a fix for this in the development version so I think we'll see it in the next release.

In the meantime, to avoid it, just make sure the very first thing you do when you start off a new craft is go to all of the KOS-enabled parts installed on it and bring up their terminals and have them all do a SWITCH TO 1.

Some how I must be missing out on this bug. Sometimes if I'm lazy I'll just switch to archive and run from there, but most of the time I try to use

copy [I]filename[/I] from archive

and I haven't run into this yet.

[Dunbaratu]

Would this also apply to using ifs inside of loops? or is it really only a problem if using the on command? I haven't really used "on do something" as it seems, to me anyway, a waste of action groups. My SSTO plane I made a while back (before kOS) uses almost all of the action groups to toggle the turbojets, rocket engine and air intakes.

No that's different. IF's are fine as they are.

IF means "check this right now and if true at this very moment do this thing once.

ON means "set up a continuous check that will check again and again after each and every statement to see if this has become true, and if it has become true then escape out of whatever you're doing to do this one thing, then go back to what you were doing (and stop the continual checking this statement did as well - remove it from the watch list).

I agree with you about Action Groups being a precious resource, but the ON command can be used on ANY boolean variable including ones you make up yourself. It doesn't have to be used with Action Groups.

[PatriotBob]

No, you're not dumb. This is a bug that's not your fault. All KOS CPU modules have a concept of "SelectedVolume" stored internally. (It's the variable that tracks the result of the SWITCH TO command.) The bug is that when a ship is first loaded onto the launchpad, although it has a Volume on it, it hasn't had its SelectedVolume variable initialized to point to it yet. It still points to null. There is a fix for this in the development version so I think we'll see it in the next release.

In the meantime, to avoid it, just make sure the very first thing you do when you start off a new craft is go to all of the KOS-enabled parts installed on it and bring up their terminals and have them all do a SWITCH TO 1.

This doesn't seem to really help. They're already on volume 1, it's the local volume. Problem only really occurs when accessing the archive. I'm guessing the terminal lack of responsiveness is related to https://github.com/Nivekk/KOS/issues/113 so I'm guessing kOS is throwing a null ref when I try to access the archive. So the question is, why?

[Dunbaratu]

I really love this mod, but I hate the syntax sooooooooo much.

I do agree.

People have tried many times in the past to achieve some sort of a utopian programming language in which you just let people write their commands out in "normal English". It *NEVER* works. Ever. It always ends up being a language that superficially looks sort of like English but is just as hard as any other programming language is and you still have to memorize its syntax as being something distinct from English. And people keep making the mistake of thinking that the reason it didn't work out in the past is something deficient about the programming - that with better computers or better software it can be solved "this time around". They fail to understand that the specific implementation isn't to blame, English is to blame. You can't make English into a formal logical language. Its just too sloppy. And this isn't just English that's like this. ANY natural language will have been built by a long history of logic fighting against incorrect sloppy common usage, and incorrect sloppy common usage winning every single time until eventually its been common long enough that its no longer incorrect. Natural languages are by the very nature of how they come into existence, NOT logical. This is why they don't work as programming languages.

Next time you're tempted to try making English into a programming language, open up the license agreement on a bit of software, or read a legal ruling online. That monstrous lawyer-speak is what a natural language turns into when people are trying to use it in a way that removes all ambiguity from it. That mess is that way because otherwise the flexibility of the English language itself would leave behind major loopholes in the legally binding text.

[Dunbaratu]

This doesn't seem to really help. They're already on volume 1, it's the local volume. Problem only really occurs when accessing the archive. I'm guessing the terminal lack of responsiveness is related to https://github.com/Nivekk/KOS/issues/113 so I'm guessing kOS is throwing a null ref when I try to access the archive. So the question is, why?

I can verify that it does help for me.

Launch a new craft and type "LIST." as my first command and the terminal freezes in exactly the way you describe.

Launch a new craft and type "SWITCH TO 1. LIST." and it doesn't.

[PatriotBob]

I can verify that it does help for me.

Launch a new craft and type "LIST." as my first command and the terminal freezes in exactly the way you describe.

Launch a new craft and type "SWITCH TO 1. LIST." and it doesn't.

If I type "LIST." It never freezes. "LIST VOLUMES.", "SWITCH TO 0.", "COPY [Filename] TO 0." These all freeze the terminal. Regardless of trying "SWITCH TO 1." First or not.

[Dunbaratu]

If I type "LIST." It never freezes. "LIST VOLUMES.", "SWITCH TO 0.", "COPY [Filename] TO 0." These all freeze the terminal. Regardless of trying "SWITCH TO 1." First or not.

Well I wish I knew why everyone's getting different behavior then.

One possible explanation for why it's not exactly the same for everyone is that the code in question that does the initialization is inside a hook function that KSP calls whenever a spaceship part (like the KOS computer) is loaded into the full physics engine, and this seems to be called multiple times in some cases. Whatever it is that causes the KSP game to sometimes call the initializer more than once, it would mean that in the cases where it's called only once it would fail (because the selectedvolume is set AFTER the initCPU happens), but in the cases where it's called more than once it works (because the selectedvolume was set on the previous call when initCPU happens the second time.)

Edited October 5, 2013 by Steven Mading

[PatriotBob]

Well I wish I knew why everyone's getting different behavior then.

One possible explanation for why it's not exactly the same for everyone is that the code in question that does the initialization is inside a hook function that KSP calls whenever a spaceship part (like the KOS computer) is loaded into the full physics engine, and this seems to be called multiple times in some cases. Whatever it is that causes the KSP game to sometimes call the initializer more than once, it would mean that in the cases where it's called only once it would fail (because the selectedvolume is set AFTER the initCPU happens), but in the cases where it's called more than once it works (because the selectedvolume was set on the previous call when initCPU happens the second time.)

Welp, started ripping out mods in desperation. It was Remote Tech.

Having access to the source on most mods is both wonderful and terribly frightening at the same time...

[MDBenson]

What would be super-awesome would be a list, possibly in the OP, of mods that support or add-on to kOS.

Aside from that, great work, keep it up!

[Sma]

Welp, started ripping out mods in desperation. It was Remote Tech.

Having access to the source on most mods is both wonderful and terribly frightening at the same time...

Yeah, was going to say maybe its a mod causing the problem as it seems to happen differently for different people. I originally was using Remotech 2 for playtesting, and found out quickly it was causing the problem where typing in the kOS window would react to the rocket (such as staging). It still happens from time to time after I took RT2 off, but not nearly as often, and usually if I click out of the kOS window and back into it.