[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Bellicosity]

[REMOTE TECH QUESTION]

Im trying to find out how to target a body/vessel with an antenna from within a script.

I found the SHIP:PARTSDUBBED(string)[index] which will return a single part (setting it to, for example, myPart).

Then you can use myPart:GetModule("ModuleRTAntenna") to get the remotetech module (set that to myMod).

Finally, a call to myMod:doAction("toggle", true) will turn it on and (if you have no target for the antenna) myMod:doEvent("no target") will bring up the targeting screen. From there I have to click on the target instead of being able to say target ShipA. Is there another way to do this or am I making things hard on myself?

[Wercho]

Im trying to find out how to target a body/vessel with an antenna from within a script.

AFAIK, RT doesn't expose the targeting to a part module field or event. I'm guessing the target event activates something in the RT dll which creates the menu, so I'm pretty sure there is no way to automatically target an antenna through RT. I can't be positive though, because I use RT but have't looked at the source.

Try to use font with fixed width in terminal. Meaning, all characters should have same width regardless if it is "I" or "H" to be able to format texts properly.

I switch the terminal font for "Fixedsys", which sounds like fixed width and looks like it. I get the same result. I don't know enough about telnet to know whether this is a Putty problem, or kOS, or just some weird interaction with the settings. Looking at it, it seems that sometimes the Putty terminal puts the PRINT...AT in the right place (eg. "Tar.Land" "No" "Yes") and sometimes appends the new text to the end of the text that has already been printed on that row rather than putting it at the correct horizontal position. (eg. "Varies" "Hover" "Land").

Different craft for the new image, but the kOS terminal looks the same. Reposted for ease of viewer.

Another idiosyncrasy I've noticed is that when kOS clears the terminal when a program ends, the telnet terminal doesn't get cleared so I end up typing over the text. No big deal though.

[Dunbaratu]

For anyone having trouble with the telnet terminal - remember the control-L key

If you are having cases where the telnet terminal doesn't update well, then remember the Control-L keypress as a temp workaround. (It's documented on the docs referred to by he changelog, but admittedly it's buried pretty far down the page.)

Pressing Control-L will force the telnet terminal to redraw itself entirely from top to bottom, which might fix some problems with it getting out of sync. Still please do report such problems though, because having to fall back on that shouldn't be necessary, but it might work as a temp workaround until the fix is out.

For the specific problem Wercho found

I'm not sure if control-L will work with this one. I tested PRINT AT lots of ways and it worked when I did it. I am going to test it tonight but I suspect what's happening here is this:

Wercho printed PRINT AT to a new, unpainted area of the screen. I was using PRINT AT to print into an area of the screen that's been painted once already with space characters. I.e. I print this first:

clearscreen.
print "+------------------------------+".
print "| DISPLAY VALUE:               |".
print "+------------------------------+".

And then further down, filling it in with:

print value at (18,1).

Thus I'm writing atop spaces that are already there.

I suspect the bug arises when you write atop areas of the screen that were previously padded with empty null chars.

When it should be sending the characters:

F i x e d (space) (space) (space) (space) (space) V a r i e s

to the telnet session, instead it's probably sending the characters:

F i x e d (nullchar) (nullchar) (nullchar) (nullchar) (nullchar) V a r i e s

and the telnet terminal is interpreting the nullchars as "do nothing" operations.

If this is correct, then I know how to fix it and should have a patch available shortly.

Another idiosyncrasy I've noticed is that when kOS clears the terminal when a program ends, [...]

kOS doesn't clear the terminal when the program ends. If it's clearing, then the script is doing it.

[Wercho]

kOS doesn't clear the terminal when the program ends. If it's clearing, then the script is doing it.

I've now looked again and I realize it's just overwriting lines, not clearing them. Thanks for some great work!

[Bellicosity]

AFAIK, RT doesn't expose the targeting to a part module field or event. I'm guessing the target event activates something in the RT dll which creates the menu, so I'm pretty sure there is no way to automatically target an antenna through RT. I can't be positive though, because I use RT but have't looked at the source..

So I guess thats my solution then? Get the craft to orbit then call the appropriate DOEVENT for each antenna so I can give them a target manually.

[Dunbaratu]

The new telnet is pretty fun. One bug I've noticed is that it doesn't seem to handle PRINT...AT properly. Specifically, everything shows up in the right place on the kOS ingame terminal, but in the Putty terminal I have connected things seem to be moved randomly left or right 1-10 characters. Does anyone know why this might be happening?

http://i.imgur.com/fIjMK04.png?1

http://i.imgur.com/6dvOeOi.png?1

I figured it out and submitted the fix to the development code here:

https://github.com/KSP-KOS/KOS/pull/613

, along with another telnet terminal issue with using UP-arrow to get previous commands back when some are long multi-line commands and some are short cmmands. I don't if it will be a while before it's released, or whether it will be deemed worthy of a "quick" patch by erendrake.

[Kron]

• Fixes #389 - LOCK STEERING broken for RCS-only (no torque) ships.
  

This still seems to be an issue for vessels that rely on engine gimbaling. I'm using 0.16.0 with RSS/RO.

[Laie]

How does one meaningfully account for intake air?

The KER/MJ data displays can show how much intake air you have and how much your engines would like to have. Any attempts on my part to get that in kOS have failed so far: I can see the fuel flow of an engine, but for intakes all I get is the amount of air that's currently stored. As jets can underrun their air supply quite a bit, the stored amount tends to be near zero during the interesting phase of the flight.

[Dr_Goddard]

I found a bug in the routine for choosing boot files.

I commented on this a while ago, and i guess everyone was non-plussed.

But I found the little buggy and squashed him.

It turns out it's not true bug in the code, but a little varmint called .DS_Store which is a system file sprinkled here and there by OS X and you cannot turn it off.

The file handling override code counts the files in the archive folder which returns a number including the hidden files, then an index is created for the files beginning with "boot".

But the way the index is created, the initial count including the .DS_Store file throws the index off by 1, so the last file can't be shown in the control, and the first file is repeated.

If you are on a MAC you can duplicate this by creating a subdirectory in the scripts folder.

Another file sneaks into the folder as well, no idea where it came from, but it is a system file called .swp same issues.

The cure?

Delete the hidden files. They do practically nothing for you.

you can expose them with instructions found here:

http://ianlunn.co.uk/articles/quickly-showhide-hidden-files-mac-os-x-mavericks/

[erendrake]

I figured it out and submitted the fix to the development code here:

https://github.com/KSP-KOS/KOS/pull/613

, along with another telnet terminal issue with using UP-arrow to get previous commands back when some are long multi-line commands and some are short cmmands. I don't if it will be a while before it's released, or whether it will be deemed worthy of a "quick" patch by erendrake.

No fix is too small for a hotfix https://github.com/KSP-KOS/KOS/releases/tag/v0.16.2

This still seems to be an issue for vessels that rely on engine gimbaling. I'm using 0.16.0 with RSS/RO.

You can still use the raw controls for craft with only engine gimbaling.

How does one meaningfully account for intake air?

The KER/MJ data displays can show how much intake air you have and how much your engines would like to have. Any attempts on my part to get that in kOS have failed so far: I can see the fuel flow of an engine, but for intakes all I get is the amount of air that's currently stored. As jets can underrun their air supply quite a bit, the stored amount tends to be near zero during the interesting phase of the flight.

That is an interesting question. I dont often do spaceplanes. Is the data lacking on the consumption or the production side? I am reticent to give a simple total surplus/deficit number when we could instead make a partmodule richer.

Edit: Have you tried looking at the intake fields? it looks like airflow, intake drag, air speed and status should be available.

- - - Updated - - -

I found a bug in the routine for choosing boot files.

I commented on this a while ago, and i guess everyone was non-plussed.

But I found the little buggy and squashed him.

It turns out it's not true bug in the code, but a little varmint called .DS_Store which is a system file sprinkled here and there by OS X and you cannot turn it off.

The file handling override code counts the files in the archive folder which returns a number including the hidden files, then an index is created for the files beginning with "boot".

But the way the index is created, the initial count including the .DS_Store file throws the index off by 1, so the last file can't be shown in the control, and the first file is repeated.

If you are on a MAC you can duplicate this by creating a subdirectory in the scripts folder.

Another file sneaks into the folder as well, no idea where it came from, but it is a system file called .swp same issues.

The cure?

Delete the hidden files. They do practically nothing for you.

you can expose them with instructions found here:

http://ianlunn.co.uk/articles/quickly-showhide-hidden-files-mac-os-x-mavericks/

.DS_Store is the devil. I hates it.

Edit: Dr_Goddard, would you mind writing this up in a github issue?

Edited February 24, 2015 by erendrake

[falken]

I think I am getting something very wrong here. I'm new to all this, and I'm trying to make an automated ascent profile for my shuttle.

lock steering to up + R(0,0,90). //this keeps the vessel locked to it's original position

stage.

print "Launch Tower Detached from the orbiter.".

WAIT 1.5.

print "Counting down from 10...".

WAIT 1.0.

print "9".

WAIT 1.0.

print "8".

WAIT 1.0.

print "7".

WAIT 1.0.

print "6".

WAIT 1.0.

print "5".

WAIT 1.0.

print "4".

WAIT 0.5.

stage. //Shuttle engines stage.

print "Main Engine Start!".

WAIT 0.5.

print "2".

WAIT 1.0.

print "1, and liftoff!".

stage. //SRBs stage.

wait until altitude > 200.

lock steering to up + R(0,0,180). //roll program

print "Beginning roll program.".

wait until altitude > 1000.

lock steering to up + r(0,-75,180). //pitchover

wait until altitude > 7500.

lock steering to up + R(0,-35,180). //more pitchover

wait until altitude > 30000.

lock steering to up + R(0,-15,180). //even more pitchover

Now, it's obviously not complete, but I'm running into problems early on. The countdown and stagings work fine, but when it gets to the > 200 it makes a very half-hearted attempt at the roll program, and then it just defaults back to the 90 degree roll.

[Dr_Goddard]

I think I am getting something very wrong here. I'm new to all this, and I'm trying to make an automated ascent profile for my shuttle.

Now, it's obviously not complete, but I'm running into problems early on. The countdown and stagings work fine, but when it gets to the > 200 it makes a very half-hearted attempt at the roll program, and then it just defaults back to the 90 degree roll.

What's that old saying? "You got a hundred problems kid, but rolling ain't one of them."

I tried your script and it worked fine.

Did you turn SAS off?

That's what would happen if it was on.

Good luck!

[Dunbaratu]

That is an interesting question. I dont often do spaceplanes. Is the data lacking on the consumption or the production side? I am reticent to give a simple total surplus/deficit number when we could instead make a partmodule richer.

It's a ridiculous bug in KSP's stock code that users have complained about for literally years that SQUAD pigheadedly pretends is "correct" behavior.

Correct behavior: When you have radial symmetry enabled and attach something to the side of a rocket so the game clones several copies of it around the rocket, then attach fuel tanks under it, then engines under that, KSP is smart enough to know that each engine is connected to each fuel tank one at a time. Engine 1 sucks fuel ONLY from tank 1, engine 2 sucks fuel ONLY from tank 2, etc.

Incorrect behavior: The same is NOT true when you attach air intakes using bi-symmetry in the SPH. Although the liquidfuel gets sucked from the correct (only the ones in the same stack in-line) tanks for each engine, the air resource gets sucked globally from ALL intakes, even the intakes not attached to that engine's stack of stuff. Basically, the bug seems to be that the game is treating the air resource like a global resource that ignores part pathing - similar to how electriccharge works. All the air gets pooled together into one common resource, which then is NOT doled out equally to all engines, but rather all of it is given to engine 1 and then whatever is leftover after that is given to engine 2. The effect is that once you get into thin enough atmosphere that the intakes don't GLOBALLY have enough air intake to satisfy GLOBALLY all the engine's demands for it, the starvation does not happen equally on left and right sides, because engine 1 starts stealing air from engine 2's air intake in a way that should be physically impossible. Thus engine 2 flames out way before engine 1 does, and your plane spins way out of control.

Lots of people have defended this ridiculous arrangement by pretending that "well it's okay because flameout isn't uniform anyway and the engines won't all flame out together anyway", which ignores the crux of the problem that engine 1 is consuming air it's not even supposed to be connected to in the first place, which is the cause of engine 2 getting starved of air prematurely. In a case where realistically, you're talking about maybe a difference between one engine operating at 10% power and the other at 0% as they flame out inconsistently, you now have one engine operating at 20% and the other at 0%. It's not JUST that one engine gets starved, but that the other one gets TOO MUCH, creating this large imbalance that spins you out of control rather than both of them getting worse and worse so when one flames out the other isn't very powerful either.

Squad refuses to fix this known problem, and there's a workaround where you can attach engines without symmetry turned on and it won't cross feed their air intakes together then, provided you can be exact enough to make them have symmetry by hand, and that's hard.

People making spaceplanes are therefore deeply concerned about detecting when flameout is about to occur and they want to kill the throttle JUST BEFORE it starts to happen. Thus the desire to be able to read what the current intake levels are.

[dsonbill]

Steve Madding/Erendrake/kOS Team:

I'm playing with kOS code, and I've come across the FunctionManager. Now, I'd like to add my own functions to kOS, but it seems I also have to add the opcode directly, and I'm not exactly sure how to inject that without totally modifying kOS. I'm going to try some more reflection, but if anyone would like to point me in a more directed... direction, I would appreciate it

Feel free to point me to a place where this is already explained, or to just look for it myself. I understand that my inquiries can sometimes be a bit... daunting?

EDIT: Well, I've noticed (right after posting, as is usual) how you did it in RemoteTechInterpreter, and I'm guessing this is the way it's to be done for now?

I don't have my own interpreter set up for the project I'm doing, but it shouldn't be too hard to pull off.

Edited February 25, 2015 by dsonbill
Opcode, not bytecode >.>

[Starwhip]

I think I am getting something very wrong here. I'm new to all this, and I'm trying to make an automated ascent profile for my shuttle.

Now, it's obviously not complete, but I'm running into problems early on. The countdown and stagings work fine, but when it gets to the > 200 it makes a very half-hearted attempt at the roll program, and then it just defaults back to the 90 degree roll.

What's that old saying? "You got a hundred problems kid, but rolling ain't one of them."

I tried your script and it worked fine.

Did you turn SAS off?

That's what would happen if it was on.

Good luck!

Yeah, that sounds like SAS was on. Code looks fine to me.

You gotta trust your code! Turn off that SAS for once.

[Wercho]

Turn off that SAS for once.

Or better yet, throw this line in the appropriate spot so you don't even have to remember.

SET sas TO false.

[falken]

Hi, I'm actually not running SAS at all.

I thought it was because my design uses gimbal auto trim, but I made a simple mk1 cockpit, 2 fuel tanks and an lvt-45, and whilst it rolled to the 180 degrees position, it immediately returned to a 90 deg roll.

Is there any other ways I can induce my shuttle's roll and pitch programs?

e: THIS IS EMBARRASSING. I was assuming that + R(0,0,180) would be like putting 90, 90, 180 into MJ's SURF mode. 180 in SURF is 90 in kOS...

Edited February 25, 2015 by falken

[falken]

I'm slowly getting the hang of this.

lock steering to up + R(0,0,180).

stage.

print "Launch Tower Detached from the orbiter.".

WAIT 1.5.

print "Counting down from 10...".

WAIT 1.0.

print "9".

WAIT 1.0.

print "8".

WAIT 1.0.

print "7".

WAIT 1.0.

print "6".

WAIT 1.0.

print "5".

WAIT 1.0.

print "4".

WAIT 0.5.

stage.

print "Main Engine Start!".

WAIT 0.5.

print "2".

WAIT 1.0.

print "1, and liftoff!".

stage.

wait until altitude > 100.

lock steering to up + R(0,0,90).

print "Beginning roll program.".

wait until altitude > 500.

lock steering to up + r(0,-20,90).

wait until altitude > 7000.

lock steering to up + R(0,-50,90).

WHEN STAGE:SOLIDFUEL < 324 THEN {

STAGE.

print "SRB Separation confirmed.".

}

wait until altitude > 25000.

lock steering to up + R(0,-70,90).

wait until altitude > 40000.

lock steering to up + R(0,-75,90).

wait until altitude > 55000.

lock steering to up + R(0,-75,270).

wait until altitude > 75000.

lock steering to up +R(0,-90,270).

Now, everything works beautifully up until it's time for the roll from inverted to upright at 55000m. It does the roll, but very slowly, and will sort end up pointing the nose like 30 degrees off from prograde.

I've got the main engines and OMS set to full auto trim level, but I think the lack of SRBs is making this difficult to handle. I've tried it with RCS enabled too, with no joy. I should point out that MJ's surf mode does the roll flawlessly (although kOS handles the pitchover maneuvers much smoother).

[Dave7]

wait until altitude > 75000.

lock steering to up +R(0,-90,270).

Is there a space missing between the + and R? Don't know if that's messing anything up or not.

[Dunbaratu]

It does the roll, but very slowly

The very first thing to look at to see if the culprit is kOS or something else is to look at this little indicator in the corner of the screen:

If you see it being pushed to the limits during the part where you want it to roll, and it's still not rolling at all, then kOS is *trying* to roll but some important facet of the ship engineering isn't being enabled (i.e. RCS is off, or torque wheels are starved of power, or thrust vectoring is off, etc.)

On the other hand if you see that it's NOT being pushed to the limits, then kOS is piloting it incorrectly and maybe there's a bug report to be made.

[Wercho]

The addition of rotations is pretty confusing to me, but with the inversion it sounds like you are running into a problem with order of operations for the rotation. You could try switching the '+' to '*' (which AFAIK perform the same operation on directions). Check out the documentation on directions and maybe you'll understand order of operations better than I do.

For these situations, I use the heading function instead because I understand it, and combine it with lookdirup if needed. So I would write your code as :

wait until altitude > 100.
lock steering to heading(90,90). //90 heading is east, 90 pitch is up
print "Beginning roll program.".

wait until altitude > 500.
lock steering to heading(90,70). //still east, now 70deg above horizon
...
etc.
...

wait until altitude > 55000.
lock steering to lookdirup(heading(90,15):forevector, (-1)*ship:up:forevector). //gets the "point at" direction as east + 15deg above horizon, and points the top of the ship at the opposite of the up vector
...

(Code may have typos)

You can totally do things the way you are doing them, I just don't understand direction math well enough to do it.

[falken]

Yeah, that code isn't working for me.

[Wercho]

I just noticed that kos puts a note in the debug log whenever you bind a control using the raw ship controls. The notes are "kOS: FlightControl Binding" and "kOS: FlightControl Bound". When using them in a PID loop, this results in large amount of log spam, so I might suggest taking out those notes. (I assume they were debug notes). It's not a big deal, though.

[Ziw]

Question/Suggestion:

Is there a way to list and identify vessels around my current ship, at least the ones in physics range? I know I can always find a vessel by name, but I want to write a script that is a bit more flexible.

EDIT: Will LIST TARGETS command return list of all vessels or just vessels in SOI, or what? Documentation is a bit vague and I cannot test right now, just brainstorming while I have a moment.

Also I believe that there is absolutely no mention of special file called "boot.ks" anywhere in official documentation, I only was able to collect bits and pieces of information on it by googling.

Edited February 26, 2015 by Ziw

[erendrake]

I just noticed that kos puts a note in the debug log whenever you bind a control using the raw ship controls. The notes are "kOS: FlightControl Binding" and "kOS: FlightControl Bound". When using them in a PID loop, this results in large amount of log spam, so I might suggest taking out those notes. (I assume they were debug notes). It's not a big deal, though.

Are you also getting unbound too? or are you just seeing bind,bind,bind?

Question/Suggestion:

Is there a way to list and identify vessels around my current ship, at least the ones in physics range? I know I can always find a vessel by name, but I want to write a script that is a bit more flexible.

EDIT: Will LIST TARGETS command return list of all vessels or just vessels in SOI, or what? Documentation is a bit vague and I cannot test right now, just brainstorming while I have a moment.

Also I believe that there is absolutely no mention of special file called "boot.ks" anywhere in official documentation, I only was able to collect bits and pieces of information on it by googling.

LIST TARGETS is all craft. Adding a "LOADED" suffix to each vessel wouldnt be hard.

The boot stuff has no documentation because we added it before we required docs for PRs and Steven and I dont use it so it has kinda languished.

Edited February 26, 2015 by erendrake