[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Berengal]

So after updated to 0.12 today I found some of my older programs completely froze KSP when I ran them. I managed to reduce it to a minimal test case:

// Will always freeze KSP in kOS v0.12
set x to false.

when x then {
  until false {
    print "hello".
  }.
}.

set x to true.
wait 1.

[Dunbaratu]

So after updated to 0.12 today I found some of my older programs completely froze KSP when I ran them. I managed to reduce it to a minimal test case:

// Will always freeze KSP in kOS v0.12
set x to false.

when x then {
  until false {
    print "hello".
  }.
}.

set x to true.
wait 1.

I just tested and verified the bug. It happens when I do it to - it froze KSP so hard I couldn't even CTRL-ALT-DEL to kill KSP and had to do a hard poweroff.

I have no idea what's going on. I'd suspect it's got something to do with leaving a THEN clause still running when the program ends.

I made an issue for it on the development site, and you can track its progress at this link:

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

[Berengal]

I found another bug with when statements.

If you have waits in a when statement they will be skipped. If your main program is waiting, its waiting condition will be replaced by the condition in the last of the wait statement in the when statement.

// Waits for 4 seconds

when true then {
  print "1: " + time.
  wait 2.
  print "2: " + time.
  wait 4.
  print "3: " + time.
}.

wait until false.
print "done: " + time.

[Morgantao]

CTRL+C is supposed to work, but if it doesn't then that could be a bug. Have you tried it and it didn't work?

It just occurred to me what the problem might be - are you aware of the keyboard focus issue with using action groups as a means of input?

When you say "ON AG5 ... " What you are saying is

not this -> "respond to somebody pressing ALT+5".

What you are saying

is this -> "respond to Action Group 5 happening.".

The difference is subtle but very important. In order for Action Group 5 to happen, Kerbal Space Program needs to see your ALT+5 keypress. Note, that's Kerbal Space Program, NOT kOS. In other words, you have to make sure that kOS's terminal window is *NOT* focussed. It needs to be greyed out and un-highlighted (click outside the window on the screen) in order for ALT+5 to be seen by KSP and turned into an action group.

Is that the problem? This also needs better documenting.

Ctrl+C didn't work. It's the first thing I tried (being an old fart that's my default "Oh crap, what did I do now?" key). In fact, all I could do was Ctrl+Alt+Del and close KSP from the task manager, as it was completely frozen.

I know about the de-focusing KOS for action groups to work. I don't know where, but I remember reading that.

What I don't know is what Alt+5 is... Is that an alternate way to toggle an action group in KSP?

[Dunbaratu]

Ctrl+C didn't work. It's the first thing I tried (being an old fart that's my default "Oh crap, what did I do now?" key). In fact, all I could do was Ctrl+Alt+Del and close KSP from the task manager, as it was completely frozen.

Well that's unexpected. Was that the entire program you posted or was there more to it? I can't get it to freeze running what you posted.

I know about the de-focusing KOS for action groups to work. I don't know where, but I remember reading that.

What I don't know is what Alt+5 is... Is that an alternate way to toggle an action group in KSP?

Uhmmm... alternate way? It's the only way I was aware of. What way were you using?

[Cakeofruit]

can we get data from FAR or KER ? or other mod ?

great mod that put your head on books of orbital mechanics like FAR !! Thx

[Morgantao]

Uhmmm... alternate way? It's the only way I was aware of. What way were you using?

I just press 5. No Alt involved. Worked for me so far.

Anyway, here's my script:

set x to 1.
on ag5 {
  set x to 1.
  until x>1 {
    toggle ag3.
    wait 1.4.
    toggle ag3.
    wait 0.3.
  }
}
on ag6 {
  set x to 2.
}
wait 10. 

All ag3 does is toggle the landing legs.

The second I hit 5, KSP freezes.

[Dunbaratu]

In a few back and forth comments on github something came up that should probably be made into a public announcement.

Lots of people are reporting in this forum the same problem with using WHEN/THEN and ON trigger code, and it can all be traced to the same cause: The behavior of these things has been altered in an important but subtle way when marianoapp re-implemented the kOS language from the ground up, and the change was never mentioned publicly. I only just found out about it an hour ago or so.

The old way it used to work:

The body of a THEN clause is a bit like a clunky blocky thread - it runs in the background, but an entire statement at a time. It's not quite a thread but it's close, in that you can interleave the execution of the THEN clause with the execution of the main program.

The new way it works:

Whenever the WHEN/THEN or ON trigger condition happens, the main program pauses and waits for the body of the THEN to finish before it will continue. Effectively, kOS is a lot faster now, but single-threaded. (Granted what there was before wasn't *quite* a thread, but you get what I mean). Also, the entire body of a WHEN/THEN or ON command must be designed to execute fully, all the way to the ending squiggle-brace, rather fast, because all of KSP (not just kOS) is paused until it finishes.

The WAIT no longer works inside WHEN/THEN or ON bodies because of this - those parts of the program don't run in the same interruptable few-instructions-per-update-tick sort of way that the rest of the code does.

Therefore any algorithm designed like some of the ones posted here, where there's a loop inside the body of the WHEN/THEN, that's expecting to see a change to a variable caused by the main body, will not work anymore, as the main body isn't running while the WHEN/THEN is running.

The reason this change was not mentioned was that it wasn't obvious that it even WAS a change, as marianoapp thought the way he implemented it *was* the way it originally worked. Let's be fair, the original specifications were unclear, the C# code itself was mostly undocumented, and of course Kevin Laity was impossible to reach to answer any questions so it's not like anyone could ask for clarifications to the spec to figure out what was intended behavior of kOS versus what was buggy behavior. So yes, it's a change to the spec, but its an understandable one (the old way was really messy how it was implemented under the hood).

There should be a way to make a repeating WHEN/THEN that doesn't delete itself after the first execution, such that you can "loop" by letting the kOS computer re-run the WHEN/THEN for you again and again. Right now the syntax doesn't support it, but it's a thing people have mentioned as possible future pie-in-the-sky ideas.

I have to hurry up and go edit some of the documentation I wrote on the site, which claims this method is supposed to work. In the past, it did.

Edited May 5, 2014 by Steven Mading

[Korb Biakustra]

Thanks for that awesome mod. I have been following it since a long time, but I've never managed to use it so far due to lack of time and another programming language to focus on for work (when you're not a programmer, you may very quickly mix up languages ).

I am wondering whether there is a Toolbar implementation for kOS. The kOS part can be very hard to select to open the terminal via the right-click menu, especially if you have a large ships where the part is far from the center of mass (where the view is centered), or even worse, if you use fairings. A Toolbar button would solve such issues.

Additionally, are there any plans for adding a radially-mountable kOS part?

Edited May 6, 2014 by Korb Biakustra

[Izandral]

Just downloaded the latest version on spaceport. When i put a KOS module on a ship i can no longer control it manually. I don't program anything i don't even open the terminal. Just having the part on the ship prevents throttle and steering from working at all. What should i do ?

[Dunbaratu]

Just downloaded the latest version on spaceport. When i put a KOS module on a ship i can no longer control it manually. I don't program anything i don't even open the terminal. Just having the part on the ship prevents throttle and steering from working at all. What should i do ?

Wait for 0.12.1

(It's a bug that is being worked on by erendrake at the moment. Not everyone experiences the bug as it seems to have something to do with exact timings in a finicky way.)

[Morgantao]

Steven, thanks for finding out why we couldn't get the loop to work. It all makes sense now

[Sma]

Additionally, are there any plans for adding a radially-mountable kOS part?

It's certainly a possibility, though honestly I didn't even think of a that. "Currently" (pending R/L and playing KSP for Science!) I'm working on a 2.5m3.75m part, and would like to also get a 3.75m one out as well, and eventually may replace the original one too.

This is my first time making parts for KSP, or any game really (can you tell? lol), but it is pretty fun. I don't consider my self to be much of a graphic artist but I do enjoy creating something with Blender/GIMP and then having it in the game.

At any rate, here is a mock up of what I'm "currently" working on. The actual in game model looks little better than this currently, but I'm not that familiar with the sketchfab process so I may be missing something.

With the 0.625 part, before the update, the built in light was green, but with the change to the lighting system it now defaults to white. I haven't taken the time yet to figure out how to fix it just yet.

If anyone has ideas/suggestions for the parts, let me know either by replying and/or PM (though PM maybe best so it doesn't get lost in the forum). Can't guarantee that I'll like them or that they'll make it in, but you never know.

Edit: It seems the small part is slightly smaller than it should be. I don't remember if this is how it was originally or not though lol. I'll get that fixed when I fix the light. Also just checked, the 3.75m part I'm working on is in the update, so you can check out where it was when I last sent it to erendrake.

Edited May 6, 2014 by Sma

[Dunbaratu]

If there was a radially-mounted kOS computer part, which of these would be the preferred behavior, I wonder:

1. Steering controls use the computer part's own orientation to decide which way is which. If the part is facing sideways, and you tell it to LOCK STEERING TO UP, it will face the PART's top toward up, not the ship's top toward up.

2. Steering controls use the Vessel's idea of up and down and left and right. The command LOCK STEERING TO UP would point the nose of the ship up, even if it was executed from a radially mounted computer part.

Along similar lines I was contemplating if it would be possible to create a tiny part along the lines of the little science sensors, called a Telemetry Sensor, the purpose of which is to be nothing more than a thing that kOS scripts can use to issue a command that says "THIS is where I want my measurements taken from, rather than from the center of the ship." For the purpose of things like POSITION vectors, or altitude queries. It would allow people to place a sensor at the bottom of the ship and use that for the landing altitude, instead of having to have the software hardcode the knowledge of how far the center of mass is from the bottom of the ship.

[Dunbaratu]

Steven, thanks for finding out why we couldn't get the loop to work. It all makes sense now

I'm not entirely happy with the change because while I can understand the need to make it cleaner, there currently isn't anything else to replace it with, so algorithmic possibilities have been taken away. (Which is a much bigger deal than removing the text editor). If there was a way to specify that a WHEN/THEN shouldn't be removed after it executes once, and should remain in place, then that would provide an alternate way - you'd just put the body of your loop flat in the THEN body without the loop wrapper, tell kOS to preserve the hook and not delete it, and then kOS will keep re-triggering it each time KSP tells the mod to update itself. It would then behave sort of like a loop but slower, only executing once per game update tick. For most of the uses I'm seeing people put it to, that would be plenty fast enough.

[Sma]

If there was a radially-mounted kOS computer part, which of these would be the preferred behavior, I wonder:

Good point, I like the 2nd behavior you mentioned, likely wouldn't have any additional programming. Also the idea of having a sensor for telemetry sounds interesting. Not sure what it'd take on the code side, but I'll keep it in mind once I get around to working on other parts.

[Ralathon]

If there was a radially-mounted kOS computer part, which of these would be the preferred behavior, I wonder:

1. Steering controls use the computer part's own orientation to decide which way is which. If the part is facing sideways, and you tell it to LOCK STEERING TO UP, it will face the PART's top toward up, not the ship's top toward up.

2. Steering controls use the Vessel's idea of up and down and left and right. The command LOCK STEERING TO UP would point the nose of the ship up, even if it was executed from a radially mounted computer part.

Along similar lines I was contemplating if it would be possible to create a tiny part along the lines of the little science sensors, called a Telemetry Sensor, the purpose of which is to be nothing more than a thing that kOS scripts can use to issue a command that says "THIS is where I want my measurements taken from, rather than from the center of the ship." For the purpose of things like POSITION vectors, or altitude queries. It would allow people to place a sensor at the bottom of the ship and use that for the landing altitude, instead of having to have the software hardcode the knowledge of how far the center of mass is from the bottom of the ship.

Vessel would be more intuitive. If you lock your steering to 30 by 45 you're going to be pretty confused as a new player when it starts to point at the horizon because the kOS core is mounted on an angle. If you want you could give the kOS parts the same "Control from here" feature that docking ports have. That way you can adjust the vessel orientation to match kOS part orientation.

[Korb Biakustra]

It's certainly a possibility, though honestly I didn't even think of a that. "Currently" (pending R/L and playing KSP for Science!) I'm working on a 2.5m3.75m part, and would like to also get a 3.75m one out as well, and eventually may replace the original one too.

Thanks for your answer! The idea behind a radially-mountable part is basically that I think a "terminal" would realistically be included in any manned or unmanned pod, and radially-mounted parts usually impose less constraints on how to design your ship than stackable parts, at least on pods. For instance I have a pod with 1.25 m stuff and docking ports on both ends, and adding a layer for the "computer" of this pod seems weird and will make it even taller.

Of course this is not a very important issue (is it an issue anyway?) and attaching radial parts is not always easy either, but I thought I'd ask!

[Sma]

Thanks for your answer! The idea behind a radially-mountable part is basically that I think a "terminal" would realistically be included in any manned or unmanned pod, and radially-mounted parts usually impose less constraints on how to design your ship than stackable parts, at least on pods. For instance I have a pod with 1.25 m stuff and docking ports on both ends, and adding a layer for the "computer" of this pod seems weird and will make it even taller.

Of course this is not a very important issue (is it an issue anyway?) and attaching radial parts is not always easy either, but I thought I'd ask!

Does not hurt to ask, usually...lol

That is true, about making a stack taller, though in the past I just planned for this from the start and/or worked around it, not always successfully though lol. Another thought I had was radially attached parts to add certain features, like more storage space, different functions and/or faster processing. Although most of that will be on the code side which is something I don't do (although I do web programming, mostly PHP...I guess it might be handy to add another one to the list, if I had the time to learn it lol).

[Cakeofruit]

the command print engine:thrust. don't work for me in kos 0.12

Did i write it wrong ?

For the docs we really need to see the output of the kos console for each command.

still no way to get data from Ferram mod ?

[Dexter9313]

Hi everyone !

I have been using kOS for a long time now (since 0.7 approximatly). I updated to 0.9 a few months ago then I modified it to add some features that are now almost all in 0.12 so I finally decided to give your new version a try.

Long story short, my RT2/kOS compatibility is broken in a strange way. I tried to narrow down the problem so I will give as much information as I can :

1 First of all I use RemoteTech 1.3.3 and installed the second fix from madadam and JDMJ here :http://forum.kerbalspaceprogram.com/threads/56399-0-23-RemoteTech-2-v1-3-3-Late-Christmas-Edition?p=901076&viewfull=1#post901076

I don't know which version is actually supported by kOS but since 1.3.3 was unplayable for a lot of us, I'll guess it used 1.3.3 fix 2.

2 Here is the bug :

I launched a ship using kOS in a 80k circular orbit, left the game, reloaded the save and loaded the spacecraft from the tracking station.

The game remains "frozen" like this. I can move the camera so the executable isn't frozen but time doesn't pass (hanged at 9:20 here). I also can use the GUI to go back to the Space Center or bring the debug console to the screen. Which leads me to the next point.

3 Here are my logs :

http://pastebin.com/RsKyjYbs

4 I figured out it only occures when kOS Module data has already been stored in the persistent file. Whenever I launch a ship for the first time, the bug doesn't show up, but whenever I reload the save file it does. The KSC is clean, it only appears when a vessel is being loaded and doesn't seem to influence the game so much. I know saved data should be the problem because whenever I edit the

"PART

{

name = kOSMachine1m

...

}"

in the persistent.sfs file and remove the

"MODULE

{

name = kOSProcessor

...

}"

from it, loading the vessel is normal.

5 I know RT2/kOS are the problem because I tried a dummy game with those installed only. Here it is :

https://www.dropbox.com/s/vegcckscce3qd5j/kosTracker.rar

Go in Tracking Station and load the only vessel orbiting.

I know both my logs and savegame contain traces from other mods but they where not installed when I ran this test (GameData folder only containing Squad "NASAsomething" kOS and Remotetech2). I tested things with other mods on just before so they leaved trash at some places but they don't interfere in any way.

Anyway, thank you for your help, those mods are almost my only reason to play KSP so much !

[EDIT] When I disable Remotech Integration in the kOS congif.xml file, the two dlls can coexist within the game without leading to the bug so I think kOS doesn't handle something quite as it should when creating the RT "environment".

Edited May 7, 2014 by Dexter9313

[CaptainKipard]

Whenever I'm building a rocket with an up-side-down payload (with multi-engine ends), kOS doesn't lock it's steering correctly. It just makes the rocket spin like a maniac. "Control from here" makes no difference. Is there a workaround?

----------------------------------

Hi everyone !

Hi!

Here is the bug :

Did you add the kOS module to your probe cores and pods?

[Dunbaratu]

Whenever I'm building a rocket with an up-side-down payload (with multi-engine ends), kOS doesn't lock it's steering correctly. It just makes the rocket spin like a maniac. "Control from here" makes no difference. Is there a workaround?

Can you give an example .craft file?

[CaptainKipard]

Can you give an example .craft file?

I'll get a stock one together. One thing I should have also said. The root part is a Science Jr. The payload probe core is surface attached and pointing down. The rocket probe core is also surface attached, and is pointing up. Both cores are custom made for the Open Mod competition by me. Would you download it? It would make your test more relevant.

Edited May 8, 2014 by Cpt. Kipard

[Dexter9313]

Did you add the kOS module to your probe cores and pods?

I'm afraid I did not. There are no modification from stock in my KSP directory other than adding the "official" RemoteTech and kOS, and one IVA mod which should be outside GameData so I forgot to mention it. It's for the stock mk2/mk3 plane cockpits but I didn't load them in my test and they are in the directory for a very long time and never interfered with anything. I modified kOS a little so that it computes eta_ascendingnode for exemple a bit later but I already had the exact same bug before I did. Now you know everything. If nobody can see what is happening I could check the source code myself but I'd rather know that the main developers have checked that before for an obvious fix. If I am the only one to experience this I should try to reinstall a fresh KSP.

Anyway, I have another wonder : have steering been heavily modified in .12 ? My probes don't handle good at all and my old "executenode" script which relies on a very stable vessel is of no use anymore. The spacecraft keeps trying to steer towards the node but it results in an "artificial wobble" which doesn't come from the structure but from the craft moving "around the vector" for 3°/4°, not being able to hold itself stricly along it. That is surely more "realistic" but I find it very annoying for maneuvers which require precision (I can't do better than 2 or 3 m/s precision now, I could do 0.1 before, no rcs required). It behaves almost like if the reaction wheel was not used.