kOS Scriptable Autopilot System 0.9

[Kalista]

The part thats broken with eta:apoapsis is using it in a math statement. My launch to orbit code has used it forever to get the circularization burn down to where its nearly perfect. THATS where eta:apoapsis is broke and no longer working when it had been working fine for several versions ( believe I started using space computer from which my code is from back in .40 and I have youtube videos of the code working perfectly back in .60). Printing it as far as I know hasn't ever been the issue its using it in a math statement for orbital maneuvers thats been busted since .8x came out.

[Bizz Keryear]

I was pretty sure I tested eta:apoapsis in 0.84 and it worked for me. I'll test it again now just to make sure though. Back in a few...

Update: print eta:apoapsis works for me in both command line prompt and in a program. Unless I'm misunderstanding something. print "" at (x,y) is half broken in that if there isn't already text at that location it won't print. Didn't try eta:apoapsis with print at though... Just tried it, it does work, but like I mentioned it has to be at a location that already has text. In my case I don't get any error messages (from command line anyway) if there is no text at the line you're trying to print to, it just doesn't do anything....Ok just tried it in a program, and it works the same. The simple program:

[COLOR="Blue"]print [/COLOR][COLOR="Purple"]eta[/COLOR][COLOR="Black"]:[/COLOR][COLOR="Purple"]apoapsis [/COLOR][COLOR="Black"]at [/COLOR][COLOR="Black"]([/COLOR][COLOR="Orange"]0[/COLOR][COLOR="Black"],[/COLOR][COLOR="Orange"]0[/COLOR][COLOR="Black"]).[/COLOR][COLOR="Black"]
[/COLOR][COLOR="Blue"]print [/COLOR][COLOR="Purple"]eta[/COLOR][COLOR="Black"]:[/COLOR][COLOR="Purple"]apoapsis [/COLOR][COLOR="Black"]at [/COLOR][COLOR="Black"]([/COLOR][COLOR="Orange"]0[/COLOR][COLOR="Black"],[/COLOR][COLOR="Orange"]10[/COLOR][COLOR="Black"]).[/COLOR][COLOR="Black"]
[/COLOR]

When run will print apoapsis at the top most section of the kOS screen. If you keep running it, once you get down to line 10 (11 being as the 1st line is 0) it'll start printing at line 10 as well. For me I don't get any error messages for some reason.

Ah sorry, and again I am a bit wiser. Ok whats really broken is:

 print "some text" + eta:apoapsis. 

That does not applies to

until variable + eta:apoapsis 

also not to when. only to print and that throws an "unknown term eta" error.

Print "" at (x,y) is broken in so far that is only prints to lines where the normal print already was.

Means if there are eight lines on the screen then print "my text" at (0,10) will stay invisible.

--- My guess is that will at least three more 0.8x versions before it is as stable as 0.71 ---

If someone still has old kOS versions which aren't on my drive please PM me.

[razark]

Ok whats really broken is:

 print "some text" + eta:apoapsis. 

That does not applies to

until variable + eta:apoapsis 

also not to when. only to print and that throws an "unknown term eta" error.

This is working for me:

print "Apoapsis in " + eta:apoapsis + " seconds".

The two problems I'm noticing now are using "throttle" in a loop control and steering. "lock steering to prograde" no longer follows prograde, but keeps pointing in the direction prograde was when steering was locked.

[Bizz Keryear]

This is working for me:

print "Apoapsis in " + eta:apoapsis + " seconds".

The two problems I'm noticing now are using "throttle" in a loop control and steering. "lock steering to prograde" no longer follows prograde, but keeps pointing in the direction prograde was when steering was locked.

But I can confirm that print "some text" + eta:apoapsis. was what has broken space computers orbit script totally ... I mean right now you can't achieve orbit with it but with adding the brackets it is executed till the end. While before it always ended with "unknown term eta".

Maybe it only shows how wired that bug is.

[razark]

But I can confirm that print "some text" + eta:apoapsis. was what has broken space computers orbit script totally

This is odd. print "a" + eta + "b". works, but print "a" + eta. doesn't. Very strange and inconsistent.

Maybe it only shows how wired that bug is.

We may just need to wait for version 0.90 to level out. It might just be that we are looking at a transitional point in the way expressions are parsed, and the author needs to finish a half done job before everything starts making sense again.

[Dunbaratu]

The part thats broken with eta:apoapsis is using it in a math statement. My launch to orbit code has used it forever to get the circularization burn down to where its nearly perfect. THATS where eta:apoapsis is broke and no longer working when it had been working fine for several versions ( believe I started using space computer from which my code is from back in .40 and I have youtube videos of the code working perfectly back in .60). Printing it as far as I know hasn't ever been the issue its using it in a math statement for orbital maneuvers thats been busted since .8x came out.

I have a suspicion this may be related to when KOS was changed to use doubles instead of floats everywhere. I don't know for certain if this is true but it seems likely. At any rate I made an issue about it on the Github and we'll see what Kevin says about it.

The problem (maybe?) is that ETA:Apoapsis is returning a native value from the KSP API library directly to the user, as-is, without casting it. Back when all the variables in KOS were single-precision floats this was fine. But now that the system assumes all variables are doubles, this effectively gives you a single-precsion float stored in a variable and the rest of the system assumes that can't happen.

[Chris92]

Well, firstly, the mod file structure was altered in 0.6 or 0.7 to match SQUAD's new plugin directory, rather than the legacy folder that was used back in 0.46.

Textures and associated folders should be in: <Your KSP Folder>\GameData\kOS\GFX

So if it's throwing the exact same error, then that's an issue for the author.

The reason my installation errored back then was because I just dumped the file in the proper place and hit the debug menu's database refresh while the game was running. I assume that doesn't load art assets, hence why a full restart worked.

Are you sure you haven't installed this in the legacy folder?

Hi, I have installed it in the GameData folder. I also installed it in the Legacy folder to test if this works...

...but it didnt work so I deleted all mods and reinstalled kOS to see if my mods caused the problem. But now i dont know what to try next...

[Sma]

Hi, I have installed it in the GameData folder. I also installed it in the Legacy folder to test if this works...

...but it didnt work so I deleted all mods and reinstalled kOS to see if my mods caused the problem. But now i dont know what to try next...

I've never run into this problem so I'm not exactly sure what's going on. Most of the time when I upgrade it I just delete the kOS folder inside of gamedate, then copy/drop the kos folder from the zip file in there and restart the game. I doubt this is the case but could it possibly be because of amount of memory left? Or for some odd reason folder/file permissions?. I assume you've actually gone to the kOS\GFX\ folder to make sure the files are there? Also, if you haven't already, be sure to take the kOS folders out of the plugin folder (except for archive, leave it there, although if its not there it'll be recreated, but make sure to have a backup of any programs you may have written).

[aNewHope]

Didn't test 0.8 throughly but

0.82: lock throttle broken, but lock steering worked (at least for me, dunno if there where some special cases), print eta:apoapsis broken, print "" at (x,y) working.

0.83: lock throttle working, but lock steering broken, print eta:apoapsis broken, print "" at (x,y) working.

0.84: lock throttle working, but lock steering working, print eta:apoapsis still broken (we just found out that that was it which caused the "unreconised term eta:", print "" at (x,y) broken. error messages broken.

I currently use a workaround to be able to use eta:apoapsis:

Simply lock a variable to eta:apoapsis and one to eta:periapsis and use these instead. This fixed all my problems.

PS.: Works perfectly fine in my new SSTO-spaceplane - Autopilot. I gonna be posting it soon. (Best SSTO ascend I got yet).

[Sma]

I currently use a workaround to be able to use eta:apoapsis:

PS.: Works perfectly fine in my new SSTO-spaceplane - Autopilot. I gonna be posting it soon. (Best SSTO ascend I got yet).

That's something I'm gonna work on when i have some time and once I nail down my rocket script like I want. Of course I need to make a new ssto, i have one already thats...ok, but heavy on the part count.

[Bizz Keryear]

I currently use a workaround to be able to use eta:apoapsis:

Simply lock a variable to eta:apoapsis and one to eta:periapsis and use these instead. This fixed all my problems.

PS.: Works perfectly fine in my new SSTO-spaceplane - Autopilot. I gonna be posting it soon. (Best SSTO ascend I got yet).

So then does lock work in loops now?

P.S.: I Know What You (Kevin) Did Last Summer ... erm the last days. =>

[masTerTorch]

if throttle = 0 {print "hallo".}

Gives flagrant error.

This seems broken to me. Can anyone confirm this?

Using 0.84.

This too:

lock throttle to 1.
print throttle.

Gives me a 0.

And this:

lock throttle to throttle + 0.5.

Gives flagrant error, again.

Ok. Tried some steering commands in 0.84:

lock steering to heading 270 by 90.

seems broken.

Edit: Tried this again and is working now. Don´t now y...

print steering.

Always gives 0. Is this intended?

Another thing:

Sometimes parts which are on top of the kos unit will disappear. Updated to 0.84 today. This probe was launched with 0.71. Parts disappeared before update. Haven´t experienced disapearing parts since update. But will watch out for this.

Edited October 10, 2013 by masTerTorch
steering with heading works now.

[Sma]

So then does lock work in loops now?

P.S.: I Know What You (Kevin) Did Last Summer ... erm the last days. =>

Lol you saw that too huh?

[Dunbaratu]

Another thing:

Sometimes parts which are on top of the kos unit will disappear. Updated to 0.84 today. This probe was launched with 0.71. Parts disappeared before update. Haven´t experienced disapearing parts since update. But will watch out for this.

I can't comment on the other problems, as I decided to just use 0.7 for now until things are more stable again.

But THIS problem I've seen before a LOT, and not just in 0.8x. Normally I prefer to play KSP with permadeath - meaning I don't manipulate the save game folder and I just accept it if I die and crash. But ever since using KOS I have had to abandon that and use save-scumming by backing up savegame folders behind the scenes so I'm able to revert when something goes haywire. This is because a lot of the time the disaster isn't my fault but a bug. This "half the ship disappears" problem is one I get a lot.

I hadn't noticed before that it was always disconnecting RIGHT at the spot where the KOS SCS part is attached. But you're right, it is always right at that spot. That might be relevant? I've wanted to make a bug report on it in github but I just can't get a consistent set of circumstances that trigger it. I figure until I have that there's no sense in reporting it. (Programmers HATE it when bug reports don't tell them how to make the problem occur. You can't discover the cause of the problem that way, and even if you can make a good guess about it and try to fix it, to prove it was fixed requires being able to see a difference between the "before" behavior and the "after" behavior. And that means being able to have a test to run that had previously made the problem occur.)

Maybe since we've both seen this happen we can help trace down the exact circumstances that cause it.

For me, the following have always been necessary but not sufficient conditions to make the truncating spaceship problem happen:

1 - Prior to the spaceship truncation, some other error with KOS caused the terminal to stop responding to typing. Sometimes just to the point where toggling the SCS power will fix it, and sometimes even worse where all of KSP freezes up and it has to be killed externally (from Task Manager, or kill -9 for unix people).

2 - You make the vessel containing the KOS piece that had the error have to be reloaded from rails back into the full physics engine, either by traveling within 2.2 km of it with another vessel, or by switching to it in the Tracking Station.

Unfortunately although I know those two things seem to be required for it to happen, they don't seem to be sufficient to make it happen every time.

Edited October 10, 2013 by Steven Mading

[ptreese84]

Sorry if posted. Did not see.

I can write scripts, save them and then edit them while flying a ship. But if i exit, relaunch or change my target i cannot find my saved script anywhere. Does not show when i use 'list.' on either volume. Is this intended? I had thought that they were saved until deleted.

[Superfluous J]

Sorry if posted. Did not see.

I can write scripts, save them and then edit them while flying a ship. But if i exit, relaunch or change my target i cannot find my saved script anywhere. Does not show when i use 'list.' on either volume. Is this intended? I had thought that they were saved until deleted.

This tripped me up too. The ship you're flying is its own computer, so when you leave it its programs vanish.

What you want to do is "switch to archive" and then create your script there, while on the ground. Save it, and then look through your ksp folder (on your actual computer, not in kOS) for the file name dot text. So if you "edit test." to create the file you're looking for test.txt. That folder is your archive, and you can actually edit the scripts there with notepad or whatever text editor you prefer (notepad++ is my favorite), and they'll show up on EVERY SHIP you make, so long as you SWITCH TO ARCHIVE first.

You can't do that in orbit, though, unless you've brought antennae with you. I don't know how many you need but the further you are the more you need.

You can also COPY FILENAME FROM ARCHIVE to get it on your ship's local drive. Copy all the files you need, then launch, and they'll be there on it's local drive for use later. However, you can't edit those scripts outside of KSP like the ones in the archive.

[Dunbaratu]

Screenshot of the ship disappearing bug, with debug log.

Here's a screenshot of the original vessel:

And here it is after the bug "ate" most of it:

Note the debug log showing the KOS exception in red. "masterTorch", do you get the same KOS exception when the bug happens to you? (You have to do a "view image" and explode it to full size to be able to read the red text in the debug log on the screenshot).

I also note that when I rotate the camera the interface is still behaving as if the center of the ship is in the right place for where it would be if all the parts were there. In other words, see how the disk that's showing is offcentered? If that was all there was to the ship it would be centered on the screen because the camera always aims at the center of mass. That makes me think that KSP sort of 'halfway" thinks the parts are still all there but you can't click them or do anything with them or see them.

[ptreese84]

This tripped me up too. The ship you're flying is its own computer, so when you leave it its programs vanish.

What you want to do is "switch to archive" and then create your script there, while on the ground. Save it, and then look through your ksp folder (on your actual computer, not in kOS) for the file name dot text. So if you "edit test." to create the file you're looking for test.txt. That folder is your archive, and you can actually edit the scripts there with notepad or whatever text editor you prefer (notepad++ is my favorite), and they'll show up on EVERY SHIP you make, so long as you SWITCH TO ARCHIVE first.

You can't do that in orbit, though, unless you've brought antennae with you. I don't know how many you need but the further you are the more you need.

You can also COPY FILENAME FROM ARCHIVE to get it on your ship's local drive. Copy all the files you need, then launch, and they'll be there on it's local drive for use later. However, you can't edit those scripts outside of KSP like the ones in the archive.

Thanks for clarifying. Cheers.

[Bizz Keryear]

if throttle = 0 {print "hallo".}

Gives flagrant error.

This seems broken to me. Can anyone confirm this?

Using 0.84.

Yes, me. And that was reported a while back on github, too.

[...]

And this:

lock throttle to throttle + 0.5.

Gives flagrant error, again.

Not sure if that is the use how it was intended. I think it should be

set x to 0.
lock throttle to x.
set x to x + 0.5.

But I might also be one of maaaany bugs in 0.84 if you not really need 0.8 feature try 0.71 instead (link below).

This too:

lock throttle to 1.
print throttle.

Gives me a 0.

[...]

print steering.

Always gives 0. Is this intended?[...]

No, that is something that broke after 0.8, but honestly I am too lazy to find out in which version exactly. Its also already reported on github.

Ok. Tried some steering commands in 0.84:

lock steering to heading 270 by 90.

seems broken.

Edit: Tried this again and is working now. Don´t now y...

I never had trouble with using steering in 0.84 or 0.82 (was broken in 0.83, though).

But like the eta error (see below) it might only happen in "special" cases.

 // the infamious eta error
print "some text".								//working
print "more text" + some_variable_internal_or_not.				//also working
print "even more text" + eta:apoapsis + "text after".				//no problem
print "lorem ipsum" + (eta:apoapsis) + "hey don't blame me I am out of ideas".	//is fine
print "dolor sit amet," + (eta:apoapsis).					//also fine
print "consetetur sadipscing elitr," + eta:apoapsis.				//throws a "unkown term eta" error!!!

Sorry if posted. Did not see.

I can write scripts, save them and then edit them while flying a ship. But if i exit, relaunch or change my target i cannot find my saved script anywhere. Does not show when i use 'list.' on either volume. Is this intended? I had thought that they were saved until deleted.

OK, Changes on your local drive are changes to ship that are made after launch. It should affect the ship like docking a vessel, as long as you are not revert to a point before that has happend (loading a quicksave made before or revert to launch). In that way the changes (at least they should be) are persistent.

Switching vessels, going to KSC or leaving the game and come back later shouldn't affect your programs. (All I mentioned here only applies to cases when you are don't get a "can't save here" warning from KSP). You have to save them from the internal editor with F5, though. But I am pretty sure you have them run at least once. (If you can run an edited program it means you have saved it, cause otherwise it would be gone at the moment you have left the editor.)

And if that is not the case for you and the programs are still gone try to use kOS 0.71 (link in the wiki -> issues page -> Old Versions)

And so far I can't confirm any trouble with saving in 0.84. (But I kinda lost track what I did test in which version...)

Screenshot of the ship disappearing bug, with debug log.

[...]

Uh, that is a drastic change of parts in the vessel ... Please report that on github, too Edited October 11, 2013 by Bizz Keryear

[Sma]

This tripped me up too. The ship you're flying is its own computer, so when you leave it its programs vanish.

What you want to do is "switch to archive" and then create your script there, while on the ground. Save it, and then look through your ksp folder (on your actual computer, not in kOS) for the file name dot text. So if you "edit test." to create the file you're looking for test.txt. That folder is your archive, and you can actually edit the scripts there with notepad or whatever text editor you prefer (notepad++ is my favorite), and they'll show up on EVERY SHIP you make, so long as you SWITCH TO ARCHIVE first.

You can't do that in orbit, though, unless you've brought antennae with you. I don't know how many you need but the further you are the more you need.

You can also COPY FILENAME FROM ARCHIVE to get it on your ship's local drive. Copy all the files you need, then launch, and they'll be there on it's local drive for use later. However, you can't edit those scripts outside of KSP like the ones in the archive.

I think the way it's meant to work (at least the way Kevin envisioned it working) is instead of switching to archive all the time, you would copy the program from archive, like you mentioned. Possibly why there is the range limitation for connecting to the archive, to try and force you to use the on board storage.

As far as editing the programs externally, I'm a fan of Notepad++ for most everything else but SolarLiner is working on an editor specifically for kOS, with syntax highlighting and what not. Wish it had tabs though, but it is a WIP.

Screenshot of the ship disappearing bug, with debug log.

Here's a screenshot of the original vessel:

Image was here

And here it is after the bug "ate" most of it:

Image was here

Note the debug log showing the KOS exception in red. "masterTorch", do you get the same KOS exception when the bug happens to you? (You have to do a "view image" and explode it to full size to be able to read the red text in the debug log on the screenshot).

I also note that when I rotate the camera the interface is still behaving as if the center of the ship is in the right place for where it would be if all the parts were there. In other words, see how the disk that's showing is offcentered? If that was all there was to the ship it would be centered on the screen because the camera always aims at the center of mass. That makes me think that KSP sort of 'halfway" thinks the parts are still all there but you can't click them or do anything with them or see them.

Interesting, I haven't had this problem yet, maybe I'm just not trying hard enough.

Don't you just love how descriptive "debug" is sometimes. Though I guess that's the point of exceptions is it isn't always specific. Better than just "there was a problem with something somewhere".

[Bizz Keryear]

[...]Don't you just love how descriptive "debug" is sometimes. Though I guess that's the point of exceptions is it isn't always specific. Better than just "there was a problem with something somewhere".

You mean: There was probably some problem at some point with something somewhere.

A bug description, that fits everywhere.

[masTerTorch]

Note the debug log showing the KOS exception in red. "masterTorch", do you get the same KOS exception when the bug happens to you? (You have to do a "view image" and explode it to full size to be able to read the red text in the debug log on the screenshot).

I made a little video showing two vessels showing the bug and one healthy vessel.

My observations:

1. When loading a vessel I get a exception in the debug log: "KeyNotFoundException: The given key was not present in the dictionary".

This will happen for buggy and healthy vessels. Seems to be a error of another mod I using. (Ioncross, Graphtron 2000, KOS Sensor reporter).

2. Buggy vessels will show the KOS Exception in debug log you found short after "CPU Inited".

3. Buggy vessels will go crazy by leaving the Flight Results Screen (F3). Almost all parts will disappear. Sometimes they are visible for second.

4. Switching from buggy vessels to other vessels per map switching dialog is not possible.

5. Buggy vessels don´t have an orbit shown on map.

6. The KOS of buggy vessels can not be toggled. The terminal can not be opened.

It is hard to find the circumstances that will trigger the problem.

It happend to me the first time by launching a probe to orbit. Switching back to Space Center while a deploy-script was running. When switching back to the vessels via trackingstation, I found the vessel buggy.

Your suspicion maybe true. I don´t know. But if they are true, then it is a bug of bug. Solve the problem that causes the terminal to stop responding and you will solve this bug. True?

We need a script that causes the terminal to stop responding to typing for further testing.

[Dunbaratu]

Your suspicion maybe true. I don´t know. But if they are true, then it is a bug of bug. Solve the problem that causes the terminal to stop responding and you will solve this bug. True?

We need a script that causes the terminal to stop responding to typing for further testing.

I would strongly suspect it's actually the other way around. The terminal not responding is probably the highest level side-effect of the bug, if you will, not the lowest level causal effect of it. Anything that makes KOS stop running properly will make the terminal fail like this. The reason the terminal fail is a commonality of so many bugs isn't because it's causing the bugs, but because its failure is a common effect of anything that breaks the execution of the SCS's CPU.

[bazilshep_]

Has anyone figured out how velocity:surface reports while on the mun? The method I'm using for kerbin gives nonsensical results, even though it appears to work perfectly on kerbin. It fits best on the mun if you assume that 144 should be added to the longitude, but that doesn't work quite correctly. The surface velocity code is shown below, can anyone spot any errors?

set lat to latitude.
set lon to longitude.
set vs to velocity:surface .

//calculate surface velocity in terms of unit vectors east, north, and up
set ve to vs:z * sin(lon) + vs:x * cos( lon ) .
set vu to vs:z * cos(lon)*cos(lat) - ( vs:x * sin(lon)*cos(lat) + vs:y*sin(lat) ) .
set vn to vs:z * cos(lon)*sin(lat) + vs:y*cos(lat) - vs:x * sin(lon)*sin(lat) .

[Dunbaratu]

Uh, that is a drastic change of parts in the vessel ... Please report that on github, too

Narrowing it down to a repeatable circumstance to trigger the problem is a prerequisite before that would be helpful. That's why I'm trying to gather data from others on the forum who had the same problem.