[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

After much messing around, I finally got my docking script to work...well most of the time anyway.

The code is an absolute mess and my vectors overshoot, as you can see in the video. Basically, I should calculate the needed thrust better (instead of just running a pulse until the desired speed is met). I have ideas of how to make this work better, but I'm going to have to take a break for the next 3 months while RL gets in the way. Thank you Steven for helping me! Here's a pastbin to the code, I added lots of comments to help myself and anyone else who'd look at what's going on. See you guys mid May! Can't wait to see how this has progressed by then!

[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

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.

[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

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

[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

At one point I do the following up front (before the main loop starts). At this point, myPort has already been selected to be the Part for the port, picked by using SHIP:PARTSDUBBED("whatever") where "whatever" is the name you see me typing into the nametag for the "this" ship (rather than for the "other" ship).

// Find axis of rotation, and angle around that axis, to rotate from my ship:facing to my myPort:PORTFACING.

set rotAngle to VANG( SHIP:FACING:VECTOR, myPort:PORTFACING:VECTOR ).
set rotAxis to VCRS( SHIP:FACING:VECTOR, myPort:PORTFACING:VECTOR ).
set rotAxis to rotAxis:NORMALIZED.

// Splitting the rotAxis into its 3 component parts, in a reference frame that is oriented
// to match my ship:facing:
set rotAxisX to VDOT( rotAxis, SHIP:FACING:STARVECTOR ).
set rotAxisY to VDOT( rotAxis, SHIP:FACING:TOPVECTOR ).
set rotAxisZ to VDOT( rotAxis, SHIP:FACING:FOREVECTOR ).

// Then, further down, constantly being updated in my loop, I do this to get the information about the target port:

  set otherPortRot to otherPort:PORTFACING.
  set otherPortInverseRot to ANGLEAXIS(180,otherPortRot:TOPVECTOR)*otherPort:PORTFACING.

Then further down, I use that to work out what direction I should be steering my nose at to make my port orient with the other port:

  set otherPortInverseRotAxis to otherPortInverseRot*V( rotAxisX, rotAxisY, rotAxisZ ).
  set myPortRotRelToOther to ANGLEAXIS(-rotAngle,otherPortInverseRotAxis)*otherPortInverseRot.

At this point, you should be able to LOCK STEERING TO myPortRotRelToOther.

That works perfectly!

The ship points exactly where I want it to, and now I understand better what's going on. I'm going to have to think about this a lot more, but I've got a good idea how I want the movement to to work now. Thanks again!

[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

This is true and how I worked around it in my script from the video was this: I don't do a "control from" my docking port. Instead I calculate which rotation Direction goes from ship's control orientation to my docking port's orientation. Once I know that rotational offset, I can use it to point my nose rotated the opposite way to that without using "control from here". (In other words, if my docking port is rotated 45 degrees yawed from my control orientation, then when I discover the orientation I want my docking port in, I should point my nose -45 degrees yawed from that. The new Direction suffixes and constructors make this possible.)

In your video, are the offsets for the different docking ports hardcoded, or is your script able to calculate the offset and make adjustments on its own? I'm assuming your script calculates it, as each port is it a wildly different point.

[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

I realize that what I posted was a giant wall of text that it was easy to miss stuff in, but that actually is what I was suggesting doing.

(The bit where it says: The challenge starts with a sandbox-mode saved game, made available for public download, in which there exists a space station in orbit around Kerbin.)

(Later on I mentioned that if you want percentage of cost returned back (for SSTOs) to be part of the challenge scoring it would have to be a career-mode saved game instead of sandbox, just because KSP won't show you the amount of recovery refund in sandbox mode.)

That's sort of why I split it into two parts. I'm unsure whether or not I *should* show the script yet if there might be a contest going on, and I'm still waffling on that.

I must come off as as an idiot sometimes...

I've only one question about your script. Are you using raw controls for rotation, or is it possible to figure out the correct vectors to use cooked controls? As in, you're able to lock steering and/or lookdirup to rotate the ship to place the port in the correct orientation?

[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

I was thinking that kOS has hit a new maturity point where it's probably worth it to have another Challenge contest like the ancient one from over a year ago. That contest really helped spur kOS on because it made people try areas the mod wasn't so good at, which helped explore the edges of what it could do, and helped figure out what things would be helpful to add to it. I had a lot of fun back then being a participant in it, although some things were a lot harder than they needed to be.

Things have gotten a lot more mature and I think it's time for a new challenge contest.

I had an idea myself for a nice one but I don't want to post it for the following reasons:

1: The challenge forum has the rule that you shouldn't make a contest for which you haven't posted a proof of your own ability to succeed at it (i.e. your own entry into your own contest, so to speak). This rule was established because there had been a few cases of people being jerks posting contests they knew cannot be done, designed to trick people into wasting their time trying. They would often say "oh trust me it can be done, I've done it, but I won't show you my solution until you start posting yours", when they know it can't actually be done. The purpose behind the requirement was to prove a minimal entry is possible. It doesn't have to be your best entry, and you can re-enter a second, better scoring entry later on. It's just meant as the proof of concept to prove you're not lying about the challenge being possible.)

2: I decided that I should really recuse myself from participating in any challenge contests about kOS after I became more heavily involved in helping develop it. I've got too much ability to change the mod to make it into what I need it to be ("Oh look the mod is missing a feature I'd need to do this task - so I'll go and add it in and get that feature into the next release, and get the release out in time for my contest entry..."). I've also got too much "inside information", as in "Oh, this feature's not documented that well, but no worries, I'm the one who wrote it, so I know how it works without the docs." I've also got more "lead time' than others do. I can start writing scripts using new features before the new features are publicly mentioned.

It's the combo of #1 and #2 that I think mean I can't really lead a Challenge Contest myself. To lead the contest I need to show my own entry into it. But I don't think I should be entering myself into a challenge.

That being said, this is the idea I had for a potential contest:

kOS Space Station Crew Exchange Challenge

The challenge starts with a sandbox-mode saved game, made available for public download, in which there exists a space station in orbit around Kerbin.

The space station has the following things on it:

• A port with nametag="Easy Port" - a docking port along the station's main central axis, at one end, clear of obstructions.
  
• A port with nametag="Medium Port" - a docking port located not along the station's main axis, at a weird diagonal angle, and aligned askew from its center of mass.
  
• A port with nametag="Hard Port" - a docking port similar to "Medium Port", but not only is it at a weird angle and not central, it's located in a dangerous way with breakable solar panel obstacles around, making it likely that you'll break the solar panels if you just try to dock straight at the port clumsily.
  
• Crew onboard.
  

You're allowed to build whatever docking ship you like to dock to the station, but depending on the design of its docking port, it may be worth more or less points. It should have crew space for at least 1 crew. It can have more but it's actually detrimental to your score to do so, as you'll be scored based on least monoprop used, and larger ships are going to use more - you're best to go with just 1 crew capacity.

The challenge is to start from that saved game and attempt to do the following:

• 1. Launch your craft from KSC to orbit. must be automated by script
  
• 2. Rendezvous your craft with the station. must be automated by script
  
• 3. Dock your craft to the station without breaking anything (like a solar panel). must be automated by script
  
• 4. Exchange 1 crew member between the craft and the station - move one crew out of the craft and one crew into it. You are allowed to do this step manually with the stock crew transfer mouse interface.
  
• 5. Undock your craft from from the station. You are allowed to do this step manually with the docking port's right mouse button menu
  
• 7. Move your craft away from the station safely without breaking anything (like a solar panel). must be automated by script
  
• 8. Return the crew member to Kerbin intact, trying to land close to the KSC if you can. must be automated by script
  

You are allowed to use the interactive terminal for file and run commands: COPY, SWITCH TO, RUN, etc, at any point during the mission, and doing so will not count as "doing things manually" (thus if you can't fit the entire sequence of scripts on the ship at once, that's fine - you can swap files in and out.). THIS mission is not intended to be a signal-delay challenge mission where you can't type commands. It all takes place within near-Kerbin orbit.

Things that could be used as criteria to affect your score (although I haven't really thought through which of these are more important, and how they should balance against each other, or which of them should be dropped. A good challenge should really only contain about 4-5 scoring criteria. Too much more and it gets messy to track):

• more points for docking to the harder ports on the station.
  
• more points for using a harder docking port on your own ship (one not just easily aimed out the nose of your ship, but one that you have to calculate directions from weirdly, like the harder ones on the station described above).
  
• less points the more monopropellant fuel was consumed. Docking with mechjeb can be monopropellant-hungry, and I'd like to think a specialized kOS script can do it better.
  
• less points the more torque power the docking craft had (more points for doing it all on RCS). (Yes I know there's a bug about using ships that don't have torque, but there's also a supposed fix donated by github user soulsource that should come out the next time there's a release).
  
• less points for more time elapsed (on the gameworld's clock, not the user's time) between start of the savegame's timestamp to the timestamp of the final landing. This will effectively reward people for managing to get a good rendezvous quickly.
  
• More points the closer to KSC the landing site was.
  
• Reusability ratio: Compare the recovery cost of the amount of your craft that landed on return to the initial cost of it at launch. Better reusability ratios mean better scores. (The purpose of adding this scoring criterion would be to give a boost to the scores of people who managed to do it with an SSTO. SSTO's present harder scripting challenges and should be rewarded for it. This would do so because they're landing the whole ship again and only payed for the fuel.)) (For this to work you probably need the initial save game to be a career mode game so it can calculate funds. I can show you how to set up bogus data to make a career mode game have lots of funds and upgraded buildings. The only reason for making it career-mode would be to turn on KSP's calculation of ship cost so you can perform this scoring.
  

Again, I don't recommend all the above be used, but they're a clue as to what could go into the scoring criteria.

Is anyone willing to set up a thing like this, and take the lead on it in the forum? (Or, to make it all your own idea, to counterpropose a different challenge). I just like the idea of there being a kOS challenge in the forums. It's been a while and I'm thinking about it. I'm thinking about docking because that's the most recent scripting I was working on.

I like the idea of this, especially since it's more or less what I've been trying to do (my difficulty is time, with my family at home and work, I have little time to play games). I think it'd be worth making a standard "station" craft file that anyone participates can download, perhaps even a save file with the station already in orbit. It would help standardize the challenge. If someone takes this up, please PM me the link to your challenge, and I'll place it as a sticky on the subreddit for kos as well!

Also, thanks very much for the tutorial! At least I know it's possible to do what I've been trying to do. I'll see if I can get it before you make your longer tutorial. Thanks again!

[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

Hey I've got another question.

If i do print ship:position I will get v(0,0,0) and that's a vector right?

And when I print part:position, is that number relative to the ship, or is it relative to the universe, or am I just not understanding how the vector systems works?

Basically, I'm trying to get the side port to line up with a target. The side port's position shouldn't change relative to ship's position as it's fixed to the ship. I should be able to just be add the port's position to the ship's position, and then minus that from the target's position to get where they are relative to each other right?

My problem is, the port on the ship's position when i type, print port:position (and i'm certain it is the port on the ship) keeps changing, and i'm not certain how exactly i should fix it in order to zero out movement relative to target and get alignment for a docking.

I understand that we're suppose to figure this stuff out on our own, but any any help (including pointing me to some reading material so i can understand this better) would be a great!

[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

In my case my goal was to make a raw-steering (not LOCK STEERING) example of how to do docking from one weirdly aimed docking port to another, as a proof of concept of the new direction and position suffixes for parts, so because I was trying to do it with raw SHIP:CONTROL techniques the fact that LOCK STEERING didn't work right was of lesser priority to what I was trying to do.

But yeah, that reminds me that I never did make the example video for that test case like I meant to. I really should.

LoL

That would be very helpful. I'm having a hell of a time trying to get the side port to position itself correctly. I suppose I could just get the position of the port, then use raw control to position of the control ship's port until the positions zero out. I think that would work...

[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

I noticed that too and reported it as issue number 397, but I didn't look into the cause because I was leaving the steering up to erendrake to deal with while I worked on other stuff, and I wasn't even sure it was real as I had a lot of other problems at the same time and it was hard to isolate one bug from another. If you're able to perfectly recreate it with a known craft and a known set of actions, it would be great if you could add your information to that bug report.

Sure, it does it every time. That's why I'm now trying to figure the angles to the port so I can get it to align with a target. I thought it should be 90 degree angle but I see I'm going to need to read a lot more.

I'll try to put a bug report up today.

[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

Yeah thats the effect of the scale operator. It mulitplies both the offset start position and the vector itself. That may be silly. If nobody is using it that way i may remove the part about multiplying the start pos and just multiply the vector size only.

In the mean time to get what you want just multiply 5 by the second argument only.

Thank you that works great. Now I'm just figuring out the movement and steering.

Here's a fun thing I discovered: if you have a inline docking port and set 'control from here' on that port, then attempt lock steering to up. It will spin around like mad, at least the small probe I have in the pictures above does. I think its because the torque and the center of mass are not lines up with port.

It will lock with no problem as long as I leave the control on the probe computer.

[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

Your description is missing the most important bit: What is it about this that doesn't work? are you getting an error message? Is something not showing up on screen?

Sorry, the problem is the origin position of the vector drawn on screen appears several meters away from the port:position that I set it to. I discovered, however, that if I set the magnitude to 1 (in the original code I was using from the github docs it was 5), then it appears exactly as I expect it to. I've attached screenshot below to show what I mean.

This is with mag set to 1: http://i.imgur.com/PoScCGL.png

This is with mag set to 5: http://i.imgur.com/OA4buTc.png

It's not currently part of an overall program, I'm just trying to learn how everything works.

[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

The ship's raw position IS V(0,0,0) in kOS terminology. The weird contradictory coordinate system of underlying KSP is re-origined at the current ship's CoM for all position vectors in kOS (although it's not re-rotated to something sane - it stays at the underlying rotation). Oddly enough, it's still not origined at the vessel for VELOCITY purposes (which would zero your velocity if it was), but rather it reports the velocity at which the rest of the objects in the universe are passing you by.

The problem then must be my syntax for the origin point of the vector. Sorry if this is a very easy answer, but I haven't played with programming since Basic and Pascal in high school and geometry/trig was around that time as well.

Here's the code:

lock t1 to ship:position.
lock pv to port:portfacing:vector.


set pm1 to ship:modulesnamed("ModuleDockingNode").
for portmod in pm1 {set port to portmod:part.}.

set aa to vecdrawargs ( t1,pv,RGB(0,1,0.5), "axis", 5, true ). 

[[1.3] kOS Scriptable Autopilot System v1.1.3.0]

Question regarding vecdraw and an offset piece. Basically, I have an inline docking port and I'm trying to get the origin of the vector to be the docking port. However, when I set the vector origin to the port origin it generates off the main ship.

I'm guessing the the position is a raw position and I can't figure out the proper syntax to get the ships raw position (as apposed to (0,0,0). I'll post my short script when I get home from work if it'll help. Thank you!