[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Ziw]

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.

Thank you. I think the way that LIST TARGETS works (e.g. returns list of all vessels) should be clarified in documentation.

To Dr. Goddard:

I remember you were struggling with getting different boot scripts to work. I sketched a quick solution, but it requires some workarounds (e.g. tagging parts). See a rough example of the universal boot.ks script below.

//bootloader


print "BOOT.KS: Checking for rootpart tag for boot script".
set bootLoaderFilename to SHIP:ROOTPART:TAG.


if bootLoaderFilename <> 0
{
    list files in fileList.
    for i in fileList
    {
        if i = bootLoaderFilename
        {
            print "Running bootloader: " + bootLoaderFilename.


            delete "dummy.ks" from 0.

            log "run " + bootLoaderFilename + "." to "dummy.ks".

            run dummy.

        }
    }
}

To Developers:

I was really surprised by this career limits change below, I had to spend extra 2mils in my career save in order to get my robotic scripts to work (because InfernalRobotics utilizes DOACTION for part movement) Althought I understand your intentions, I find it a bit unfair as IR does not require you to have custom actiongroups unlocked to function.

• 
  In order to be allowed to execute the PartModule :DOACTION method, either your VAB or your SPH must be upgraded to the point where it will allow access to custom action groups. This is because otherwise the :DOACTION method would be a backdoor “cheat†past the restricted access to the action group feaures of various PartModules that the game is meant to have.
  

Edited February 26, 2015 by Ziw

[Wercho]

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

I get "unbound" if I do something like "SET ship:control:neutralize to true." but since my PID loop just updates the control every round, that is showing up many times. It only puts unbound into the log when the script stops controlling things.

Pseudocode:

UNTIL end {
WAIT 0.001.
Calculate PID control.
SET ship:control:pitch TO x. //adds "binding" note to log every time the loop cycles.
}

//control done
SET ship:control:neutralize TO true. //adds unbound to log

[Laie]

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.

It's not quite as bad: you can place whole units of (intake+engine) with symmetry and things will work out nicely. Or prepare one wing, then (re)place it with symmetry and you have two symmetric wings with identical air distribution.

But yes; people are *very* interested in squeezing the most out of their engines. If the MJ/KER figures are to be trusted, jets will work nicely until they're down to pretty exactly 10% of what they'd like to have. There's a design school that mandates an odd number of engines, with one dead center. When all others are out and that last engine gets air from all intakes, it can/will still produce meaningful thrust at 60km. If you can set the throttle just right, that is: settings of 0.1-0.05 are hard to do for keyboard users.

I've devised all kinds of functions that approximate the perfect throttle setting, but they're rather arbitrary affairs.

[Dunbaratu]

Thank you. I think the way that LIST TARGETS works (e.g. returns list of all vessels) should be clarified in documentation.

I personally hate the name of it. It's a naming choice going back all the way to Nivekk. The name implies that:

(A) The only reason for getting a list of vessels is for the sake of setting a target (which is false), and

( The only things you can target are vessels (which is false - there's bodies and docking ports).

It's just a list of all the vessels in the campaign save. That's all. The name of it is terribly misleading.

I was really surprised by this career limits change below, I had to spend extra 2mils in my career save in order to get my robotic scripts to work (because InfernalRobotics utilizes DOACTION for part movement) Althought I understand your intentions, I find it a bit unfair as IR does not require you to have custom actiongroups unlocked to function.

• 
  In order to be allowed to execute the PartModule :DOACTION method, either your VAB or your SPH must be upgraded to the point where it will allow access to custom action groups. This is because otherwise the :DOACTION method would be a backdoor “cheat†past the restricted access to the action group feaures of various PartModules that the game is meant to have.
  

I don't actually like this rule either and I'm the one that implemented it. I just don't like it when mods make things easier than stock in ways that aren't just fixing stock bugs or stock annoying missing bits (i.e. alarm clock, for example, makes things easier than stock, but by basically fixing a missing feature that stock needs. kerbal engineer makes things easier, but by un-hiding information that stock has no right to be hiding from the player. In-flight waypoints just un-hides information that stock has no right to be hiding from the player, and so on.)

But this is different. Allowing a back-door way to enable a feature that stock is *deliberately disabling* is something else entirely, and I don't feel comfortable doing it. Ideally, what I'd like to see is to make the stock game stop using this silly feature. The custom action groups are not in any way related to how nice your VAB is, thematically. They're part of how your flight controls can pilot the ship, not part of how you engineer building it.

But nevertheless I'm reluctant to change it unless stock is changed, even though I think the change would make perfect sense, the change should happen in STOCK, not in a mod.

- - - Updated - - -

Incidentally, the claim that IR allows you to call its action groups without an upgraded VAB isn't *quite* true. It's more accurate to say that IR has two different user interfaces to access the part movement, ONE of which is the action groups and THAT interface is still restricted by VAB level just like in kOS.

It's just that IR also provides a second way to move the parts that kOS can't see, using IR's own GUI window that is entirely outside the action group system altogether.

I'm waffling on this, however, because really you still *CAN* use the IR action groups from the stock action groups, its just stupid and weird (i.e. turn the brakes on to slide the slider up, and turn the lights on to slide the slider down.) So the dividing line isn't "can you call the action" but rather "can you call it from Ag1, ag2, ag3, etc.")

And come to think of it.... I don't think we use the VAB level as a restriction against using AG1, AG2, AG3, etc. We just rely on the fact that you can't BUILD anything into those action groups anyway without the VAB interface allowing it.

[Ziw]

As I said, I understand your intentions and mostly agree. Just a little but frustrated that IR's mechanics are not accessible outside of their GUI without action groups. But the same goes for RT antenna targeting for example - you cannot target the RT antennas via KOS script (as discovered by someone earlier in the thread), best you can do is open the GUI.

Only hope for early robotics would be asking sirkut to add KSPEvents to robotic parts mimicking "move +" and "move -" actions. Or even implement proper iterative movements - eg "move +" button to move for 1 unit set in Min Increment field.

[Laie]

(querying intake air)

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

Huh? I just tried part:airflow and so on, to no avail. How do I get a list of everything that might be queryable about a given part?

Right now I only know about :intakeair, which only shows the stored amount and as such isn't really helping.

---

also, may I inquire about issues #549/#550? If these are non-issues, I'd like to know what I fail to grasp.

Edited February 27, 2015 by Laie

[erendrake]

Huh? I just tried part:airflow and so on, to no avail. How do I get a list of everything that might be queryable about a given part?

Right now I only know about :intakeair, which only shows the stored amount and as such isn't really helping.

---

also, may I inquire about issues #549/#550? If these are non-issues, I'd like to know what I fail to grasp.

you can directly interrogate any part for the contents of the right click menu.

http://ksp-kos.github.io/KOS_DOC/general/parts_and_partmodules.html#exploring-what-s-there-to-find-field-event-action-names

I believe there is more available for intakes if you use this.

* Flow

* Drag

* Air Speed

#549/#550 are features that have been asked for. I dont know if there is a simple work around for them and I have been thinking about how to best resolve the request.

Edited February 27, 2015 by erendrake

[Ziw]

I am experimenting with running multiple cores on one ship and trying to find a way, apart from obvious tagging, from within a script to locate a part of the ship that is the active core itself? I want to use this to save bootloader script name in the each core's tag to be executed on this core whenever the ship loads from rails.

All I can think of requires some basic string operations, which are not yet present in KOS.

Maybe something like "list cpu" command which behaves like "list parts" command, but returns the list of all cores in physics range with some indication of active cores (almost the same functionality you get on a welcome screen of a telnet terminal).

Edited February 27, 2015 by Ziw

[erendrake]

I personally hate the name of it. It's a naming choice going back all the way to Nivekk. The name implies that:

(A) The only reason for getting a list of vessels is for the sake of setting a target (which is false), and

( The only things you can target are vessels (which is false - there's bodies and docking ports).

It's just a list of all the vessels in the campaign save. That's all. The name of it is terribly misleading.

Lets change it then, im sure we will get some grumbling but if we deprecate it and remove it a few releases later im sure we can come up with better names.

sounds like we have two pieces of state we are trying to get.

All of the "craft" ( currently TARGETS )

* TRACKABLES ( meaning its in the tracking station list )

* CONTACTS ( Like Radar contacts? )

* .... crap this list is crappy to name

The ability to query a craft to see if its loaded or not

* TARGET:LOADED

* TARGET:INRANGE

* TARGET:???????

Help us out people i am having a lack of imagination

- - - Updated - - -

I am experimenting with running multiple cores on one ship and trying to find a way, apart from obvious tagging, from within a script to locate a part of the ship that is the active core itself? I want to use this to save bootloader script name in the each core's tag to be executed on this core whenever the ship loads from rails.

All I can think of requires some basic string operations, which are not yet present in KOS.

Maybe something like "list cpu" command which behaves like "list parts" command, but returns the list of all cores in physics range with some indication of active cores (almost the same functionality you get on a welcome screen of a telnet terminal).

We were just talking about this earlier in the week. would you mind adding this as a Github issue? This makes sense as something you should be able to do.

[Sirplentifus]

Awesome mod!

I've been using it mostly to make controllers. My latest is an attitude hold controller, and it works quite nicelly.

However, I've been wanting to make a wing leveler, but I can't find out how to get my roll angle. The values given by SHIP:FACING are obtained using a weird, barelly explained reference frame which uses propper euler angles. This two situations together make it almost impossible for me to figure out the roll angle of my aircraft.

I wish there was an angle system like (heading, pitch, bank), aka nautical angles. It would be awesome if it was impelemented. Does anyone know a workaround this problem? I would appreciate it a lot.

Thanks for this cool mod!

[Dunbaratu]

However, I've been wanting to make a wing leveler, but I can't find out how to get my roll angle. The values given by SHIP:FACING are obtained using a weird, barelly explained reference frame which uses propper euler angles. This two situations together make it almost impossible for me to figure out the roll angle of my aircraft.

This is my really long explanation of the angles system. I turned on he microphone and just started talking through stuff. An example of bank angle happens towards the end about 22-23 minutes in, but it wont make much sense if you skip ahead to it without watching the earlier bits.

[Ziw]

Lets change it then, im sure we will get some grumbling but if we deprecate it and remove it a few releases later im sure we can come up with better names.

sounds like we have two pieces of state we are trying to get.

All of the "craft" ( currently TARGETS )

* TRACKABLES ( meaning its in the tracking station list )

* CONTACTS ( Like Radar contacts? )

* .... crap this list is crappy to name

The ability to query a craft to see if its loaded or not

* TARGET:LOADED

* TARGET:INRANGE

* TARGET:???????

Help us out people i am having a lack of imagination

If we are discussing the change of the name only (without changing how it works), then why not just LIST VESSELS? It makes sense as it returns a list of elements of type Vessel.

We were just talking about this earlier in the week. would you mind adding this as a Github issue? This makes sense as something you should be able to do.

Done, issue #623

[Sirplentifus]

This is my really long explanation of the angles system. I turned on he microphone and just started talking through stuff. An example of bank angle happens towards the end about 22-23 minutes in, but it wont make much sense if you skip ahead to it without watching the earlier bits.

Thanks for that video. With what I learned from your video, I managed to calculare the vector which always points to the right of the projection of SHIP:FOREVECTOR onto the horizon plane. Here it is in the pictures (Called Right). Its angle with SHIP:STARVECTOR (called Right wing in the pictures) is the bank angle!

You can see in the pictures the math I used to calculate it. A side effect of the method used to calculate it is that the Right vector becomes smaller as pitch angle increases. And unfortunately, the kOS function for angles between vectors makes no distinction between positive and negative vectors, so I'm going to use the arcsin of the magnitude of the cross product between those vectors divided by their respective magnitudes.

Thank you for helping!

EDIT: I forgot to actually post the image: http://imgur.com/RAPhfxu , http://imgur.com/B4x0Taf

And here are some pictures showing that I did manage to calculate the bank angle from these vectors: http://imgur.com/a/TkmY5#0

Edited February 28, 2015 by Sirplentifus

[falken]

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.

Hi Wercho, I tried using this with a basic setup of Mk1-2 pod and a fuel tank with engine, and with the "lock steering to lookdirup(heading(90,15):forevector, (-1)*ship:up:forevector)." it would roll wildly from one extreme to the other.

Is there any other way I can manage a roll from inverted to heads up position?

[Wercho]

Hi Wercho, I tried using this with a basic setup of Mk1-2 pod and a fuel tank with engine, and with the "lock steering to lookdirup(heading(90,15):forevector, (-1)*ship:up:forevector)." it would roll wildly from one extreme to the other.

Is there any other way I can manage a roll from inverted to heads up position?

Hmm, after I wrote the code above it occured to me that the heading function might work straight, using the opposite heading and a pitch > 90 degrees. I just tried it (though not in atmo). This produced a smooth roll, with only a couple of degrees of wobble:

LOCK steering to heading(90,15). //east, 15 deg above horizon
WAIT 10.
LOCK steering to heading(270,165). //west, pitched all the way past vertical to inverted 15 deg above horizon
WAIT 5.

[falken]

I tried this with a line of code to fly straight up to 10k before a turn. The entire way up it rotates left to right constantly.

LOCK steering to heading(90,90).

wait until altitude > 10000.

LOCK steering to heading(90,15). //east, 15 deg above horizon

WAIT 10.

LOCK steering to heading(270,165). //west, pitched all the way past vertical to inverted 15 deg above horizon

WAIT 5.

e: I am using FAR if that could be causing issues.

e2: I think the reason the original kos code of "lock steering to up + R(0,-75,270)." is that it is just like pressing Q or E on the keyboard. This would be fine for a conventional rocket, but as a shuttle is largely assymetrical, the pitch is not compensated for, so I need to figure out a different way to do this.

I can however set MJ's SMART ASS SURF mode to 90head, 7 pitch, 0 roll prior to launch and have the program end at 55000m, and MJ would take over and complete the roll for me. Cheaty? Yes, but it gets the job done.

Edited March 1, 2015 by falken

[kcs123]

If your plane is rolling unstable (check FAR graph and analysis) then kOS should have trouble to maintain stability.

At 10km you need to go above 1Mach to maintain craft stability and in transition area almost all craft will have some kind of problems.

Try with slightly dehadrial wings, small vertical surfaces on wingtips and larger vertical surface on tail and/or vertical surfaces further back from main wing helps with roll stability. Check links in signature, but keep in mind that those examples were for researching craft limits. In most cases you will not need such high wingspan, but I have researching possibilities with those designs.

[falken]

kcs123, it's because it's a space shuttle with external tank on the belly, it rolls a bit funny. MJ's smart ass surf mode compensates well enough, kOS less so.

A quick question, what command would I use to activate an action group? I want my program to unfurl solar panels and antennae at set times.

e: Also, someone tell me I'm not crazy. I made a conventional rocket, and it stages when I still have a third of the liquid fuel left in the 1st stage tank. I have no idea why.

wait until altitude > 8500.

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

WHEN STAGE:LIQUIDFUEL < 0.001 THEN {

STAGE.

print "FIRST STAGE SEPARATION.".

}

Edited March 1, 2015 by falken

[Ziw]

I just realised that RequiredPower consumed by CPU depends on whether or not you are using Archive

If you switch to Archive CPU consumes 0.2 EC/sec, if you switch to local volume it consumes 0.02 or 0.04 depending on CPU size. Is that an intended behaviour?

Also please see issue #632

Boot file selection bug (simple fix inside).

Edited March 2, 2015 by Ziw

[erendrake]

I just realised that RequiredPower consumed by CPU depends on whether or not you are using Archive

If you switch to Archive CPU consumes 0.2 EC/sec, if you switch to local volume it consumes 0.02 or 0.04 depending on CPU size. Is that an intended behaviour?

It is intended, the idea being that it should take more power to communicate to the archive back @KSC then it does to pull files off of the local volume.

- - - Updated - - -

kcs123, it's because it's a space shuttle with external tank on the belly, it rolls a bit funny. MJ's smart ass surf mode compensates well enough, kOS less so.

Our LOCK STEERING is for basic craft. More advanced craft should use the raw controls.

http://ksp-kos.github.io/KOS_DOC/commands/flight/raw.html?highlight=raw

A quick question, what command would I use to activate an action group? I want my program to unfurl solar panels and antennae at set times.

http://ksp-kos.github.io/KOS_DOC/bindings.html?highlight=ag1#boolean-toggle-fields

e: Also, someone tell me I'm not crazy. I made a conventional rocket, and it stages when I still have a third of the liquid fuel left in the 1st stage tank. I have no idea why.

we currently are tracking down a bug in the new way we are aggregating resources. https://github.com/KSP-KOS/KOS/issues/513.

[falken]

Thanks, I will look into that.

[Alturen]

This is an excellent mod, and in keeping with the spirit of the game. Thanks!

[Ziw]

This is an excellent mod, and in keeping with the spirit of the game. Thanks!

I'd say that trio of RemoteTech + IR + KOS mods make the game so much deeper. It's like a sandbox within a sandbox.

[Wercho]

Should the OP and Kerbalstuff (and therefore CKAN) be updated to 0.16.2? I just saw that there were updates on Github, but not on those two spots.

[erendrake]

Should the OP and Kerbalstuff (and therefore CKAN) be updated to 0.16.2? I just saw that there were updates on Github, but not on those two spots.

it should be, I totally forgot about it my bad