kOS Scriptable Autopilot System 0.9

[Dunbaratu]

@MaHuJa: I've been trying the build you made to work with 0.23 KSP and I noticed its version is listed as 0.93 in the terminal window, which makes me think it has more changes than just the ones you did to make it work with KSP 0.23.

Did you build it from code on github that also contains other changes from other people too? Because I noticed it won't parse any of my programs because this syntax that used to work in 0.92 no longer works in your build:

if someVar = "literal string here" { print "hi". }.

You can no longer compare against a literal string. It used to work in 0.92.

If this is an intentional new change and is to be expected in future versions of kOS then I'll go though my scripts and change them all, but if it's an accidental change that's the result of someone making a mistake when editing the code, then I'll leave my scripts alone and wait.

[Camacha]

I don't think kOS currently has the ability for the parent vessel to run a program on a "child" vessel, unless it's just a matter of setting everything up just right.

You could have them write to a shared script on the archive to coordinate efforts Just make sure every unit reads and writes at separate times , otherwise kOS chokes. It is also possible to have all kOS units look at the clock time, to coordinate their efforts in a similar way. Either way you will have to make sure that unloading does not occur, so you will need a mod to expand the (un)loading limits.

If this is an intentional new change and is to be expected in future versions of kOS then I'll go though my scripts and change them all, but if it's an accidental change that's the result of someone making a mistake when editing the code, then I'll leave my scripts alone and wait.

Either way it would be good to have some sort of documentation, to reduce the guesswork what is a feature and what is not.

[togfox]

Okay - so got kos for 0.22 in version 0.22. Installs and runs fine.

Gotta say - very hard to find instructions on where to store a script file and how to load it. I've worked out the archive thing but really not intuitive. Whoever runs the wiki should have that as the very first page. Anyhow, moving on ...

When I type commands into the console, those keystrokes are also sending commands to KSP/craft. So when I type

PRINT "Hello World".

The space after the print stages my rocket while I'm on the launch pad. I locked the staging in this instance but the problem still stands. As I'm typing commands my craft is doing all sorts of random things as I type. I'm sure this is mentioned many times in the 2451 posts in this thread. Also another one for the wiki if there is a quick answer to this.

Onto more serious things: I want to design a ground radar for automated landing, and I don't mean "control thrust; extend legs; touch down". I mean scan an area of terrain, determine the gradiant of the slope, and then move or abort the landing if the gradient is too steep (i.e the side of a crater or mountain).

To do this I would scan a series of lat/long points and the true altitude at that point (not radar altitude). Simple trig will give me the gradient of slope between two points. I question how to store these points in kos. I would want something like:

set lat = latitude

set long = longitude

terrain(lat, long) = altitude

This is essentially a 2d array, because its mapping a 2d space. Will the above notation work or something similar? Of course, anything I get to work will be shared for reuse. Thanks.

[Camacha]

Gotta say - very hard to find instructions on where to store a script file and how to load it. I've worked out the archive thing but really not intuitive. Whoever runs the wiki should have that as the very first page. Anyhow, moving on ...

This has been mentioned in this topic more than a couple of times, but yes, there also has been mention of a need to add this clearly to the wiki on a couple occasions You are right, it can be a bit confusing for newcomers.

When I type commands into the console, those keystrokes are also sending commands to KSP/craft.

I have not tried the new version yet, but that should not happen. In any case it is advisable to use an external editor, as those are a lot easier to work with and you spare some of the frustrations of doing it in-game (like your input confusion mess). I would suggest the kOS IDE.

To do this I would scan a series of lat/long points and the true altitude at that point (not radar altitude).

At the moment, it is only possible to get altitude and radar altitude directly below your location. This means you will have to physically move between the points you want to measure. You could get the true altitude by deducting radar altitude from altitude (150 meter on the altimeter - 14 radar altimeter meters = ground level at 136 meter) .

Will the above notation work or something similar?

I do not think so. The commands will do something, but if I understand you correctly, they will do something completely different than what you want. Be mindful of using abbreviations for variable names that might already mean something else. Unfortunately, arrays are not yet implemented at the moment. However, there is a log function that allows you to write to a logfile. This includes the possibility of writing program code that can be executed later. If you do this in a smart way, you will be able to build a logfile that contains the height data in a usable manner so it can be used later. This also allows you to use a large amount of variable names, as opposed to having to hard code a limited number of them.

I have suggested building seperate laser rangers for kOS in another topic, but if those ever come to be they are a long way off. It would be pretty good to have one on each corner of your vehicle pointing down, knowing right away what the ground conditions underneath your craft are.

Edited December 21, 2013 by Camacha

[togfox]

I want to take radar measures on the way down, directly underneath me, and store a map of sorts in an array. As horizontal movement approaches zero for landing, I'll know if the vessel is above flat ground or on a slope. The maths is easy but storing a 2d array in the way I want to is probably beyond kos.

Getting really ambitious here, tongue in cheek even, maybe I can write to a file and create a text file database of lat, long, and altitude. :-) (no, I'm not serious about that idea).

I'll see if I can source an older version of kos for 0.22 to fix that typing problem because even

Copy file from archive.

Contains enough spaces to stage your rocket into oblivion.

[Dunbaratu]

Okay - so got kos for 0.22 in version 0.22. Installs and runs fine.

Gotta say - very hard to find instructions on where to store a script file and how to load it. I've worked out the archive thing but really not intuitive. Whoever runs the wiki should have that as the very first page. Anyhow, moving on ...

What there should be to solve this is a sort of basic walkthrough to build a "hello world" sort of program. It would include an example of where the archive is and so on. I wonder what a "hello world" would be for kOS, though. A program that just unconditionally shoots off at a 45 degree angle for a few seconds, cuts the engines and hits the chutes perhaps? Kevin originally had some basic simple scripts but they don't start from the beginning of the process. A good hello world walkthrough should actually start from assembling a simple crude rocket in the VAB, editing the code in an external editor, where to copy the code to in an installation, and so on.

When I type commands into the console, those keystrokes are also sending commands to KSP/craft. So when I type

PRINT "Hello World".

The space after the print stages my rocket while I'm on the launch pad. I locked the staging in this instance but the problem still stands. As I'm typing commands my craft is doing all sorts of random things as I type. I'm sure this is mentioned many times in the 2451 posts in this thread. Also another one for the wiki if there is a quick answer to this.

With the exception of two keypresses that can't be exclusively trapped by a mod, which are "X" and "Backspace/Del", that's not supposed to happen. If it's happening then something wrong is going on. Do you have other mods installed? Sometimes different mods "argue with each other" over who gets control of the kepresses.

Onto more serious things: I want to design a ground radar for automated landing, and I don't mean "control thrust; extend legs; touch down". I mean scan an area of terrain, determine the gradiant of the slope, and then move or abort the landing if the gradient is too steep (i.e the side of a crater or mountain).

There should be a variant of the ground radar that aims in the direction the craft is pointed. But there isn't. It always aims straight down no matter how the craft is oriented. That makes it hard to scan an area because you have to move the craft over it instead of just rotating the radar receiver back and forth. If I knew more about the artwork side of things I'd consider going through the effort to make a radar part that does this. You mount it on the craft and it always reads the way it's pointed (so mount it upside down to scan the ground) and when the part tilts (by tilting the craft) it also changes its aim to match. I just don't know enough about KSP to do it.

To do this I would scan a series of lat/long points and the true altitude at that point (not radar altitude). Simple trig will give me the gradient of slope between two points. I question how to store these points in kos. I would want something like:

set lat = latitude

set long = longitude

terrain(lat, long) = altitude

This is essentially a 2d array, because its mapping a 2d space. Will the above notation work or something similar? Of course, anything I get to work will be shared for reuse. Thanks.

kOS does not support arrays right now. There's a few things that it's hard to implement because of that. You can't make a generic algorithm that operates on arbitrary amounts of data when you need a different hardcoded variable name for each and every piece of data. You could hardcode a solution for a known small array size with variable names like arr11, arr12, arr13, arr21, arr22, arr23, arr31, arr32, arr33, but you can't write code that lets you, say, pass in any arbitrary M and N for the array sizes.

Edited December 21, 2013 by Steven Mading

[Camacha]

I want to take radar measures on the way down, directly underneath me, and store a map of sorts in an array. As horizontal movement approaches zero for landing, I'll know if the vessel is above flat ground or on a slope. The maths is easy but storing a 2d array in the way I want to is probably beyond kos.

You can store anything along the way, with some fantasy. I am just not sure it is enough to really map the surroundings.

Getting really ambitious here, tongue in cheek even, maybe I can write to a file and create a text file database of lat, long, and altitude. :-) (no, I'm not serious about that idea).

Should be possible. Should not be hard, actually.

I'll see if I can source an older version of kos for 0.22 to fix that typing problem because even

Copy file from archive.

Contains enough spaces to stage your rocket into oblivion.

Apparently that is a new or reintroduced error, but if you use a proper IDE that is no problem. Inputs are indeed undesireable, but those did not and should not occur. I can imagine they are very annoying if they do.

[togfox]

So a dynamic array is too much to ask for so ill move to a fixed number of data points ( say 10 for example). Program flow:

Assuming a starting orbit of 100km x 100km

Turn retro

Reduce horizontal speed to 10 m/s

Use standard thrust algorithms to control vertical speed during descent

When radar height = 2000m, start testing terrain, meaning:

Store current alt every 10 seconds ( or whenver)

Scan1lat = latitide

Scan1long = longitude

Scan1alt = altitude

10 seconds later store the next scan

Scan2lat = latitude

Etc

Recycle scan1 when i fill all of my "array".

On the way down, scanning evey few seconds, ill know if the terrain is getting better or worse, because i have a surface speed of 10 m/s. I can determine the gradient between my current location and my 10 previous locations and decide if i should continue on the current track (gradient is getting progressively flatter) or if rcs should be activated and the course reversed back to one of my previously recorded lat/longs.

All of this is during a fuel hungry controlled descent of course. So, while my 'map' would be very linear, i would be able to tell if ive moved away from a flat land into a towering cliff face and reverse course. What it wont do is tell me that just beyond the cliff face is a field of marshmellows with the greatest landing spot ever. Not shooting for perfect here, just want to remove some of the randomness with unattended landings.

Thr game engine wont tell me where im going but i can certainly track where ive been and react accordingly. Doable?

[Dunbaratu]

Apparently that is a new or reintroduced error, but if you use a proper IDE that is no problem. Inputs are indeed undesireable, but those did not and should not occur. I can imagine they are very annoying if they do.

At minimum even if you edit all the code externally you still have to type at LEAST the spaces in the following commands:

copy[space]programname[space]from[space]0.

run[space]programname.

If those cause stages to execute that's still going to make the mod unusable.

I haven't seen this behavior. Something is wrong with the installation.

[Dunbaratu]

So a dynamic array is too much to ask for so ill move to a fixed number of data points ( say 10 for example). Program flow:

You can't do arrays but you can do vectors of 3 numbers. The intent was to use them for xyz coordinates but technically you could use them as a crude 3x1 array until such a time as the language actually supports arrays.

[Dunbaratu]

Which of the following script language features would be most useful? Just taking a survey of people's opinions. This is NOT a question about the instrumentation or the I/O for controlling the craft. This is about basic language features the syntax should be made to support and which ones people think are best. Also, this isn't about fixing obvious bugs, like the misreported line numbers on errors, but about new features.

Keep in mind that things that would confuse non-programmers need to be considered with great caution.

* A way to explicitly declare a variable to be local (so it goes out of scope when the sub-program run ends).

* A way to embed quote marks inside literal strings.

* A way to give programs return values (so you can use them in expressions such as SET X to 1 + run myProg(y).).

* A way to make array variables. (if they can contain any arbitrary object then a 2-D array would be doable as an array of arrays).

* ONCPU: A way to make one CPU tell another CPU to execute an arbitrary command on itself (i.e. ONCPU 2 run prog1.) (only if they're on the same vessel).

* BOOT.txt: A standard convention that if a volume contains a program called BOOT on it then this program is auto-executed after the CPU is started or restarted.

Feel free to add to the list if there's something obvious I missed.

[togfox]

My experience is about 6 hours long, but option 3 then 6.

As a developer, i recognise the importance of item 3.

[diomedea]

IMO, options 3, 4 and 1 in that order.

Further features to add (using typical BASIC keywords here, but not necessarily the same with kerboscript):

- INPUT statement, to let the program wait for a value from the user then continue using that value.

- GOSUB... RETURN, to manage subroutines within the same program (instead of having to load another program to do that).

and with the above, of course, some form of label, to name the subroutines.

[togfox]

I was afraid to ask for functions. gosub / return works the same way.

btw - my 'focus' thing with the keys fixed itself with a reinstall of kos.

[KvickFlygarn87]

Where's Kevin? Also, does it work in .23?

[Sacred Aardvark]

I'll see if I can source an older version of kos for 0.22 to fix that typing problem because even

Copy file from archive.

Contains enough spaces to stage your rocket into oblivion.

Haven't had that issue, but just a thought, would locking staging help? (alt+L)

Or swapping from staging to docking controls so space only swaps between rotation and translation controls, instead of staging.

[AeroEngy]

@Steven Mading that is a nice list.

1) I would just suggest all vars be local to a program unless specifically declared as global.

3) Returning values would be very nice. I would like to see returning multiple values at once though. Although if we had arrays (or the ability to create custom structures) this could be worked around. ...

4) Arrays, Yes please and multidimensional.

One other minor gripe. I would love to replace the period statement terminator with a semicolon.

[Dunbaratu]

@Steven Mading that is a nice list.

1) I would just suggest all vars be local to a program unless specifically declared as global.

3) Returning values would be very nice. I would like to see returning multiple values at once though. Although if we had arrays (or the ability to create custom structures) this could be worked around. ...

4) Arrays, Yes please and multidimensional.

One other minor gripe. I would love to replace the period statement terminator with a semicolon.

I am mindful of the original intent of Kevin to make this not TOO hard for non-programmers to get started with. So the idea of variables being global by default. while terrible programming practice for "real" programming, does ease the barrier to entry for new people. Since one of the design goals was to make declaring variables optional, and allowing them to just be made by using them, you have to decide how those implicit declarations behave. Thus globals by default, locals only if explicit. Also, I'm trying to suggest the least syntax changes as possible. Making the behavior be identical to what it used to be if you don't change the script code keeps things backward compatible with Kevin's original design.

I too think the period is a bad idea. But I'm mindful of the idea that even if we do decide to "steal away" Kevin's project for now I want to be nice to him and leave it in a state that he would accept if he comes back.

Basically when it comes to a conflict between "do it the way I'd prefer" versus "do it the way that looks most similar to the rest of the language" I'll side with making it look like the rest of the language. That's also why I suggested a syntax like "SET X to 1 + run myProg." for return values, inserting the word "run" in there just to keep it consistent even though that looks weird to us old-time programmers.

Edited December 21, 2013 by Steven Mading

[Rosco P. Coltrane]

I haven't delved into the kOS code a lot: but what about some sort of "compiler directive"? So the default would be global variables and programs don't return any value, and if you want you can specify, say, "//KOS093" and it would cause the program to be interpreted with local variables and any new things the community might come up with.

I too think the period is a bad idea. But I'm mindful of the idea that even if we do decide to "steal away" Kevin's project for now I want to be nice to him and leave it in a state that he would accept if he comes back.

Yeah, I think we're counting the chicken before they hatch.

Edited December 21, 2013 by Rosco P. Coltrane

[Camacha]

I would very much like action group keypresses not to perform a break in the program. That would increase their usefulness a lot. If you really need a break at that point, you can easily add it manually through on ag9 {sas on. break.}.

* A way to explicitly declare a variable to be local (so it goes out of scope when the sub-program run ends).

If that would completely clear it from the unit it would help. No lingering variables that can cause havoc the second time the code is run.

* A way to give programs return values (so you can use them in expressions such as SET X to 1 + run myProg(y).).

Do you mean you can use a program as a sort of complex variable that executes the code in that program when used?

Personally I would like to see program names that can be set by variables instead of fixed strings and the same with the .txt extension. It would allow to directly write CSV files, for instance.

* A way to make array variables. (if they can contain any arbitrary object then a 2-D array would be doable as an array of arrays).

This would be useful of course, but also adds complexity for beginners. It is fundamental to programming, but also initially potentially confusing.

* ONCPU: A way to make one CPU tell another CPU to execute an arbitrary command on itself (i.e. ONCPU 2 run prog1.) (only if they're on the same vessel).

This could be useful to start up a program before seperating stages or, if you want to complicate things, implement multithreading.

* BOOT.txt: A standard convention that if a volume contains a program called BOOT on it then this program is auto-executed after the CPU is started or restarted.

This would be my number one wish. No more enlessly copying and starting programs and from the story side of things a major improvement. It enables you to write proper firmware.

Edited December 21, 2013 by Camacha

[AeroEngy]

I am mindful of the original intent of Kevin to make this not TOO hard for non-programmers to get started with. So the idea of variables being global by default. while terrible programming practice for "real" programming, does ease the barrier to entry for new people. Since one of the design goals was to make declaring variables optional, and allowing them to just be made by using them, you have to decide how those implicit declarations behave. Thus globals by default, locals only if explicit. Also, I'm trying to suggest the least syntax changes as possible. Making the behavior be identical to what it used to be if you don't change the script code keeps things backward compatible with Kevin's original design.

I too think the period is a bad idea. But I'm mindful of the idea that even if we do decide to "steal away" Kevin's project for now I want to be nice to him and leave it in a state that he would accept if he comes back.

Basically when it comes to a conflict between "do it the way I'd prefer" versus "do it the way that looks most similar to the rest of the language" I'll side with making it look like the rest of the language. That's also why I suggested a syntax like "SET X to 1 + run myProg." for return values, inserting the word "run" in there just to keep it consistent even though that looks weird to us old-time programmers.

I don't disagree with any of your points and see where you are coming from. However, I just thought if someone was to fork this project and take over, getting rid of some of the odd syntax and bad features like all globals would be a good place to do it. Carrying forward bad code/habits just for the sake of backwards compatible isn't always the best idea and a fork seems like the correct place to make the break. But like I said before I am not a programmer by trade, couldn't help with the mod if I wanted to (besides general suggestions ) and I will be grateful for whatever effort someone puts into this mod.

[Camacha]

I don't disagree with any of your points and see where you are coming from. However, I just thought if someone was to fork this project and take over, getting rid of some of the odd syntax and bad features like all globals would be a good place to do it. Carrying forward bad code/habits just for the sake of backwards compatible isn't always the best idea and a fork seems like the correct place to make the break. But like I said before I am not a programmer by trade, couldn't help with the mod if I wanted to (besides general suggestions ) and I will be grateful for whatever effort someone puts into this mod.

To be honest, if you are going to do that you will need to start from scratch. The entire syntax and setup is designed with first timers in mind. It would be a bit foolish to remove some of the things that are technically considered less than ideal but should not be a major hassle if you know what you are doing (like globals), but keep major features like the English-like syntax. You will end up with a very strange mismatched set of implementations of several contrasting ideas.

It is also not very practical to (possibly) have two similar languages with partially shared syntax, yet that are not compatible. Something like that is just asking for trouble and confusion. Not to mention the addition of even more forks.

[togfox]

Any syntax that doesnt look like c+/c# is fine by me! :-)

Seriously but, this was built on a dream of easy syntax for noobs. Lets keep the purists at the door and continue the dream.

[Dunbaratu]

Any syntax that doesnt look like c+/c# is fine by me! :-)

In other words, kosscript. which looks nothing like c++ or c#. There is exactly 1 thing ONLY it shares with C++ and that's the curly braces. That's IT. Nothing else looks anything remotely like C++. To claim it looks like C++ is to reduce C++ down to one single teeny tiny aspect of the language and ignore everything else about it.

Seriously but, this was built on a dream of easy syntax for noobs. Lets keep the purists at the door and continue the dream.

It's an impossible dream to a certain extent. unless you sacrifice functionality to get simplicity. Programming languages are complex not because programmers go around trying on purpose to make life harder for themselves, but because there's a minimum complexity inherent in their flexibility.

[Dunbaratu]

To be honest, if you are going to do that you will need to start from scratch. The entire syntax and setup is designed with first timers in mind. It would be a bit foolish to remove some of the things that are technically considered less than ideal but should not be a major hassle if you know what you are doing (like globals), but keep major features like the English-like syntax. You will end up with a very strange mismatched set of implementations of several contrasting ideas.

It is also not very practical to (possibly) have two similar languages with partially shared syntax, yet that are not compatible. Something like that is just asking for trouble and confusion. Not to mention the addition of even more forks.

I think that if someone wants to make a kos-like mod starting from the existing code and forking it, but change so much about it that it is no loner recognizable as being the same basic language structure, that the proper way to do that would be to pick a brand new name for that project and call it a different mod entirely. Continuing to call it the same thing when it's totally different would lead to unnecessary confusion.