kOS Scriptable Autopilot System 0.9

[Ralathon]

Does anyone know how many decimals are stored in kOS variables? I'm currently building a UI that allows the user to input large numbers by adjusting them 1 power of ten at a time. That's a lot more accurate and faster than steps of 10km or whatever. I have the basic script running for integers but as soon as I try to make numbers larger than 10 billion it switches to scientific representation (X.YZ E+(7+N)). Does kOS still store the digits past that point, or do I need to kludge together a way to make double integers? If I want a craft in a synchronous orbit those digits become rather important.

Here's the script so far. Note that it is horribly inefficient (4 AG's and infinite variables... I know how to bring it down but it's a proof of concept).

clearscreen.

set X to 0.
set T to 0.
set I to 0.
set D to 0.
set P to 0.
set Flag to 0.
on AG10 set Flag to 1.

print "Current value = " + X.

until Flag = 1 {

set T to (T*10) + X.
set X to 0.
on AG7 set P to 1.
wait 0.05.
set P to 0.


until P = 1{

on AG8 set D to 1.
if D = 1{
set X to X - 1.
clearscreen.
print "Current value = " + ((T*10) + X).
wait 0.05.
set D to 0.
}.

on AG9 set I to 1.
if I = 1{
set X to X + 1.
clearscreen.
print "Current value = " + ((T*10) + X).
wait 0.05.
set I to 0.
}.


}.
}.

clearscreen.
print "Your final value was: "+T.
print "Good choice!".

[Desrtfox]

I agree. I don't have time to actually build the regex at the moment, but the logic is pretty simple: Period followed by not a number, switch to semicolon. Period followed by EOL replaced with a semicolon. I think that'd do it.

So, I did find the time. Here's the find and replace expression for use with Textpad (my script editor of choice):

Find: \.\([^0-9]\)\|\.\($\)

Replace: ;\1

Other editors should have similar syntax.

[KevinLaity]

Even after so much scripts written (most of them for tests purposes), I'm still not used to the fullstop for a command. And from my POV, a period marks the end. Peroiod. While I think a semi colon marks the end of an action, but leaves place for more.

Well, in English a semicolon doesn't come with the option of another sentence, it comes with that as a requirement. And the second sentence MUST be related to the first.

[KevinLaity]

While you're fixing bugs, the "unlock all." command does not appear to be working for me, it unlocks neither steering nor throttle.

Okay, a fix for this is done and will be rolled out in the next release.

[razark]

If I run a program from inside another program, the steering and throttle commands don't seem to respond.

For example:

//Program1
...
IF [i]condition[/i] { RUN [i]program2[/i]. }.
...
//End Program1


//Program2
...
PRINT "Prograde".
LOCK STEERING TO PROGRADE.
LOCK THROTTLE TO 1.
PRINT "Burning.".
...
//End Program2

When condition is met, program2 runs. It will print "Prograde", but the ship never turns. Likewise, the "Burning" message is printed, but the throttle never activates. SAS is off. I'm trying to set up a menu system, and I'd rather not stick all my code into one program. Any ideas?

[MDBenson]

Well, in English a semicolon doesn't come with the option of another sentence, it comes with that as a requirement. And the second sentence MUST be related to the first.

Without wishing to sound trite, this isn't English, it's a scripting/programming language, we aren't writing Shakespeare or Keats here . It doesn't conform to English grammar rules.

Most of your other structures comply to common C-like programming structures. It makes sense from my POV (as a coder who's worked on C-like languages for 10 years) to stick to common conventions to allow easy adoption of your coding standard. As others have pointed out it's not too hard to substitute using regular expressions. It'd be better to change conventions at this early stage and offer some sort of simple upgrade routine (UPGRADE prog1 TO prog1new command, for example) than find you want to do it later and can't due to inertia (i.e. breaking people's code).

While you are at it, you should also consider dropping the need for a line ending after closing '}' braces. Most languages assume '}' as a line ending anyway. Also, being able to roll up the code window to a 1-line display would be handy too.

Are you planning to implement user-defined functions, maybe then additionally importing one file to the other to allow modular coding? That'd be amazing, as people would be able to extend your basic language by building custom libraries

This one is probably unrealistic, but what are the practicalities of adding external interfaces to it by, say, telnet or serial? It#s something I'd like to see as a long term goal, it's not something it needs right now but it would be cool

I absolutely love the idea of what you are doing, it's awesome and at a much more accessible and intelligible level than things like ProgCom (I never really got my head a round assembler) and I'm going to have a good old go at using it in my week off later in the month, but I think if you want to implement what is rapidly becoming a comprehensive, feature-rich and complex scripting language, it's worth taking a step back and looking at common scripting language conventions to make your codeing system more accessible to people like muggins here who's brain works in C and PHP

Keep up the good work!

Edited September 5, 2013 by MDBenson

[TMS]

On the issue of structures and conventions, I don't think it really matters what form it takes... does it?

As someone who only dabbles with PHP and C, I feel I can adapt to these requirements quite easily. Also, I quite like the concept of a language that is fairly unique to this game for a number of reasons: one, keeping it verbose makes accessibility easier for non-programmers; two, trying to conform to existing standards will only please people with more detailed familiarity with those standards (can't please everyone); three, a unique language fits with the kerbal trope of aliens - not bogged down with prior experience - creating it to meet their needs; and four... I like the idea of a language reflecting the author - I think it's kinda neat to see it take shape.

I do, however, feel that the terminators should not be made changeable. My hope is that this scripting language will give enough options to make scripts that can be applied universally to any ship and that libraries of scripts become a possibility. As such, editing out peoples obscure choice of terminators seems like an obstacle.

Just a quick feature request? Would like to see node burn time implemented (BURNTIME:NODE).

[CaptainKipard]

Just a quick feature request? Would like to see node burn time implemented (BURNTIME:NODE).

Noooooo! Bad idea. Node burn times seem really buggy in KSP, not to mention that you can (probably) do a lot better by writing your own timing script. I'm actually doing one for Space Computer.

[KevinLaity]

Without wishing to sound trite, this isn't English, it's a scripting/programming language, we aren't writing Shakespeare or Keats here . It doesn't conform to English grammar rules.

Maybe not, but the post I was responding to WAS about English and whether the English meaning of a semicolon fits into a programming language.

Most of your other structures comply to common C-like programming structures. It makes sense from my POV (as a coder who's worked on C-like languages for 10 years) to stick to common conventions to allow easy adoption of your coding standard. As others have pointed out it's not too hard to substitute using regular expressions. It'd be better to change conventions at this early stage and offer some sort of simple upgrade routine (UPGRADE prog1 TO prog1new command, for example) than find you want to do it later and can't due to inertia (i.e. breaking people's code).

They comply to C-like structures when I have absolutely no choice. If you read my blog, you know that implementing braces was a last resort for me.

As a programmer who works regularly with 5 different languages and has worked in the past with at least 10 others, I feel that it only helps you grow as a programmer to be confronted with new syntaxes and push yourself out of your comfort zone. If nothing else, it encourages you to do more thinking and less knee-jerk reacting.

If I were to switch the terminator to be more C-like, well there would always be "just one more" C-like thing people would want it switched to as well. Eventually my mod would be pointless, because KSP already has a 100% C-like way to program it: writing your own mod.

Part of the fun of developing kOS is being able to throw out convention and try new unexpected things.

What I absolutely do not want is to create rage wars of people trying to share code and yelling at each other for not using the "one true terminator." And frankly, from my point of view, we've already passed the point where I would even consider doing a hard-change to semicolon for everyone.

While you are at it, you should also consider dropping the need for a line ending after closing '}' braces. Most languages assume '}' as a line ending anyway. Also, being able to roll up the code window to a 1-line display would be handy too.

This one I definitely agree with. It's just one of those things I haven't gotten to. What I'm going to do is have optional periods after braces to avoid breaking old code. While I love bucking convention, there's no upside to }.}.}.

Are you planning to implement user-defined functions, maybe then additionally importing one file to the other to allow modular coding? That'd be amazing, as people would be able to extend your basic language by building custom libraries

I definitely want to give mod developers a way to join in, in ways that each mod doesn't require the other, but that they can optionally work together. I've been in some talks with the creator of infernal robotics about this. I did notice in one of my DLL fishing expeditions something about messaging for parts. This might hold the key.

What I'd like is for mod developers to be able to register their own bindings and maybe even commands with kOS. And/or let kOS send strings to a part that have commands in them. Like TELL kethaneDrill TO "Deploy Drill".

This one is probably unrealistic, but what are the practicalities of adding external interfaces to it by, say, telnet or serial? It#s something I'd like to see as a long term goal, it's not something it needs right now but it would be cool

I did bring this idea up before, I think it's a cool idea and the kOS terminal already functions in a way that (I think) should be pretty compatible with telnet. But I don't have the time to work on this at the moment.

I absolutely love the idea of what you are doing, it's awesome and at a much more accessible and intelligible level than things like ProgCom (I never really got my head a round assembler) and I'm going to have a good old go at using it in my week off later in the month, but I think if you want to implement what is rapidly becoming a comprehensive, feature-rich and complex scripting language, it's worth taking a step back and looking at common scripting language conventions to make your codeing system more accessible to people like muggins here who's brain works in C and PHP

Keep up the good work!

Thank you, and I hope you and others find the unique quirks of KerboScript more endearing than annoying!

[dahud]

I'm not sure what I'm doing wrong, but I can't persuade kOS to control my heading. I've tried simple tests, like "LOCK STEERING TO PROGRADE." both in direct commands and executed scripts. The craft can be rotated manually, but kOS just won't do anything. Am I missing something silly?

[CaptainKipard]

Locking steering with direct commands will only nudge your ship slightly in the right direction.

I'm pretty sure you have to lock steering and keep that script from ending, so put it in a loop or tell the script to wait until whatever.

Also turn SAS off.

[dahud]

Hmm, that makes sense.

[KevinLaity]

Locking steering with direct commands will only nudge your ship slightly in the right direction.

I'm pretty sure you have to lock steering and keep that script from ending, so put it in a loop or tell the script to wait until whatever.

Also turn SAS off.

SAS is probably the most common thing because under the new system, you expect the craft to rotate at will when it's on.

I may implement a fix that automatically shuts off SAS whenever the steering is locked.

EDIT: And the script ending only applies of course if you're in a program, the original post seemed to indicate that he had also tried doing it as an immediate mode command.

[dahud]

the original post seemed to indicate that he had also tried doing it as an immediate mode command.

That is accurate. Also, SAS was off. My exact steps:

1. 
   
2. Be in space.
   
3. Right click on kOS part to activate and bring up the command prompt.
   
4. Type "LOCK STEERING TO PROGRADE."
   
5. Press Enter.
   

At the end of all this, nothing has happened.

Edited September 5, 2013 by dahud

[CaptainKipard]

I don't know if this has been mentioned already but I've found a conflict with Improved Maneuver Nodes. Pressing o while typing will open the node dialogue in map view, and briefly flash it in ship view.

[curiousepic]

What I would LOVE to see, after we have the ability to refer to specific parts, is the option to restrict what flight statistics a script can access by those parts, and/or from telemetry with other vessels or KSC. (And perhaps a supplementary mod that adds additional sensor parts).

I like how KSP is the only game where I say "I want to HAVE to do X"!

[KevinLaity]

That is accurate. Also, SAS was off. My exact steps:

1. 
   
2. Be in space.
   
3. Right click on kOS part to activate and bring up the command prompt.
   
4. Type "LOCK STEERING TO PROGRADE."
   
5. Press Enter.
   

At the end of all this, nothing has happened.

If you look at the bottom left, do you see the controls moving as though it's trying to turn?

Do you lose your flashing cursor at any point? That would indicate that an uncaught exception

[SiliconPyro]

If you look at the bottom left, do you see the controls moving as though it's trying to turn? Do you lose your flashing cursor at any point? That would indicate that an uncaught exception

I almost sprayed coffee on my monitor when I read that last . . . fragment.

[KevinLaity]

What I would LOVE to see, after we have the ability to refer to specific parts, is the option to restrict what flight statistics a script can access by those parts, and/or from telemetry with other vessels or KSC. (And perhaps a supplementary mod that adds additional sensor parts).

I like how KSP is the only game where I say "I want to HAVE to do X"!

Well, some of this will come true. I already have a plan to take the scientific instruments and expose their outputs and make sure that you can't get those values without those instruments on board.

On that note, you will soon need at least one antenna if you want to access your Archive drive from space and more if you're more than 150 km from the surface of Kerbin. It'll use the same rules as targetting, you get 75km for free, each additional antenna gives you another 75km, and then that number is multiplied by 10 for every comm dish.

It's so true about KSP. All of the fun of a sandbox game comes from finding your own solution to problems that are hard to solve.

[Kalista]

By antenna and dish you mean just the stock ones right? or will the mod be able to tell if a mod antenna is a real antenna and run off it as well.

[KevinLaity]

By antenna and dish you mean just the stock ones right? or will the mod be able to tell if a mod antenna is a real antenna and run off it as well.

Yes the stock ones. And if a mod has an antenna that people want to use I would have to add that in manually.

There doesn't appear to be an antenna partmodule that I can detect, so I have to go by the part names "commDish" and "longAntenna".

[dahud]

If you look at the bottom left, do you see the controls moving as though it's trying to turn? Do you lose your flashing cursor at any point? That would indicate that an uncaught exception

The rotation axis dials don't move, it's not even trying to turn. I don't remember whether the cursor was blinking or not at that particular time, but I do remember the console falling into a bad state a few times. For example, sometimes the console would stop displaying text in realtime, and would only display the command after I press Enter. Do unhandled exceptions bubble up to the ALT-F2 window? If not, do you dump them anywhere? EDIT: BBCode really doesn't like line breaks today. Edited September 5, 2013 by dahud

[KevinLaity]

sometimes the console would stop displaying text in realtime, and would only display the command after I press Enter.

That's definitely an exception when that happens. And it also happens if you try to type into a terminal that was opened from a ship that is now destroyed.

Do unhandled exceptions bubble up to the ALT-F2 window? If not, do you dump them anywhere? EDIT: BBCode really doesn't like line breaks today.

I don't really use alt-f2 much, but they do get dumped in an output file in your KSP folder. (I can't remember exactly where it is right now)

This is definitely worth exploring further. What happens if you try to lock the steering of a craft that's still on the pad?

[dahud]

This is definitely worth exploring further. What happens if you try to lock the steering of a craft that's still on the pad?

I haven't tried that. All my experimentation has been in orbit. Idea: is there any architectural reason you can't pipe unhandled exceptions onto the console? It makes sense in-universe, it is a computer after all. For bug tracking purposes: I'm using the latest Steam version of KSP, on Windows 8 64-bit. The only mod running alongside this was Kerbal Engineer Redux, dunno what version. Also, you know what would be really nice? Functions. Or at least the ability for programs to return values to the program that called it.

[jsalexan]

I definitely want to give mod developers a way to join in, in ways that each mod doesn't require the other, but that they can optionally work together. I've been in some talks with the creator of infernal robotics about this. I did notice in one of my DLL fishing expeditions something about messaging for parts. This might hold the key.

What I'd like is for mod developers to be able to register their own bindings and maybe even commands with kOS. And/or let kOS send strings to a part that have commands in them. Like TELL kethaneDrill TO "Deploy Drill".

Kevin, I've been looking into this pretty deep because I REALLY REALLY want it to work with infernal robotics.

TLDR; Version:

Create two things in your code:

KOS-Vars(key,value)

adds or updates the key value pair in your variables collection

alias the script processor "tell" command to unityengine.sendmessage(methodname,message,value)

You're done.

The rest is up to the other plugin authors to implement.

They'd need to implement the public method your code would call with 2 parameters per the sendmessage documentation.

They could set values via calling unityengine.sendmessage ("KOS-Vars",key,value)

Longer wordy version:

What could be done would be to send a message to the root node (these propagate downwards to all other elements on the vessel).

the message could consist of a string containing a group address, a command and a value.

You would simply implement two routines: a method to do the sendmessage broadcast to the entire vessel and a callback routines that would take variable name/value pairs and turn them into internal variables.

This command: Tell "IR-Interface" "Group1/MOVE" -5.

Calls: UnityEngine.SendMessage("IR-Interface", "Group1/Move", -5) behind the scenes

http://docs.unity3d.com/Documentation/ScriptReference/GameObject.SendMessage.html

Then it's up to the mod creator to implement an "IR-Interface" method that parses the command string and moves group "Group1" to current position -5.

If a plugin doesn't support your event, it's ignored.

Any mod developer that implemented an IR-Interface using the same format of commands would be controllable via this method.

The IR-Interface would do a sendmessage to "KOS-Vars" telling it "<IR>Group1Value" = 14

This method would be useable, expandable and would not require much coding on your part at all and by creative use of enumerator strings you could Tell "IR-Interface" "ListGroups" "IRGroups" and get a message back of "IRGroups" "Group1/Group2/Group3" on your KOS-Vars Interface

The downside of doing this is that there would be nothing stopping you from calling any public method on any part so you may want to lock out the built in part commands.

Tell "explode". ENTIRE ship blows up

Tell "Activated" 1". Everything on the ship activates

One good thing is that you wouldn't have to worry about getting addresses for specific parts, the downside is that unless the part plugins themselves kept a list of their own and provided that in the interface (Infernal Robotics does), you wouldn't have any way to direct commands to only specific parts.

This is actually the method I'm going to try to hack together this weekend on my own just to see if I can.

If you're interested in anything that comes out of it, I will PM you the code for rewriting to get the spaghetti out and include it in the core codebase. If I can get it to flash the lights on the ship on a timer in a loop via this method, it'll count as a working proof of concept and I'll then try to somehow bribe sirkut into implementing a command handler on his side (or take a stab at it myself for my own use) at that point.

It should be fairly trivial to make this work from the KOS side.

Jeff

Edited September 5, 2013 by jsalexan
Brain fart