kOS Scriptable Autopilot System 0.9

[Bizz Keryear]

Interesting. I can not get it to work, but that does not mean it does not work. I am running kOS 0.9.1.

0.9.1 or 0.9.2 which claims to be 0.9.1

[Mulbin]

It was hard not to get, with four different explanations

Lol I didn't read any of them, you all ninja posted while I was typing that I had worked it out for myself! Thanks anyway everyone lol

[Camacha]

0.9.1 or 0.9.2 which claims to be 0.9.1

In retrospect the latter

[Bizz Keryear]

In retrospect the latter

Doesn't matter I just found out that it isn't in the current build. You can make your own, though. Which I am now trying to do... my first time I ever will compile a C(#)... let hope for the best.

[Bizz Keryear]

GITHUB: Does someone knows how I integrate branches from another (3rd) person into my branch?

The way I try it it always says: no differences. But I know for sure a1270 has done some.

And: Argh I cant get it work ... I have to learn how to compile C# programs ... especially in context to unity ... I think I am missing files.

Edit: a1270 ... or anybody who is firm in compiling C# in context with KSP/Unity please PM me. I need help.

Edited November 24, 2013 by Bizz Keryear

[adammada]

http://wiki.kerbalspaceprogram.com/wiki/Plugins - worked for me.

[mileshatem]

I've spent awhile trying to figure out why I couldn't set a maneuver node properly with kOS, to finally figure out that the documentation in the readme on github is a bit off. It seems that TIME does return a value of universal time, but kOS doesn't consider it to actually be a "number". To clear up the confusion in the documentation, the changes I think that need to be made are:

In the "NODE (universalTime, radialOut, normal, prograde)" there's the line:

SET X TO NODE(TIME+60, 0, 0, 100).

I believe that should be changed to:

SET X TO NODE(TIME:SECONDS+60, 0, 0, 100).

A similar error is under the command reference > add section

I don't have a github account to request to make a change, but if that could be fixed at some point it'd probably save some people the debugging trouble I've gone through.

[Dunbaratu]

I've spent awhile trying to figure out why I couldn't set a maneuver node properly with kOS, to finally figure out that the documentation in the readme on github is a bit off. It seems that TIME does return a value of universal time, but kOS doesn't consider it to actually be a "number". To clear up the confusion in the documentation, the changes I think that need to be made are:

In the "NODE (universalTime, radialOut, normal, prograde)" there's the line:

SET X TO NODE(TIME+60, 0, 0, 100).

I believe that should be changed to:

SET X TO NODE(TIME:SECONDS+60, 0, 0, 100).

A similar error is under the command reference > add section

I don't have a github account to request to make a change, but if that could be fixed at some point it'd probably save some people the debugging trouble I've gone through.

There are loads of object casting problems in kOS like this, which are, IMO, made worse by the decision to mask off and hide the precise type information from the user. When floats, doubles, integers, and long integers are all called just "Number" by the code, in an attempt to make things "easier" for the user, that attempt backfires and makes things harder when a user sees a message claiming you can't add a "number" to a "number", or can't compare a "number" to a "number", and the user goes "WTF are you talking about? Of COURSE I can add numbers to numbers. I do it all the time." What the code was actually doing was complaining about two different types (say, Float and Integer for example), but then masking their type names when displaying them to the user, so they both got called just "number", which leads to that ridiculous looking error message.

There's been a lot of pull requests about trying to fix this with getting all things in the system to return the same type: Double, but I can't help but wonder if the right solution isn't to tackle this root problem:

Why on earth can't KOS cast between integers, floats, and doubles in the first place, as need be?

The fact that something returns integer instead of double shouldn't BE a problem in the first place. There's plenty of very well defined type promotion rules for how to handle mixed number types in expressions. If you add an integer to a double, you promote the integer into a double first, then do the operation and return a double.

This is exactly what happens using low-level primitives in C:

int a = 5;

double x = 6.0123;

double y = x + a; // works just fine because the expression temporarily makes a double version of 'a' to add it to x.

I find it really odd that this behavior gets lost when using objects like Integer and Double rather than primitives like int and double. It seems like a step backward that the more high-level objects are actually LESS useful than their primitive counterparts.

[Camacha]

The fact that something returns integer instead of double shouldn't BE a problem in the first place. There's plenty of very well defined type promotion rules for how to handle mixed number types in expressions. If you add an integer to a double, you promote the integer into a double first, then do the operation and return a double.

Like you said, Kevin tries to make this language accessible. If you include all sorts of stuff that is common knowlegde to the programmer it might not get any easier for the new user. I think that there are certain problems with the current system that must be solved, but that it is not necessarily inherently bad.

[Dunbaratu]

Like you said, Kevin tries to make this language accessible. If you include all sorts of stuff that is common knowlegde to the programmer it might not get any easier for the new user. I think that there are certain problems with the current system that must be solved, but that it is not necessarily inherently bad.

What I'm saying is that it's perfectly safe to use the technical terms when reporting a bug to the user, the existence of which already renders the beginner-friendly goal moot. After everything is working right and kOS is more robust, in order to achieve the goal of making it beginner-friendly, the language is going to have to "just work" when it comes to casting numerical types into each other. Therefore go ahead and use the real info when reporting a message that can only occur when that goal isn't working. Problems with mismatched number types are the sorts of problems that can only happen when the beginner-friendliness isn't quite all there anyway.

[Camacha]

What I'm saying is that it's perfectly safe to use the technical terms when reporting a bug to the user, the existence of which already renders the beginner-friendly goal moot. After everything is working right and kOS is more robust, in order to achieve the goal of making it beginner-friendly, the language is going to have to "just work" when it comes to casting numerical types into each other. Therefore go ahead and use the real info when reporting a message that can only occur when that goal isn't working. Problems with mismatched number types are the sorts of problems that can only happen when the beginner-friendliness isn't quite all there anyway.

Fair point

[Dunbaratu]

Has anyone else had these things happen?

After running a KOS script for a while, some of the user interface elements of KSP look messed up and bits of the widgets are blank. The game continues to function but you can't see some of the displays.

Specific examples I have seen of this are:

1 - throttle slider gone. The slider indicator disappears, and sometimes the notches aren't drawn either, turning the slider into a blank grey arc.

2 - round altimeter widget gone from the top of the screen, a blank grey where it's supposed to be. (the rolling number wheels are there, but the 'clock-style' circular part is gone).

3 - sliding chevrons in the staging/docking indicator on the lower left are missing.

4 - RCS and SAS lights are masked off in the navball.

5 - Some of the indicators on the navball are missing - maybe it has crosshairs but not the prograde mark, or visa versa.

Also, switching to map view shows a different set of UI problems on the navball, usually. Maybe problems 4 and 5 might exist on map view, while they don't exist on camera view, but problem 1 does instead, for example. It is inconsistent which problems occur in different runs of the same mission with the same KOS code.

As far as I can tell it appears to be a problem with the ORDER in which KSP draws the UI elements. They flicker in occasionally such that I think they're there but they're layered on top of each other in the wrong order, so for example the background plate for the throttle arc gets drawn on top of the throttle chevron rather than under it.

Has anyone else had this happen? It seems to coincide with the 'pausing' hitches in game performance. Once I start getting a lot of pausing hiccups, I also get the UI problems.

[Camacha]

Yes, I have seen this on multiple occasions. I viewed it as a general indication that the current boot of KSP was going wonky due to some bugs in kOS, just like with the stutter behaviour.

[Dunbaratu]

Yes, I have seen this on multiple occasions. I viewed it as a general indication that the current boot of KSP was going wonky due to some bugs in kOS, just like with the stutter behaviour.

It might be a timing issue that is altering the order in which widgets get drawn when it gets laggy.

[Bizz Keryear]

Since Kevin isn't around for a while now I decided it might be time to play test the next improvements.

I have put it here http://kos.wikia.com/wiki/Sidebar_Topics (current direct link https://github.com/BiZZKeryear/KOS/releases/tag/0.9.2.1)

More to come once I figure out how to merge the latest pushes for Nivekk/kOS into my fork.

[Mulbin]

Is there any way to permanently save a program? F5 saves it during the current mission, but if I go back to the space center and start a new flight the program is always gone (edit "filename" just starts a new file rather than opening the old one)... am I doing something wrong, or do you have to type the whole program in every time you launch?

[MSD]

If you write the program in-game, switch to archive first.

[ switch to 0. ]

On boot the volume ( the "disk" it uses ) is set as the local volume. These programs are onboard, And limited to 10k total, the archive volume is back on kerbin, so if you want to keep programs you can copy them. The local volume is persistent on the current vessel and only avaible on the current vessel. The archive is avaible on all other vessels within range of kerbin.

You can read more about it on the wiki under volumes

Edited November 24, 2013 by MSD
addendum

[Mulbin]

If you write the program in-game, switch to archive first.

[ switch to 0. ]

On boot the volume ( the "disk" it uses ) is set as the local volume. These programs are onboard, And limited to 10k total, the archive volume is back on kerbin, so if you want to keep programs you can copy them. The local volume is persistent on the current vessel and only avaible on the current vessel. The archive is avaible on all other vessels within range of kerbin.

You can read more about it on the wiki under volumes

Awesome, thanks!! Also I really love the way the ship cpu is limited to 10k... nice touch

[Dunbaratu]

Another important difference between archive and local volume is that the local volume is saved in the campaign saved game, while the archive is saved outside of he campaign directory.

Therefore programs you store in the archive are not only available to different ships, but also between different save games.

[Dunbaratu]

Yes, I have seen this on multiple occasions. I viewed it as a general indication that the current boot of KSP was going wonky due to some bugs in kOS, just like with the stutter behaviour.

I've also noticed this seems to happen for me only after having done a "revert to launch" or "revert to vehicle assembly bay".

I wonder if some aspect of the KOS module isn't being properly unloaded and in some way a piece if it is still trying to execute from the previous run. i.e. the part is gone but there's still a bit of a hook leftover in the DLL that's still trying to do something.

[Amloris]

Hello, everyone! I have been tinkering with this mod over the last couple weeks in my fleeting free time and I have to say I love it (even though it has its quirks ).

However, I have some questions that I need some help with. I have tried everything that I can think of, so I figure it's better to ask the community before I proceed to bang my head against the wall any more than I already have.

First Question

I am trying to create system responses through the use of action keys for a functional menu system. I saw that the KOS Space Computer thread accomplished this feat, but I am having difficulties replicating their success, and to be honest I doubt whether it is still possible in the most current version. The following simplified code is a portrayal of what I want to work, but have not gotten to function properly yet.

Note: The spacecraft that is being tested on is in orbit.

CLEARSCREEN.

SET X TO 0.

UNTIL ALTITUDE < 70000 {
 IF AG1 == "TRUE" {SET X TO 1.}.
 IF X = 0 {PRINT "FAILED" AT (0,0).}.
 IF X = 1 {PRINT "DETECTED" AT (0,0).}.
}.

I'm sure that I am missing something absolutely trivial (a common case in programming). I would appreciate any input on this matter so that I can sleep better tonight.

[Dunbaratu]

Hello, everyone! I have been tinkering with this mod over the last couple weeks in my fleeting free time and I have to say I love it (even though it has its quirks ).

However, I have some questions that I need some help with. I have tried everything that I can think of, so I figure it's better to ask the community before I proceed to bang my head against the wall any more than I already have.

First Question

I am trying to create system responses through the use of action keys for a functional menu system. I saw that the KOS Space Computer thread accomplished this feat, but I am having difficulties replicating their success, and to be honest I doubt whether it is still possible in the most current version. The following simplified code is a portrayal of what I want to work, but have not gotten to function properly yet.

Note: The spacecraft that is being tested on is in orbit.

CLEARSCREEN.

SET X TO 0.

UNTIL ALTITUDE < 70000 {
 IF AG1 == "TRUE" {SET X TO 1.}.
 IF X = 0 {PRINT "FAILED" AT (0,0).}.
 IF X = 1 {PRINT "DETECTED" AT (0,0).}.
}.

I'm sure that I am missing something absolutely trivial (a common case in programming). I would appreciate any input on this matter so that I can sleep better tonight.

One simple thing that it might be is just this: Where was the keyboard focus when you pressed ALT-1? The trick of using action groups as a roundabout way to get live key input requires that you are in the camera view (not map view) and that the terminal window NOT be focused. It has to be "greyed out" because unless your kepressess are passing through to the KSP game, hitting ALT-1 doesn't trigger action group 1.

[Bizz Keryear]

Is there any way to permanently save a program? F5 saves it during the current mission, but if I go back to the space center and start a new flight the program is always gone (edit "filename" just starts a new file rather than opening the old one)... am I doing something wrong, or do you have to type the whole program in every time you launch?

If you write the program in-game, switch to archive first.

[ switch to 0. ]

On boot the volume ( the "disk" it uses ) is set as the local volume. These programs are onboard, And limited to 10k total, the archive volume is back on kerbin, so if you want to keep programs you can copy them. The local volume is persistent on the current vessel and only avaible on the current vessel. The archive is avaible on all other vessels within range of kerbin.

You can read more about it on the wiki under volumes

its not recommended run programs directly from the archive since future versions may cut the program as soon you leave the com range.

it is recommended to write your programs on the archive (out of the game while using notepad++ or the in meanwhile outdated kOS IDE) and copy it to your vessel before flight.

[Camacha]

I've also noticed this seems to happen for me only after having done a "revert to launch" or "revert to vehicle assembly bay".

I would not be able to tell how KSP and kOS operate without reverting, as my current project involves lots of reloading and reverting.

I wonder if some aspect of the KOS module isn't being properly unloaded and in some way a piece if it is still trying to execute from the previous run. i.e. the part is gone but there's still a bit of a hook leftover in the DLL that's still trying to do something.

I am not sure what the technical background is, but there seems to be something building up (.ie left over) indeed.

or the in meanwhile outdated kOS IDE

The IDE is very workable! Some of the newest terms are not fully recognized, but it works very nicely.

Edited November 25, 2013 by Camacha

[AbeS]

Is it too hard to get isp, like we get maxthrust? that would be a pretty nice addition, also dry and/or fuel mass would be wonderful! KER and MJ have that info already!