[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Dr_Goddard]

I'm literally squealing like a little girl.

[erendrake]

AWESOME will love being able to use a terminal on one of my side monitors.

Now about that RT2 stuff... can I or can I not get signal delay??

you cannot get the signal delay right now but that should be pretty simple to add. Right now the extent of the RT integration is to allow you to kick off a script when you have control and that script can continue to work, without signal delay, on the craft with or without control.

[Drew Kerman]

you cannot get the signal delay right now but that should be pretty simple to add

Cool, that's really all that's missing. I mean, a more direct means of querying whether the ship is connected or not would be nice, but it's currently doable through the part module interface by querying the SPU module.

[Dr_Goddard]

I have a new idea for integration with IR.

One of the big problems with robotics traditionally is it is very difficult to imagine/convey the precise movements required to do anything. You add multiple legs or multiple arms to coordinate and you have a real conceptual difficulty.

In robotics they get around that by having a training mode.

You physically move the robot through the motions and they simply learn it and repeat it.

Now, I don't think we can do that... too many hurdles.

But if you think of stop-motion as an analogy for what we want...

What we can do is move a robotic to incremental positions, and record the incremental translations of the various servos, maybe through the log function.

I'm thinking a machine could be trained to follow my servo script and the results could be spectacular.

I delayed any effort to make my robot bug-walk because I hadn't thought of an elegant way till now.

I didn't want it clanking around stumbling over every obstacle, I want it to walk properly and turn, etc. negotiate obstacles and maybe even automatically load cargo or some other task.

O man, what am I getting into now?

[Dunbaratu]

Just a heads-up to people writing kOS scripts. I'm sure we can all understand that given some of what SQUAD wants to do with aerodynamics in the next release, that it will affect some calculations.

Here's one thing that affects people even if they're not making airplanes but are just making rockets.

http://forum.kerbalspaceprogram.com/threads/110229-Thrust-scaling-with-atmosphereic-pressure-instead-of-Fuel-Flow-rate-Yay!?p=1726681#post1726681

(nutshell: a throttle of 0.5 will no longer necessarily mean 50% of maxthrust anymore.)

[kcs123]

Just a heads-up to people writing kOS scripts. I'm sure we can all understand that given some of what SQUAD wants to do with aerodynamics in the next release, that it will affect some calculations.

Here's one thing that affects people even if they're not making airplanes but are just making rockets.

http://forum.kerbalspaceprogram.com/threads/110229-Thrust-scaling-with-atmosphereic-pressure-instead-of-Fuel-Flow-rate-Yay!?p=1726681#post1726681

(nutshell: a throttle of 0.5 will no longer necessarily mean 50% of maxthrust anymore.)

Well, long before those news kicked in, I got some thoughts for making sort of autopilot with kOS and FAR. Instead of setting throttle to 50% and using as constant for other variables, I thought it would be better to use acceleration as constant and change everything else that is allowed to change to keep same acceleration.

Acceleration should be function of thrust(force) and craft mass, if I recall this correctly from school . Problem is that both will be changing over time, thrust due to atmosphere pressure change and mass due to fuel loss over time. So, kOS script should watch current acceleration and adjust trotlle to keep same acceleration as addition to keep tracking other vectors - prograde, horizont, relative to target, etc.

Maybe it will be good to include such function in kOS, when you call it it will give you current acceleration of craft.

That will allow to make more simple script and leave room for more complicated tasks.

Edited February 11, 2015 by kcs123

[Parastie]

Question on vectors (again).

I have 2 spacecraft with ports somewhere in their middle section.

Lets say that I have the port from the ship I'm controlling perfectly inline with the port on the other shift.

I should be able to type,

lock myporttotargetport to (myport:facing*target:position).

And that should give me a vector from my port to the targetted port, right?

So, I should be able to

lock myporttotargetangleZangle to vang(myport:facing:vector,myporttotargetport).
lock myporttotargetangleXangle to vang(myport:facing:starvector, myporttotargetport).
lock myporttotargetangleYangle to vang(myport:facing:upvector, myporttotargetport).

To get the angles between the vector facing the target port, and 3 coordinate vectors and they all should be originating from my port.

The problem is, (and I know that Z,X, and Y lables are not likely to be correct) that if the ports are point directly at each other, then the myporttotargetangleYangle should be 90 degrees, and it's not for some reason.

Does any of that make sense? Basically I'm trying to use the angles to determine if the ship is lined up correctly, but I can't get the angles to line up to what I think they should be.

EDIT:

Here's a screen shot of what's going on the screen, and I've dumped my code into a pastbin. I'm just not sure exactly how to get the angles I'm expecting. The orange line should draw from my port to the target port, however it appears just slightly off for some reason, and this is also reflected in the angles I'm getting. Any help would be great! Thanks guys! (I should note that I'm using code that Steve Madding posted awhile back, which works great!!)

http://pastebin.com/T8LJjKrh

Edited February 11, 2015 by Parastie

[Ziw]

I have a new idea for integration with IR.

One of the big problems with robotics traditionally is it is very difficult to imagine/convey the precise movements required to do anything. You add multiple legs or multiple arms to coordinate and you have a real conceptual difficulty.

In robotics they get around that by having a training mode.

You physically move the robot through the motions and they simply learn it and repeat it.

Now, I don't think we can do that... too many hurdles.

But if you think of stop-motion as an analogy for what we want...

What we can do is move a robotic to incremental positions, and record the incremental translations of the various servos, maybe through the log function.

I'm thinking a machine could be trained to follow my servo script and the results could be spectacular.

I delayed any effort to make my robot bug-walk because I hadn't thought of an elegant way till now.

I didn't want it clanking around stumbling over every obstacle, I want it to walk properly and turn, etc. negotiate obstacles and maybe even automatically load cargo or some other task.

O man, what am I getting into now?

It is a very nice idea, I've been thinking about it for a while. I am trying to write more-or-less universal script to operate a robotic crane arm for a shuttle, and having the ability to record and playback (at least) basic movements involving sevral servos would be of much help.

Now you can read the current Rotation from Rotatron for example and implement basic movements via some kind of loops, but I haven't tried recording desired parameters and playing them back yet.

Edited February 11, 2015 by Ziw

[stevehead]

Before submitting an issue on the github issue tracker, I was wondering if anyone else has the GUI for the config and kOS CPUs randomly open in the Kerbal Space Center screen? I noticed this issue back when the GUI was first introduced with an earlier version of 0.15.x, before KSP 0.90 was released; back then, the issue was more reproducible by changing scenes (e.g. switching from the Astronaut Complex back to the KSC). I'm still experiencing this, but not as often, and it recently happened when I returned to the game after alt-tabbing. I've been on a little KSP hiatus and was hoping that this was fixed in the more recent versions. It doesn't affect gameplay, but it is a little annoying since the kOS menu button is not displayed on the KSC screen so I cannot turn it off at that point; I use the Kerbal Construction Time mod and its build queue/settings window is at the same fixed position as the kOS GUI, so they are overlapping. Anyways, I'm still enjoying kOS and like to thank the guys that have developed it; looking forward to getting back to writing some scripts for it.

Edit: Screenshot for clarification: https://www.dropbox.com/s/3hsp9bl4b1j5jvj/screenshot0.png?dl=0

Edited February 11, 2015 by stevehead
Added screenshot

[Drew Kerman]

nope, never ever seen that happen to me. Nor do I have KCT installed

[Wercho]

Before submitting an issue on the github issue tracker, I was wondering if anyone else has the GUI for the config and kOS CPUs randomly open in the Kerbal Space Center screen? I noticed this issue back when the GUI was first introduced with an earlier version of 0.15.x, before KSP 0.90 was released; back then, the issue was more reproducible by changing scenes (e.g. switching from the Astronaut Complex back to the KSC). I'm still experiencing this, but not as often, and it recently happened when I returned to the game after alt-tabbing. I've been on a little KSP hiatus and was hoping that this was fixed in the more recent versions. It doesn't affect gameplay, but it is a little annoying since the kOS menu button is not displayed on the KSC screen so I cannot turn it off at that point; I use the Kerbal Construction Time mod and its build queue/settings window is at the same fixed position as the kOS GUI, so they are overlapping. Anyways, I'm still enjoying kOS and like to thank the guys that have developed it; looking forward to getting back to writing some scripts for it.

Edit: Screenshot for clarification: https://www.dropbox.com/s/3hsp9bl4b1j5jvj/screenshot0.png?dl=0

This happens to me, and I also use KCT. I've never bothered to do anything about it because it doesn't affect play, but it is a bit distracting.

[Ziw]

Before submitting an issue on the github issue tracker, I was wondering if anyone else has the GUI for the config and kOS CPUs randomly open in the Kerbal Space Center screen? I noticed this issue back when the GUI was first introduced with an earlier version of 0.15.x, before KSP 0.90 was released; back then, the issue was more reproducible by changing scenes (e.g. switching from the Astronaut Complex back to the KSC). I'm still experiencing this, but not as often, and it recently happened when I returned to the game after alt-tabbing. I've been on a little KSP hiatus and was hoping that this was fixed in the more recent versions. It doesn't affect gameplay, but it is a little annoying since the kOS menu button is not displayed on the KSC screen so I cannot turn it off at that point; I use the Kerbal Construction Time mod and its build queue/settings window is at the same fixed position as the kOS GUI, so they are overlapping. Anyways, I'm still enjoying kOS and like to thank the guys that have developed it; looking forward to getting back to writing some scripts for it.

Edit: Screenshot for clarification: https://www.dropbox.com/s/3hsp9bl4b1j5jvj/screenshot0.png?dl=0

I have this bug all the time, but for me it is more of annoyance as it does not cover anything important.

[stevehead]

Well I couldn't find any other post about it. I was just curious to see if it was just me. I understand how this would be low priority on the list of things to do / fixes. No big deal. It doesn't impede on my enjoyment of the mod.

[Wercho]

I should be able to type,

lock myporttotargetport to (myport:facing*target:position).

And that should give me a vector from my port to the targetted port, right?

The vector from your port to the targetted port would be:

 lock myporttotargetport to targetport:position - myport:position.

The code you pasted would find the vector from the origin (approximately ship center of mass, I think, NOT "controlled from" part) to the target port, and then rotate it by the port facing. That's why the drawn vector is slightly off. You are calculating targetportposition based on the ship origin, then basing future calculations assuming it was calculated from the port origin.

For the rest, I would definitely suggest changing all of your facing statements to portfacing, because I suspect with the surface mounted docking ports those directions may not be the same. In fact, based on the picture it seems clear that the FORE vector is pointing along the ship's FORE vector, and I bet the portfacing FORE vector would point directly along the ports docking axis. It'll probably mess with your immediate calculations, but I think that'll help in the end.

I hope this helps and I didn't get stuff to wrong.

- - - Updated - - -

Double post, but this one is on a separate topic.

Devs, would it run better better to write code that references the part suffixes everytime, or set a variable to a given quantity and then reference that variable? As in should I reference ship:velocity:surface multiple times per loop, or set varSVS to ship:velocity: surface and then use varSVS? Basically, I'm asking if the ship:velocity:surface or other such calls consume much processing power, such that a kOS script could have an appreciable affect on the smoothness with which KSP runs by repeatedly querying the KSP engine.

[Parastie]

Hey that helps a lot!

I'm actually not using "control from here" as there's a bug that if you change control from to something other then what's inline with the ship and try to lock steering, it just spins out of control. I had thought that multiplying my target vector by a rotation would get me the correct information, but that obviously wasn't correct. A few more refinements and I should get it.

I had assumed that facing, and portfacing were the same, but having checked, you are correct they are not the same. The vectors differ slightly in the above configuration (though not in the screenshot). I'll have to give that a shot when I get more time. I'm still not sure why exactly the orange vector is pointing ever so slightly off, even though the angles I'm getting are more correct. It's lightly from the portfacing vs facing.

[Richy330]

Maybe it will be good to include such function in kOS, when you call it it will give you current acceleration of craft.

That will allow to make more simple script and leave room for more complicated tasks.

Shouldn't it be possible to get acceleration by differentiating your velocity vector over time?

[kcs123]

Shouldn't it be possible to get acceleration by differentiating your velocity vector over time?

Yes, it should be possible to get by differentiating velocity vector over time, I was not thinking about that as possible solution. There is one problem with that aproach, though.

Not sure if that will be problem at all, maybe it will be actualy better solution , but by differentiating velocity vector you will get acceleration of whole craft.

Meaning other velocity vector were added to main velocity vector. Those are from gravity and from wing lift.

With mentioned method by calculating acceleration with thrust and craft mass you will get scalar value that is closer to previous "Set throttle to 50%" commands used in already developed kOS scripts, without need to wory about direction of vector or if some other forces are included or not. English is not my native language, I hope that I was able to clarify first idea that poped up when Steven mentioned changes in upcoming version of KSP.

[Dunbaratu]

Devs, would it run better better to write code that references the part suffixes everytime, or set a variable to a given quantity and then reference that variable? As in should I reference ship:velocity:surface multiple times per loop, or set varSVS to ship:velocity: surface and then use varSVS? Basically, I'm asking if the ship:velocity:surface or other such calls consume much processing power, such that a kOS script could have an appreciable affect on the smoothness with which KSP runs by repeatedly querying the KSP engine.

The cost of the access via the suffix chain varies depending on the suffixes in question. It's sometimes quite expensive, and sometimes negligibly small, but it's never quite zero. (Due to the way suffix calls are built at the moment, the more suffixes a term has the more expensive it is to create it. One of the more expensive calls is VESSEL("vessel name here"), because any creation of a vessel object needs to build up about 30 suffixes to attach to it, and also getting the vessel from KSP in the first place means doing a sequential walk of all the vessels in your saved game and checking each name. In a new saved game that's quick, but by the time you have hundreds of "flights" in progress (Flags and debris laying on the ground aren't "flights", dammit SQUAD!) it gets more expensive to say Vessel("name") and you should really just do it once up front and then keep it in a variable from then on.

It's almost always more efficient to store a long suffix chain into a single variable, but often not by enough to matter. Most of our examples show the whole chain just because they make more legible examples that way. You can see in a glance where the thing we're talking about is found in the API that way.

But beware of premature optimization. Often the legibility you are sacrificing is worth more, in the long run, than the speed you get by doing it.

Especially since KSP is doing an enormous amount of work 30 times a second or so anyway. The extra cost you're putting on it by your kOS script is often tiny. The only really expensive thing relative to the rest of KSP is the act of initially parsing and compiling the script. If you have a longer script you may have noticed KSP's animation hiccup a moment when you first type the RUN command for it. kOS is, literally, trying to perform an entire parse and compile within the span of one single animation frame. It doesn't have the sophistication to split that activity up into more than one animation frame to smooth it out. (That's a lot of work. You'd have to retain the whole state of the parser and partly built ML code halfway through and resume it where it left off. It's unlikely that we'll ever fix that soon, as there's bigger fish to fry.)

To give an example of why the expense of your kOS code probably doesn't matter too much, consider this:

Roughly 10-15 times a second (*), kOS has to re-draw the *entire* screenful of characters in each open terminal. It's going through an entire 2D array of 50x36 chars (more after my terminal resizing stuff is released) and individually looking up each one for its matching subset of the font image file to find the right picture for that character, then tiling that part of the image to the right position for it on the terminal, even when it hasn't changed since last animation frame, its still re-doing that. This is how Unity requires that GUI's be made. They have to be re-drawn over and over or they disappear (in fact that's how you erase a button or a bit of text - just skip over the part of the code that's been drawing it.)

Compared to that, what your code is doing is going to probably be small potatoes.

(*) - GUI windows are drawn less frequently than your framerate, but still quickly enough to be responsive to user actions.

- - - Updated - - -

As for the problems with vectors, I admit I haven't looked at that part of the conversation too carefully over the last few days. I've been sort of glossing it over, spending my kOS time on the cool thing I want to add about telnet instead. Partly its because I'd like to have a working version of it around to be able to let the people at /r/ksptomars/ use it, as I think it would be perfect for what they're trying to do.

If the problem isn't solved by the time I finish with that I'll come back and have a look at it in more detail.

[Kartoffelkuchen]

Hey, how can I show off those Arrows?

And how can I set a target to a coordinate position; like 15ºN and 4ºW ?

Edited February 13, 2015 by Kartoffelkuchen

[KK4TEE]

Hi everyone!f I've spent the past week working on another tutorial for kOS and tried to incorporate a few of the community's suggestions. This video demonstrates how to de-orbit and land a rocket propulsively near the Kerbal Space Center. Enjoy!

[Ziw]

Hey, how can I show off those Arrows?

And how can I set a target to a coordinate position; like 15ºN and 4ºW ?

I'll give you a hint

set v2 to VECDRAWARGS(V(0,0,0), upvector, RGB(1,0,0), "upvector", 10, True).

the rest you can find in the manual.

[Dunbaratu]

Hi everyone!f I've spent the past week working on another tutorial for kOS and tried to incorporate a few of the community's suggestions. This video demonstrates how to de-orbit and land a rocket propulsively near the Kerbal Space Center. Enjoy!

*clap**clap**clap*.

Very helpful to have these.

[Dunbaratu]

kOS Telnet. The pull request is in and now we're working on getting it all merged in nicely:

[Ziw]

kOS Telnet. The pull request is in and now we're working on getting it all merged in nicely:

Amazing!!! Can't wait to get my hands on it!.

Couple questions:

1) in your video you connected to one of the cores via telnet without ingame terminal open (it is the option I look forward to the most as I value my KSP screen real estate). But what about connecting to multiple cores in different terminal windows simultaneously - is it possible?

2) Will it be possible now to use color for text output in terminal?

P.S. As a side question - you said you are considering increasing default disk storage for cores, is there any chance to see this change implemented too? I know I can edit my part.cfg manually, but maybe you are finally convinced that this limitation is hindering the quality of the programs you can actually store on the craft.

Edited February 14, 2015 by Ziw

[Dunbaratu]

But what about connecting to multiple cores in different terminal windows simultaneously - is it possible?

Yes. If you scan the video to the very last few seconds of it and freeze frame it there you can see a still screenshot of me doing just that.

Will it be possible now to use color for text output in terminal?

Not yet. Not directly. It's a future idea I have but I wanted to get it released with the minimum functionality first. The minimum goal I had was "Make the telnet window able to do exactly what the in-game terminal already can". Color requires a bit of thought because it means deciding whether or not the in-game terminal should have it, whether we want to consider terminal capability to be a tech-tree upgradable thing, etc.