[KSP 1.12.x] kOS v1.4.0.0: kOS Scriptable Autopilot System

[RizzoTheRat]

I usualy Lock steering to ship:velocity:orbit (or ship:velocity:surface) rather than use ship:prograde 

[danielboro]

2 hours ago, Xd the great said:

How do you lock prograde?

i use

lock steering to prograde.

[Xd the great]

1 hour ago, danielboro said:

i use

lock steering to prograde.

As in what exactly do i have to type.

[ElWanderer]

5 minutes ago, Xd the great said:

As in what exactly do i have to type.

"lock steering to prograde."

Literally, what's inside the quotes is what you would type in the terminal (or into a script) to lock the steering to orbital prograde (surface prograde would need srfprograde instead of prograde).

Is there more to your question than that?

[Xd the great]

4 minutes ago, ElWanderer said:

"lock steering to prograde."

Literally, what's inside the quotes is what you would type in the terminal (or into a script) to lock the steering to orbital prograde (surface prograde would need srfprograde instead of prograde).

Is there more to your question than that?

Ah thanks.

[RizzoTheRat]

43 minutes ago, Xd the great said:

Ah thanks.

I would seriously recommend working through the tutorial on Github.  It actually gives you a pretty good idea of the basics and helped me get going when I first started playing with KOS.

https://ksp-kos.github.io/KOS/tutorials/quickstart.html

[RizzoTheRat]

21 hours ago, Steven Mading said:

The only thing I can think of is that target *must* be getting changed to something else somewhere, and that change is happening maybe from one physics tic to the next which is why it only happens when you have longer code (that allows a physics tic to happen between setting it and using it).

Maybe this test might help - put this statement between each line between the setting of target and the line that errors:

print "AAA: target type = " + print target:typename.

but change that AAA to BBB, and CCC, and DDD, etc on each subsequent line so you can tell the lines apart and tell which line of code printed which line of output.

At some point in there, the target has to be getting changed to another type, and discovering exactly when that happens might help.

Once you have that test set up, and you see where the type gets changed, then try this:  Leave the code alone, but change your config:IPU to other values and try again to see if the place where it changes ends up *moving* when you do that.  If changing the IPU causes the change to happen at a *different* line, then that would confirm that its something that happens when a new physics tic starts.

If it is something that happens when a new physics tic starts, then that might be a kOS bug, or it could still be a script problem if your script has any triggers like WHEN or ON, or LOCK STEERING, that might execute code between tics and cause Target to change to something else.  Either way, narrowing it down will help (either me if it's kOS, or you if it's the script) find the cause.

Tried running this bit of code 

clearscreen.

function drawvecs{
	print "008: target type = " + target:typename.
	Set TgtVec to VECDRAWARGS( V(0,0,0), target:position, blue, "Target", 1, true).
	print "009: target type = " + target:typename.
	set TgtForevec to VECDRAWARGS( target:position, ApproachDist*target:portfacing:vector, Green, "Port", 1, true).
	print "010: target type = " + target:typename.
	Set ReqPath to VECDRAWARGS( V(0,0,0), target:position + ApproachDist*target:portfacing:vector, Yellow, "Path", 1, true).
	print "011: target type = " + target:typename.
	
	Set UpVec to VECDRAWARGS( V(0,0,0), 10*UpVel, White, "Up", 1, true).
	print "012: target type = " + target:typename.
	Set ForVec to VECDRAWARGS( V(0,0,0), 10*ForVel, White, "Fore", 1, true).
	print "013: target type = " + target:typename.
	Set SideVec to VECDRAWARGS( V(0,0,0), 10*SideVel, White, "Side", 1, true).
	print "014: target type = " + target:typename.
	}

Set ApproachDist to 20.

SET KUniverse:ACTIVEVESSEL TO VESSEL("Docker").
Set target to "Agena".
wait 1.
set PortList to target:modulesnamed("ModuleDockingNode").
for Ports in PortList {
	set port to Ports:PART.
	print port:name.
	if port:tag = "TgtDockPort" {
		set target to port.
		print "Docking port targetted".
	}
 } 

print "001: target type = " + target:typename.

Set shipheading to target:position + ApproachDist*target:portfacing:vector.
set angle to vang(shipheading,target:position).
Set MissDist to target:position:mag * sin(angle).
print "Missdistance : " + MissDist.
print vang(target:position,-target:portfacing:vector).
print "002: target type = " + target:typename.
Lock Vrel to ship:velocity:orbit-target:ship:velocity:orbit.
print "003: target type = " + target:typename.
lock shipUp to (ship:facing * R (-90, 0, 0)):vector:normalized.
print "004: target type = " + target:typename.
Lock Upvel to ship:facing:topvector*vdot(ship:facing:topvector,Vrel).
print "005: target type = " + target:typename.
lock ForVel to ship:facing:forevector*vdot(ship:facing:forevector,Vrel).
print "006: target type = " + target:typename.
Lock SideVel to ship:facing:starvector*vdot(ship:facing:starvector,Vrel).
print "007: target type = " + target:typename.
drawvecs().

and it worked the first time.  So I added in another 20-30 lines of code and it fell over Print 10.  Removed the extra lines and it still falls over after Print 10.

All 10 say target type = Docking Port and it says GET Suffix 'PORTFACING' not found on object VESSEL("Agena")

 

I set the config:ipu to 300 and ran it again.

This time I got 12 as Docking port and 13 as Vessel before GET Suffix 'SHIP' not found on object VESSEL("Agena")

 

So it does look like it's randomly changing the target between ticks.

 

I'll give it another go with setting the variable in a loop and see if that doesn't anything different from using Lock.

 

For reference I'm using KOS v 1.1.6.1 and KSP 1.6.1.2401. 

 

Edit to add..

Changed the Locks to Sets in a loop for 10 seconds

clearscreen.

function drawvecs{
	print "008: target type = " + target:typename.
	Set TgtVec to VECDRAWARGS( V(0,0,0), target:position, blue, "Target", 1, true).
	print "009: target type = " + target:typename.
	set TgtForevec to VECDRAWARGS( target:position, ApproachDist*target:portfacing:vector, Green, "Port", 1, true).
	print "010: target type = " + target:typename.
	Set ReqPath to VECDRAWARGS( V(0,0,0), target:position + ApproachDist*target:portfacing:vector, Yellow, "Path", 1, true).
	print "011: target type = " + target:typename.
	
	Set UpVec to VECDRAWARGS( V(0,0,0), 10*UpVel, White, "Up", 1, true).
	print "012: target type = " + target:typename.
	Set ForVec to VECDRAWARGS( V(0,0,0), 10*ForVel, White, "Fore", 1, true).
	print "013: target type = " + target:typename.
	Set SideVec to VECDRAWARGS( V(0,0,0), 10*SideVel, White, "Side", 1, true).
	print "014: target type = " + target:typename.
	}

Set ApproachDist to 20.

SET KUniverse:ACTIVEVESSEL TO VESSEL("Docker").
Set target to "Agena".
wait 1.
set PortList to target:modulesnamed("ModuleDockingNode").
for Ports in PortList {
	set port to Ports:PART.
	print port:name.
	if port:tag = "TgtDockPort" {
		set target to port.
		print "Docking port targetted".
	}
 } 




print "001: target type = " + target:typename.
Set shipheading to target:position + ApproachDist*target:portfacing:vector.
set angle to vang(shipheading,target:position).
Set MissDist to target:position:mag * sin(angle).
print "Missdistance : " + MissDist.
print vang(target:position,-target:portfacing:vector).
print "002: target type = " + target:typename.
	
set starttime to time:seconds.
until time:seconds>starttime+10{	
	
	set Vrel to ship:velocity:orbit-target:ship:velocity:orbit.
	print "003: target type = " + target:typename.
	set shipUp to (ship:facing * R (-90, 0, 0)):vector:normalized.
	print "004: target type = " + target:typename.
	set Upvel to ship:facing:topvector*vdot(ship:facing:topvector,Vrel).
	print "005: target type = " + target:typename.
	set ForVel to ship:facing:forevector*vdot(ship:facing:forevector,Vrel).
	print "006: target type = " + target:typename.
	set SideVel to ship:facing:starvector*vdot(ship:facing:starvector,Vrel).
	print "007: target type = " + target:typename.
	drawvecs().

}


print Vrel:mag.
lock steering to shipheading.

 

4 is a docking port, 5 is a vessel but it doesn't hit anything that causes it to fall over until after 9.

 

Wierd

Edited February 12, 2019 by RizzoTheRat

[Dunbaratu]

@RizzoTheRat Are there any of these in your code which aren't being shown in the forum?

ON ____ {    }

WHEN _____ THEN {   }

LOCK STEERING TO .....

LOCK THROTTLE TO ......

Those are all things that can fire off between ticks and execute code between ticks.

 

OOOH.  There's one other possibility - the KSP game refuses to allow setting target to docking port except when within a close distance.  If you drift a bit farther away, it may force the target to be the whole vessel instead of a part.  It could be that it forces this to happen between ticks.

[RizzoTheRat]

29 minutes ago, Steven Mading said:

OOOH.  There's one other possibility - the KSP game refuses to allow setting target to docking port except when within a close distance.  If you drift a bit farther away, it may force the target to be the whole vessel instead of a part.  It could be that it forces this to happen between ticks.

Aha!

 

I set up a script to calculate some vectors and print the distance.  If I'm more than 200m away from the target ship it runs fine while the KOS window is active, but trips out due to the ship being targeted not the port as soon as I click in the KSP window to take focus away form the KOS window.   I've just run it for a minute slowly drifting apart from 250+ meters and it was absolutely fine until I clicked on the ship.

Within 200m I can click on the KOS window or the KSP window and it's all fine. 

Odd that it's ok within the KOS window, which I guess is why it seemed inconsistent, but glad we know what the issue is, thanks for the help.

 

So supplementary question, is there a way to figure out the port facing vector for further away than 200m?  What I'm trying to do is manoeuvre the ship to a point a given distance away from the  docking port along the port facing vector so I can come straight in to dock.

[ElWanderer]

38 minutes ago, RizzoTheRat said:

So supplementary question, is there a way to figure out the port facing vector for further away than 200m?  What I'm trying to do is manoeuvre the ship to a point a given distance away from the  docking port along the port facing vector so I can come straight in to dock.

Do you have the same problem if you store the port in your own variable rather than using TARGET? That's what I do, and I've never had this problem, though my rendezvous is usually less than 100m out.

Also, I imagine that if you are far enough away that the target ship hasn't been properly unpacked/loaded (I forget which one is which right now), you may not be able to do anything as KSP won't know where the port is. You could carefully play with the various load distances if that turns out to be a problem.

[RizzoTheRat]

How do I store it as my own variable?  I tried referring to it as PART having identified it in a list of parts but that didn't work.

Good point on loading/unpacking distance though. best bet is probably going to just be close to sub 200m and then reassess, it means an extra manoeuvre though as I was hoping to approach a point 20m out along the portfacing vector, so I'll need to stop at <200 and then manouvre again to that point.  Not the end of the world though.

Looks like increasing the load distance can act as kraken bait, but increasing it within the code and decreasing it again when closer might be an option I guess.  My test target only has one docking port on it's central axis so portfacing-ship:facing which makes it simple for now though.

[Dunbaratu]

1 hour ago, RizzoTheRat said:

Aha!

 

I set up a script to calculate some vectors and print the distance.  If I'm more than 200m away from the target ship it runs fine while the KOS window is active, but trips out due to the ship being targeted not the port as soon as I click in the KSP window to take focus away form the KOS window.   I've just run it for a minute slowly drifting apart from 250+ meters and it was absolutely fine until I clicked on the ship.

Within 200m I can click on the KOS window or the KSP window and it's all fine. 

Odd that it's ok within the KOS window, which I guess is why it seemed inconsistent, but glad we know what the issue is, thanks for the help.

 

So supplementary question, is there a way to figure out the port facing vector for further away than 200m?  What I'm trying to do is manoeuvre the ship to a point a given distance away from the  docking port along the port facing vector so I can come straight in to dock.

Assign the target to a variable of your own so the game doesn't rip it away from you and change it.

As for the weird difference between the terminal being focused or not, I think I may have an idea and it's annoying because I'm having to work around a stock KSP bug.

Do you remember the behaviour kOS used to have where if you have the terminal focused and are looking at the map view, the map view would rotate if your ship was rotating?  Remember how annoying that was?  Well, it turns out after much trial and error that what caused it was the targettting input lock.  KSP has 64 different individual boolean flags for allowing/disallowing UI inputs to work.  There's a flag for keyboard input, a flag for steering, a flag for the throttle, a flag for switching vessels, etc.  One of these flags is for allowing picking a target.  In the past (when the rotation bug existed) kOS was always unlocking target picking at all times, so that a script can always do SET TARGET even if the player cannot through the UI (the UI flag banned even a program from doing it - because KSP melts together UI issues with low level API issues a lot of the time).  Now, what made no sense is that KSP caused the map view to rotate for some weird reason when that targetting input lock was unlocked.  (which happens as a side effect of switching focus).  There is no reason for that to make any sense, but I proved this is exactly what caused it.  When I made ONLY that one flag differ and none of the other input flags, that changed the map rotating behaviour.

So how to solve the problem of the rotating map?  Well I decided that the targeting input lock really only needs to be unlocked when setting the target.  So I did this:  When you run SET TARGET TO WHATEVER, kOS *temporarily* unlocks that input lock so the game will allow the target to be set, then puts it back the way it was again when the SET TARGET command is over.  That fixed the rotating map bug.  But now it looks like putting the target input lock back again after the SET means the UI code will re-assert itself and rip away the setting you made when it next runs between pysicks ticks.

So it looks like I can either get rid of the targeting bug, or get rid of the map rotating bug, but not both.  For some ridiculous reason, these two unrelated things are melted together somewhere inside KSP's hidden code - both being triggered by the same boolean setting.

The rule "cannot pick a docking port target > 200m away" is meant to be a UI rule, but that UI rule is affecting all calls to the API routine whether coming from autopilot software or from manual player control.  And so when the KSP game runs code in between kOS ticks, it sees "oh look the target is set to a part but we are >200m away, I will therefore re-assign the target to the whole vessel" because it's assuming that target had been set by a player.

At this point I'm going to just document it, rather than fix it - because it's hard to fight the KSP game's own behavior on this one.  Just use your own variable instead of TARGET, I guess.

 

Edited February 12, 2019 by Steven Mading

[ElWanderer]

41 minutes ago, RizzoTheRat said:

How do I store it as my own variable?

Instead of "SET TARGET TO port." do "SET my_variable TO port."

In my case I do something like "LOCAL target_port IS pickTargetPort(TARGET)." where the function loops through the ports on the input vessel and picks the "best" one. Actually I store the target in a variable too in case the player accidentally deselects or changes it during docking.

[SpinkAkron]

For those that may be interested, I released my script pack. 

Spink's Script Pack

[Dunbaratu]

2 hours ago, SpinkAkron said:

For those that may be interested, I released my script pack. 

Spink's Script Pack

I don't know if I'll have the time to check this out, but I fully support the idea of users doing this.  The more public examples there are, the easier it is for new people to see how things can be done.

 

@RizzoTheRat I don't think I'll be able to fix it, but I can at least document the problem you ran into.

The issue is here: https://github.com/KSP-KOS/KOS/issues/2435

[RizzoTheRat]

1 hour ago, Steven Mading said:

 

@RizzoTheRat I don't think I'll be able to fix it, but I can at least document the problem you ran into.

The issue is here: https://github.com/KSP-KOS/KOS/issues/2435

"The user is very confused."

Yeah, I think that captures it pretty well 

Good to know what the problem is is though, I should be able to work around it easy enough by assigning the port to a variable within a physics tick.

[funkheld]

Hi good afternoon.

I built two computers at the Pegasus:
- Pegasus CPU: CompoMax (test)
- Pegasus CPU: CompoMax (test1)

How can I load a program in each one now?
test.ks and test1.ks

Thank you.
greeting

[ElWanderer]

24 minutes ago, funkheld said:

Hi good afternoon.

I built two computers at the Pegasus:
- Pegasus CPU: CompoMax (test)
- Pegasus CPU: CompoMax (test1)

How can I load a program in each one now?
test.ks and test1.ks

Thank you.
greeting

If you've already put the ship on the launchpad, you can right-click on each CPU part and open a terminal. In each terminal, you'd then copy over and run one program. e.g. you might type COPYPATH("0:/test.ks","1:/"). RUNPATH("1:/test.ks"). in one terminal.

In general, its easier to set these up as boot programs that get loaded and run automatically. You do that in the ship editor (VAB/SPH) by right-clicking on the part and selecting a boot script. Note that first you need to have a folder named Boot within your Ships/Script directory, and have the programs you want to run in there, as it's that directory that is scanned when the VAB/SPH build editor starts. Note also that this choice of boot file(s) will be saved against the particular ship design so would need to be repeated for new designs. https://ksp-kos.github.io/KOS/general/volumes.html#special-handling-of-files-in-the-boot-directory

Edited February 13, 2019 by ElWanderer

[funkheld]

 

Hello thanks for info.

 

greeting

 

 

[Dunbaratu]

10 hours ago, RizzoTheRat said:

"The user is very confused."

Yeah, I think that captures it pretty well 

Good to know what the problem is is though, I should be able to work around it easy enough by assigning the port to a variable within a physics tick.

Although we don't have "atomic sections" to force two adjacent lines to be in the same tick, you can still guarantee it happens in the same tick by forcing a WAIT 0 right before the two lines in question, so you know even at a low IPU setting there will still be plenty of IPU to fit both lines in before there's a break, by starting a new update right before the section in question.

Edited February 13, 2019 by Steven Mading

[Drew Kerman]

18 hours ago, Steven Mading said:

I don't know if I'll have the time to check this out, but I fully support the idea of users doing this. 

if you want to include library links on the OP here's mine: https://github.com/KSAMissionCtrl/AFCS

I'm not going to make a release thread for it or anything tho, but I am more than happy to share it with anyone that wants additional references for how others are controlling their vessels

Edited February 13, 2019 by Drew Kerman

[RizzoTheRat]

Thanks fer the help folks, I now have my docking script working, apart from one small problem...How do I stop it?

I have the final approach on to the docking port running perfectly, but tried having it an UNTIL tgtPort:STATE = "PreAttached" loop, where tgtPort is the port as a variable.  I was hoping this would catch it in the wobbly moment before I lose the target but one of my calculations is still calling on the target between that being tripped and finishing the loop.  Is there a way to trip out of the loop as soon as trigger occurs?  Only think I can think of is stop the loop when the distance is half a meter rather than anything to do with the ports, but there must be a better way.

[infinite_monkey]

You could set the loop condition to a variable (false initially) and then set that variable to true in your trigger  After reading your text again, I guess this is not what you wanted. As far as I know, there's no way to end a program directly,  and in your case, return would just return from the trigger...

Edited February 14, 2019 by infinite_monkey

[RizzoTheRat]

As someone who learned programming in BASIC what I really need is a GOTO, but that's the kind of talk that gets you dragged outside and lynched by programmers

Yeah trigger variable has the same problem as my previous attempt, it will only stop the loop at the end of the current run through, if the loop still has things that use the Target after it's been lost it falls over.

I've set it to stop the loop when the distance is less than 0.5 for now but the fact I'm having this issue suggests there's a better way I should be doing the flow control.

[ElWanderer]

12 minutes ago, RizzoTheRat said:

As someone who learned programming in BASIC what I really need is a GOTO, but that's the kind of talk that gets you dragged outside and lynched by programmers

Yeah trigger variable has the same problem as my previous attempt, it will only stop the loop at the end of the current run through, if the loop still has things that use the Target after it's been lost it falls over.

I've set it to stop the loop when the distance is less than 0.5 for now but the fact I'm having this issue suggests there's a better way I should be doing the flow control.

It could suggest you're doing too much in one loop or that your final approach velocity is a bit high... For comparison, my loop ends when the docking port changes to any state that isn't ready, and I've never noticed this kind of problem. Then again, my loop is fairly simple, especially compared to the initial route calculation before approach. My final approach velocity is 0.2m/s once within a few metres.

I guess one goto-like approach would be to stick the loop contents into a function and load it with checks that can return early if the target becomes invalid midway through.