[1.3] kOS Scriptable Autopilot System v1.1.3.0

[airbus a320]

Since most of people prefer to use external text editor they removed the in game editor. Archive is a drive without space limitation (the KSC data server), while 1 is the disk on your vessel... You have to download your programs into 1 (copy [script_name] from 0.) . if you prefer you can edit kos config file, there is something like "start from archive" but remember that you can access to the archive only if you are in communication range!

[Dunbaratu]

What i mean is when I run KOS every time i need to type switch to 0, and place my txt file out side the gamedata folder to be read ( J:\Program Files\Steam\steamapps\common\Kerbal Space Program\Plugins\PluginData\Archive ), then its fine.

You do not need to do both these things every time. You do need to type "switch to 0." each time, but you don't need to keep re-copying the text file each time. It should still be there from last time. If it's getting erased between runs then something is wrong and that's a bug.

also i have seen vids of scipts being edited in the KOS UI and saved from there I can't do this!

The in-game text editor was removed as it was getting in the way of more important updates. Something does need to replace it but it will probably involve just calling out to a generic UI text widget. Right now it's not there.

It would be perfect if the script could be loaded from my public documents so i can edit it on my laptop,

My goal is to be able to control my rover over wifi or even the net. only seeing what its cameras can see (like real missions).

a simple config file for the archive directory would solve this.

It shouldn't be too hard to make a simple shell script or "batch file" to just copy everything into the archive from somewhere else. (I use a perl script that also strips out indents and comments as it does this to help compensate for the fact that kOS rewards you for writing illegible code. - something unrealistic that I never liked but I don't think I can convince the others to change it.)

I like the idea of a config option to pick whatever archive location you like.

Edited May 12, 2014 by Steven Mading

[airbus a320]

. (I use a perl script that also strips out indents and comments as it does this to help compensate for the fact that kOS rewards you for writing illegible code. - something unrealistic that I never liked but I don't think I can convince the others to change it.)

I like the idea of a config option to pick whatever archive location you like.

It's not unrealistic, the lunar descent script on the Apollo was written in a cryptic language similar to assembly

https://code.google.com/p/virtualagc/source/browse/trunk/FP8/FP8.s?r=258

http://www.ibiblio.org/apollo/Pultorak_files/FP8Listing.pdf

Edited May 12, 2014 by airbus a320

[MKI]

Whats up with the editor not working? Seems like a killer for the mod at least for me. (trying 9.2 as we speak)

[Dunbaratu]

It's not unrealistic, the lunar descent script on the Apollo was written in a cryptic language similar to assembly

https://code.google.com/p/virtualagc/source/browse/trunk/FP8/FP8.s?r=258

http://www.ibiblio.org/apollo/Pultorak_files/FP8Listing.pdf

kOS is not machine code.

If you have a higher level language with longer identifier names, structured loops, whitespace indentation, and comments, then those things do not affect the size of the executable you actually install on the craft.

A four byte integer called "k" with no explanatory comment takes up no more space than a four byte integer called "thisIsMyVariableName" with a comment written next to it. All the syntactic sugar of whitespace, comments, and long variable names do not take up space in the actual executable. Ironically for your argument, long variable names only started making a difference in compiled code size in *modern* languages like Java and C# where more symbol table information stays in the final compiled file for the purpose of late-binding.

Even in assembler comments still don't take up code space after compilation.

Edited May 12, 2014 by Steven Mading

[airbus a320]

yea, i know it's not low level programming, but we need some kind of limit ... maybe a limit on vars number or maximum program lines but this should be a low priority thing on developing!

[Vulkan]

yea, i know it's not low level programming, but we need some kind of limit ... maybe a limit on vars number or maximum program lines but this should be a low priority thing on developing!

Now that would be a very realistic and difficult tech tree. You have to land on the Mun with the proverbial "less computer power than a mobile phone" in order to make enough science for more computer. No hovering skycranes until you've unlocked the last tier.

[erendrake]

Whats up with the editor not working? Seems like a killer for the mod at least for me. (trying 9.2 as we speak)

When we rewrote the parser, the editor was removed to help get an update out sooner (still took awhile). Once 12.1 is out for real we have a list of stuff to bring back.

I personally would rather use the excellent Saturn IDE

[Dunbaratu]

yea, i know it's not low level programming, but we need some kind of limit ... maybe a limit on vars number or maximum program lines but this should be a low priority thing on developing!

At no point did I advocate for there being no limits.

I advocated for changing the quantity being measured to use a realistic metric instead. Good indenting and understandable long variable names and having comments are all things that exist only in the source code. They wouldn't make one bit of difference in how big the compiled code is that you'd be loading onto your limited space drive going with the craft. If you have 10k (ish) to work with, you're not going to be wasting that on sending source code. Your source code is going to stay home on the much bigger archive, and on the craft you're only going to send the result of compiling it.

The cost should be based on how complex the code *actually* is, not on how much ascii text you used to pretty it up in source code. A token count is a quick estimate that gets much closer to that. (if you mention a variable name it counts as 1 variable. no matter how many characters you used to name the variable. Heck with the kRisc underpinnings it could be possible to *actually* count the compiled code.

Hmm. Now that I think of it, with the kRISC underpinnings, it may be possible to *actually* implement a compiler for real - as in save the result of the parse/compile in a separate file on the Archive (perhaps with a ".kex" extension) and then make the terminal allow you to run precompiled program files… hm… that may be actually doable as a future feature.

Edited May 12, 2014 by Steven Mading

[marianoapp]

if you prefer you can edit kos config file, there is something like "start from archive" but remember that you can access to the archive only if you are in communication range!

All the config options can be modified from the kOS console itself, just use "set config:[option] to [true|false]". Use "list config" to view all the available config options and their current value.

At no point did I advocate for there being no limits.

Hmm. Now that I think of it, with the kRISC underpinnings, it may be possible to *actually* implement a compiler for real - as in save the result of the parse/compile in a separate file on the Archive (perhaps with a ".kex" extension) and then make the terminal allow you to run precompiled program files… hm… that may be actually doable as a future feature.

Actually that's what the compiled code cache does (without the saving to a file part), so it wouldn't be difficult at all to implement this.

[Waz]

How do I "autorun" something? Or do I have to COPY then RUN from the console at every launch? I'm not trying to automate everything, just a few minor things, for which having to manually load and run stuff every launch would take longer than just doing the minor operations manually.

[airbus a320]

Autorun is not implemented yet, devs said it's a planned feature.

If you have to download and run many script you can write another script that copies all "dependencies" and runs them.

[baloan]

Any idea why I can't use Kerbin as a target:

set target to "Kerbin".

does not work. My ship is in Mun orbit.

But I also can't set it as a target from the map view. KSP restriction?

Land safely, baloan

Edited May 14, 2014 by baloan

[Dunbaratu]

Any idea why I can't use Kerbin as a target:

set target to "Kerbin".

does not work. My ship is in Mun orbit.

But I also can't set it as a target from the map view. KSP restriction?

I think it's a KSP restriction. It doesn't let you target a body that is your SOI body or your SOI body's parent or grandparent.

[Dunbaratu]

Actually that's what the compiled code cache does (without the saving to a file part), so it wouldn't be difficult at all to implement this.

That would be so cool. Actually, what I'd really like to see is that if that's done, then the disk file should store the op codes in a human readable assembly-like ascii format (but one that's simple enough to be quick to parse back in), rather than as a binary dump. Not only is this just nice to let people see what's under the hood of their programs, but it also opens up the chance for other languages. Someone could make a different high-level language that isn't kosscript and parse the result into kRISC assembly opcodes for kos to run.

[baloan]

but it also opens up the chance for other languages.

Does it make sense to separate the language from the variables and command interface like kRPC is doing?

Many advantages pop up in my mind:

1. ability to use my favourite development environment and language.

2. access to all variables and actions through a generic protocol. Fix one bug in the interface and it fixes it for all available languages. Decouples language and access layer.

3. Immediate availability of stable programming languages. Avoids Steven and Chris reinventing the wheel. Don't get me wrong: I like your contribution to kOS, your effort and enthusiasm! Great job done. But with a home-grown language and parser there are just a lot of language related bugs to fix - I'd like you rather spend your time to implement cool things like thruster control and docking.

Maybe (just thinking loud) it is an option to extract the kOS language and interface it with kRPC - and make kRPC support thruster control and docking become available in Python and kOS (sounds more like a dream).

Keep on the great work. I'll be back with a new entry to the kOS automation challenge soon!

[Dunbaratu]

Does it make sense to separate the language from the variables and command interface like kRPC is doing?

Many advantages pop up in my mind:

1. ability to use my favourite development environment and language.

2. access to all variables and actions through a generic protocol. Fix one bug in the interface and it fixes it for all available languages. Decouples language and access layer.

3. Immediate availability of stable programming languages. Avoids Steven and Chris reinventing the wheel. Don't get me wrong: I like your contribution to kOS, your effort and enthusiasm! Great job done. But with a home-grown language and parser there are just a lot of language related bugs to fix - I'd like you rather spend your time to implement cool things like thruster control and docking.

Maybe (just thinking loud) it is an option to extract the kOS language and interface it with kRPC - and make kRPC support thruster control and docking become available in Python and kOS (sounds more like a dream).

Keep on the great work. I'll be back with a new entry to the kOS automation challenge soon!

The kRISC system isn't *entirely* open-ended and generic (yet?). There's things basic computers can do that it can't (like peek under the top of the stack to look at local variables stored there), which would make cross-compiling from other languages currently a bit hard to do. It's hypothetical pie-in-the-sky thinking on my part to have mentioned that. It's a nice longterm future idea - not anything to expect any time soon. But a more short-term idea would be that if the compiled code could be looked at as assembly opcodes it would help debugging greatly, and *hypothetically* one could actually write directly in kRISC assembly - not that I'd recommend it.

[gsmurf]

I seem to be having a problem targeting planetary bodies.

The command set target to body("mun"). returns the following error: VESSEL 'BODY("Mun")' not found.

Has the syntax for targeting bodies been changed recently?

I am using the 12.1 prerelease.

Thanks.

[erendrake]

The kRISC system isn't *entirely* open-ended and generic (yet?). There's things basic computers can do that it can't (like peek under the top of the stack to look at local variables stored there), which would make cross-compiling from other languages currently a bit hard to do. It's hypothetical pie-in-the-sky thinking on my part to have mentioned that. It's a nice longterm future idea - not anything to expect any time soon. But a more short-term idea would be that if the compiled code could be looked at as assembly opcodes it would help debugging greatly, and *hypothetically* one could actually write directly in kRISC assembly - not that I'd recommend it.

He is talking about kRPC, another project that is pretty neat.

Honestly the concept of kRPC is pretty compelling and before our parser rewrite i had considered doing something like that and we still might. I have been focused on enabling more mission types and integrating with other addons. Im pretty sure we will come back around to something like this. This would be a very long ball.

[marianoapp]

@Steven: There are no stack manipulation instructions because the compiled code is a stack based CIL and not assembler, and therefore there's no need for them (the .NET CIL don't have stack manipulation instructions either).

@baloan: Most of the language bugs are because we rewrote most of the kOS code and it was bound to have this kind of problems in the first release. In fact the change was so big that we considered changing the name of the project to something else but finally agree to leave it the same.

The main difference between kOS and kRPC is that ours is a virtual machine that exists entirely inside KSP, and as such is more tightly integrated with the game and subject to its rules (e.g. if you revert to launch in kOS the execution is stopped and the variables erased, but I don't know how kRPC handles this kind of thing).

Anyway it could be possible to integrate kOS and kRPC so our virtual machine sends instructions to it instead of interfacing with KSP itself, but it would be necessary to evaluate the pros and cons of doing that.

After the rewrite kOS became pretty language agnostic so it shouldn't be difficult to write a compiler for another language if we ever choose to do it (I think it took me about two weeks to write the current one).

[Dunbaratu]

@Steven: There are no stack manipulation instructions because the compiled code is a stack based CIL and not assembler, and therefore there's no need for them (the .NET CIL don't have stack manipulation instructions either).

There aren't locals of any other type either in kRISC. The .locals section of CIL has no analogy in kRSIC (yet?). And they still are in *a* stack, otherwise recursion wouldn't work right. (And technically peeking under the top of the stack is not stack manipulation as you're reading. not altering, the stack.).

[airbus a320]

IMHO, the best is to choose an easy language like lua or python ... the final user may not be nerd enought to figure out what is a source code or a compiled byte-code or a machine code ("wtf, i can't run my script! this game is crap!!" - "you have to compile it in order to launch it!" - "have i to what? i wanna play! gimme my game!!")

... an interpreted script is much easier, i had tons of fun in Minecraft with Computercraft mod programming turtles! ... but with an interpreted language we will encounter again the "realism issue", it's a trade-off:

- interpreted language: or an unrealistic space limit (crappy code without a single line of comment) or a limit on the max vars and lines of actual code

- compiled code: a realistic space limit on compiled code

unless with the upcoming new GUI it would be possible to implement a something-like-an-SDK directly into kerbal interface... if it's possible to write, debug and compile in the vab it will be awesome!

Edited May 15, 2014 by airbus a320

[marianoapp]

@Steven: Ah ok, now I understand what you mean. We could of course keep adding stuff to make our CIL more expressive/flexible as need arise.

@airbus: kOS actually compiles the code under hood, from the user perspective there's no difference with an interpreted language.

[CaptainKipard]

I seem to be having a problem targeting planetary bodies.

The command set target to body("mun"). returns the following error: VESSEL 'BODY("Mun")' not found.

Has the syntax for targeting bodies been changed recently?

I am using the 12.1 prerelease.

Thanks.

I think you need to delineate with a colon.

body:mun

I'm not sure though I've never done this before.

[airbus a320]

@Steven: Ah ok, now I understand what you mean. We could of course keep adding stuff to make our CIL more expressive/flexible as need arise.

@airbus: kOS actually compiles the code under hood, from the user perspective there's no difference with an interpreted language.

got it...

i was thinking in the end user point of view... a couple of days ago we were talking with, if i recall right, steven about the realism of the size limit. Kerbal is set in a fictional apollo era. The programs were at architecture level, the limits were on overall number of istructions/vars and vars lenght so a var named "x" and a var named "ILoveWhenGoofySpanksMyArse" are totally the same in size.

Changing the subject: if i have two processor (sry, i don't remember the actual part name) on my vessel running two different programs, there is a way to pass a variable between them? vars defined in one is not accessible in the second, is it possible to use a file like a socket? in the wiki on git there is no mention on reading files...