[1.3] kOS Scriptable Autopilot System v1.1.3.0

[marianoapp]

I already added an issue to the tracker basically asking what the correct behavior should be. On one hand locks are like variables and variables don't have scope, but on the other hand locks also behave like functions and I'm not sure I like having functions without scope. We'll have to talk it over to find a solution we see fit.

[Xty]

@Xty: The problem is that locks declared in a parent program are not available in a child program. There's an explanation for why adding the "unlock throttle" line in the child program causes the throttle to unlock but that is more suited to the development thread, so I won't enter into details here.

Try changing the "unlock throttle" for "set throttle to 0" which has the same effect and shouldn't have this problem.

Ah I see, thank you, it works now. It was actually the opposite of what you said, UNLOCK THROTTLE works, but LOCK THROTTLE causes the bug.

Tangent question, why does LOCK THROTTLE TO 0 unlock the throttle? What if I actually want to lock the throttle off?

[marianoapp]

The throttle is a special case which requires to be updated in every update (every frame, by design of KSP) so when you lock the throttle to anything the program also adds a trigger that evaluates the lock on every update and sends that value to KSP.

Due to the way the program gets compiled the trigger is added if a throttle lock exists anywhere in the program, even if it never gets executed, and since the throttle hasn't been locked to anything yet the trigger returns the default value of the throttle variable (which is zero).

[TranquilTempest]

In case anyone's curious about the ascent autopilot I'm working on: http://pastebin.com/439Bm7yi

I wouldn't call it done, but I've wasted enough time on it tonight, and I think it's good enough to share.

Intended use: remotetech probes/relays in .24. I need to work on reducing the size of the script and the amount of time it takes to circularize. I'll probably end up consolidating the three sections into one loop, so I can get rid of the duplicated staging code and steering error/SAS code

I considered starting a competition to develop the most reliable and efficient ascent script, but decided the fun way to do that would be too much work to organize and score. The idea was to have each competitor submit an autopilot script and a .craft. Each submitted script would be run on each submitted craft, and ranked by average altitude, remaining fuel, and eccentricity. So you design a ship as difficult to pilot as possible, playing to the strengths of your particular autopilot script, and exploiting weaknesses you think everyone else's autopilot scripts would have.

[Dunbaratu]

I already added an issue to the tracker basically asking what the correct behavior should be. On one hand locks are like variables and variables don't have scope, but on the other hand locks also behave like functions and I'm not sure I like having functions without scope. We'll have to talk it over to find a solution we see fit.

As long as there's only one way to do it, I'd rather that the one way be global. Scoping makes sense only when there's ways to choose the scope (i.e. local when you want, global when you want). If scoping was forced to be local only, then it would create the opposite problem, where you can't delegate your steering operations to a subprogram and all steering would have to be in the top level program.

[CaptainKipard]

Are there any plans for user console input?

[erendrake]

Are there any plans for user console input?

No current plans but it isnt a bad idea. It would enable menus and all kinds of fun stuff

[Dunbaratu]

No current plans but it isnt a bad idea. It would enable menus and all kinds of fun stuff

There's a toolbar mod toolbar mod that's a sort of mod for mods. It doesn't do anything by itself but it presents a system for other modders to use to create popup windows with icons and guis, and it's commonly used by many different mods. Perhaps a bridge between kosscript and that might be handy, so someone can call kosscript functions that make things happen in the toolbar mod. I'm of a mixed mind about it though because it does sort of break the "make it feel like an old computer" feeling of kOS to have your flight computer be able to open dialog boxes and let you click buttons with a mouse.

[Sma]

There's a toolbar mod toolbar mod that's a sort of mod for mods. It doesn't do anything by itself but it presents a system for other modders to use to create popup windows with icons and guis, and it's commonly used by many different mods. Perhaps a bridge between kosscript and that might be handy, so someone can call kosscript functions that make things happen in the toolbar mod. I'm of a mixed mind about it though because it does sort of break the "make it feel like an old computer" feeling of kOS to have your flight computer be able to open dialog boxes and let you click buttons with a mouse.

Maybe it could be tied together with that Altair Alcor module (don't have the link to the thread handy). So if you are using the Altair Alcor module you could have the popup menus, but if not you just get regular kOS. Or maybe thats too much? lol

Edited April 18, 2014 by Sma

[CaptainKipard]

I think erendrake was talking about text-based menus inside the console window that people can script themselves where you type "1" for menu item number 1 and so on.

@erendrake could you make the window hide like all other UI elements when you press F2?

edit

could you somehow get altitude from this mod? Would be great for landing and hovering scripts.

Diazo says the method is exposed, so you can call it directly if the plugin is present.

Edited April 18, 2014 by Cpt. Kipard

[Hans Dorn]

No current plans but it isnt a bad idea. It would enable menus and all kinds of fun stuff

For the moment, you could put aside a couple of action groups to interact with your script.

[erendrake]

For the moment, you could put aside a couple of action groups to interact with your script.

Reserving action groups for use with KOS would be a support nightmare. You can already read the state of action groups to see when they have been pressed.

[Hans Dorn]

Lol I was suggesting this for the user side, not as a change to KOs.

Cheers

[Dunbaratu]

I think erendrake was talking about text-based menus inside the console window that people can script themselves where you type "1" for menu item number 1 and so on.

@erendrake could you make the window hide like all other UI elements when you press F2?

edit

could you somehow get altitude from this mod? Would be great for landing and hovering scripts.

Diazo says the method is exposed, so you can call it directly if the plugin is present.

I would prefer the more raw information needed to calculate it: "What are the bounding box dimensions of my vessel and where is my current COM within that?" Because there's other places besides landing where you need that - like docking. The core problem is not the inability to read altitude from the bottom of the craft, but the inability to even know where the bottom of the craft is in the first place. Solve that more raw problem and you effectively solve more than one problem at the same time.

Imagine being able to access this information:

"Your current craft's dimensions are bounded by this box: FORE: [-22 to +5], STARBOARD: [-8 to +8], TOP: [-5 to +5]."

Then you can use the "-22" of the FORE dimension to get the distance from your COM to the bottom of the craft, and your true altitude would then be reported altitude minus 22. But you'd also have all the rest of that information at your disposal too.

And of course you could re-query it after doing a stage (which of course changes the numbers as parts of your craft fall off).

Edited April 18, 2014 by Steven Mading

[Dunbaratu]

I think erendrake was talking about text-based menus inside the console window that people can script themselves where you type "1" for menu item number 1 and so on.

Oh I know, but I was pointing out a possible alternative. Either approach would still mean people script it themselves. I was picturing having script commands for "open a window that looks like this" and "put a button here with this word on it", and "WHEN clicked(mybutton1) THEN { do stuff }."

I'm not entirely sure it's a good idea. I'm waffling on it. The con is that it doesn't *feel* right to have guis for an old clunky 10,000 byte computer. The pro is that if you look at the thread for the toolbar mod, you see that the rest of the modding community uses it extensively so it would make kOS scripts look more similar to other mod's interfaces.

As for what's easier to implement, it's probably easier to implement a simple text keyboard catcher like:

IF keypress:queued > 0 { print "you pressed " + keypress:getnext:name. }.

with "keypress" being a special identifier that has these properties:

keypress:queued, Integer, is the number of queued key presses that haven't been consumed yet.

keypress:peeknext, keyType, is the bottom of the queue of keypresses. It is the oldest keypress not yet processed.

keypress:getnext, keyType, is exactly the same as peeknext, except that it consumes the keypress from the queue as well.

keypress:peeknew, keyType, allows the script writer to "cheat" and break the queue model, instead peeking at the most recent keypress without processing the older ones under it. *for the purpose of processing important aborting keys.* There is no getnew. You're allowed to peek at the newest key to see whether or not to abort something but still have to consume the keys from the oldest-first, like a real queue.

keypress:consume, INTEGER, causes the queue to consume N items from the queue when SET to any positive N. Note that setting N to be equal to keypress:queued clears all the queue.

keypress:trapping, BOOLEAN, is set to true by the script when it's time to begin trapping keys, false, when it's time to release control of them. kOS should automatically invoke "set keypress:trapping to False." on program exit or abort.

keyType, is the type that contains a single key, which in turn contains these parts:

keypress:next:name, String, is the text name of the key, one char for letters like "K" but also can store things like "[Home]" or [F7]"

keypress:next:type, Integer, is a code for the kind of key: 0 = printable ascii char, 1 = special like home, F7, arrow, etc

That's just an idea. What do people think of this?

As a totally separate interface, for just line-at-a-time input where the program is blocked doing nothing until you press return to make something happen rather than key-at-a-time input, a much simpler method like this could be used:

print -n "What is your Name? " at (0,0).

readline myName. // script is stopped until ENTER is pressed.

The "-n" idea is borrowed from lots of unix scripting languages. It means "don't start a new line afterward". It leaves the cursor where it was at the end of the print statement instead of going to the next line. I don't quite know what a good equivalent kosscript syntax might be for the same idea, if it was to be implemented.

What do people think of that as another way to do input?

[CaptainKipard]

Honestly all I imagined was something like cin and some basic data type converters if they're necessary.

[Hans Dorn]

I like the idea of using an old computer as a guideline. These didn't have GUI's, but displays and buttons. LOTs of buttons

Having a simple fixed GUI with some LED displays, numerical and function keys (with user defined labels) would be apropriate I guess.

[Sma]

I like the idea of using an old computer as a guideline. These didn't have GUI's, but displays and buttons. LOTs of buttons

http://www.oldcalculatormuseum.com/tisr-60.jpg

Having a simple fixed GUI with some LED displays, numerical and function keys (with user defined labels) would be apropriate I guess.

Heres the link to a WIP (Alcor Module) I mentioned in a previous reply, look at all the buttons in the IVA mode lol. Maybe it's a little much though for what we're talking about here.

Kevin did originally say he was planning on adding some buttons in the bezel area below the screen. Hmmm...*thinking cap on...power light blinking saying to charge the battery*....

[Dunbaratu]

Honestly all I imagined was something like cin and some basic data type converters if they're necessary.

That's easy on the surface to use but harder under the hood to implement.

Although, on an unrelated note, for any sort of input, converters will be necessary to be able to turn "123" into a numerical variable. Right now you can only go the other way around from number to string (by concatenating numbers to strings with "+") but you can't go from string to number, which is vital for being able to take user input and do stuff with it.

Edited April 19, 2014 by Steven Mading

[OxalysResourceConsortium]

Was just about to post this in the wrong thread, someone should lock that thread and put up a link at the top directing everyone to this one.

So two questions, first one should be easy, second one takes a little explaining.

Question 1: If I run remotetech and am in program mode, as soon as that program starts running, does it need contact with KSC to continue running?

Question 2(What I was originally going to post in the 0.9 thread):

Hey, so I was writing a program for Launch and Ascent Guidance of the stock Kerbal X (with the exception of one kOS module in between the command module and the parachute and a communitron on the side of the command module and the staging setup so the launch clamps release with the first "STAGE." command. craft file here) on my practice save (a separate copy of KSP 0.23.0 I run with no other mods installed so I can use it for debugging purposes) using kOS v0.11.0.

I want to be able to get a comm network ready so I can have a probe ready for my Moho launch window in 5 Kerbal days so I'm using this to learn how to code in kOS. But every time I ran my code the launch clamps would release but the throttle wouldn't respond, so the Kerbal X craft would just end up crashing down on the launch pad.

The following is the code I used:

CLEARSCREEN.

//Begin Countdown


SET X TO 10.
UNTIL X = 0
{
 PRINT "Launch in T -" + X.
 WAIT 1.
 SET X TO X-1.
 CLEARSCREEN.
 }
PRINT "LAUNCH!".




//Ascent


LOCK STEERING TO UP.
LOCK THROTTLE TO 1.
STAGE.

I was able to hunt down the problem in my code down to the "LOCK THROTTLE TO 1." command by commenting out everything else like so and running the program again:

//CLEARSCREEN.

//Begin Countdown


//SET X TO 10.
//UNTIL X = 0
//{
// PRINT "Launch in T -" + X.
// WAIT 1.
// SET X TO X-1.
// CLEARSCREEN.
// }
//PRINT "LAUNCH!".




//Ascent


//LOCK STEERING TO UP.
LOCK THROTTLE TO 1.
//STAGE.

When I ran that, the throttle did not respond (i.e. it stayed at 0%). So I figured I must have been typing the command wrong so I issued the same command in immediate mode

LOCK THROTTLE TO 1.

Surprisingly, the throttle immediately responded and went to 100%. So I tried the opposite.

LOCK THROTTLE TO 0.

And once again the throttle responded by going back down to 0%

At this point I thought there might have been something wrong with my original program, so that the rest of the code, even though it was commented out, was causing the parser some kind of trouble. So I wrote a program called 'THROTTLEUP' to test this hypothesis.

LOCK THROTTLE TO 1.

Guess what? The throttle didn't respond at all. Soo... here's my KSP log, if it helps at all. I don't know what's wrong, so any help would be appreciated:confused:.

[Logris]

the throttle wouldn't respond, so the Kerbal X craft would just end up crashing down on the launch pad.

What's happening is that all the locks are cleared when the program finishes running, so what's happening is you lock the throttle to 1, stage, and then immediately reset the throttle to 0.

The trick is to stop the program from ending by putting in a loop. It doesn't need to do anything necessarily, but normally you would put the bulk of your logic in there.

A simple

UNTIL 1=0 {
...
}

should do the trick.

[OxalysResourceConsortium]

What's happening is that all the locks are cleared when the program finishes running, so what's happening is you lock the throttle to 1, stage, and then immediately reset the throttle to 0.

The trick is to stop the program from ending by putting in a loop. It doesn't need to do anything necessarily, but normally you would put the bulk of your logic in there.

A simple

UNTIL 1=0 {
...
}

should do the trick.

Thanks, I probably won't need to keep that loop in there since I was just writing the code one piece at a time and testing it as I went. In the final version it should work without the loop then?

[Dunbaratu]

Thanks, I probably won't need to keep that loop in there since I was just writing the code one piece at a time and testing it as I went. In the final version it should work without the loop then?

Just do anything that keeps it from ending the program. It doesn't matter what. For example you could do this:

SET done to False.
ON AG1 SET done to True.
wait until done.

To cause it to wait forever until action group 1 (alt-1) is pressed. You can use anything from AG0 to AG9 for the action groups.

(Note: for action groups to work, you have to have the terminal window NOT being focused, otherwise the ALT-number keypress doesn't pass through to the piloting code in KSP and instead KOS has it trapped.)

[CaptainKipard]

SET done to False.
ON AG1 SET done to True.
wait until done.

Why is it that even if "done" is false then that script wont continue? Logically then "wait until false" should work the same way that "wait until true" would, wouldn't it?

[Dunbaratu]

SET done to False.
ON AG1 SET done to True.
wait until done.

Why is it that even if "done" is false then that script wont continue? Logically then "wait until false" should work the same way that "wait until true" would, wouldn't it?

I'm confused. Are you reporting a bug, or are you describing how you're saying you would expect it to work? (Because if "wait until false" and wait until true" are giving the same result, that's definitely a bug. They shouldn't be the same.)