[1.3] kOS Scriptable Autopilot System v1.1.3.0

[TDW]

Is it possible to make the part facing give this? The direction it currently gives is 90deg from the direction of thrust (for the engines I tested), but as rotation is done about the vessel facing i can't think of a way to get it in line.

quick test script, identifies an engine in stage 2 and draws its facing.

SET vec TO vecdraw().
UNTIL 1 > 2 {
List engines in foo.
for eng in foo {
 IF eng:STAGE = 2 {
  SET dir to eng:facing.
 }.
}.
SET vec:VEC TO dir:vector.
SET vec:SCALE TO 5.
SET vec:SHOW TO true.
}.

Edit: oops code was wrong, forgot to loop the list engines.

Can you include a screenshot image of what that vecdraw is looking like when you run this code?

Ok been away form the PC for a while.

Worth noting that this is with KSP 0.24.2 and kOS 0.14 but I doubt that it will make a difference in this. If you feel it would i will be happy to take more pics when i get round to updating, which will probably be this weekend.

Image of "rocket" with the above script.

After adding R(90,0,0) to the facing you get this:

Which is far more usable. However If the engine is rotated as is often the case when using multiple boosters (or symmetry) you get this (without the rotation):

But because the rotation is applied around the control parts co-ordinate system (I think) and not the engine parts co-ordinates applying the same rotation does this:

Another possible case (possibly the main case) is engines that don't point in the same direction as the vessel in which case you get this (without rotation):

With rotation:

EDIT: The quoted script has been modified to detect engines in stage 0.

I believe the facing being reported by KSP is the "front" facing in the CAD package use to make the mesh and that most engine parts are made upright (engine bell on bottom face) because it makes scene to the modeller, with only control parts being made with much thought to what KSP would report as the facing.

Any way, this means that in order to apply the correct rotation to the part you must work out its orientation relative to the control part (and if you know that querying the part:facing of anything other than a control part is moot). And if the engine rotates (using IR parts) then it is impossible to calculate the new direction of thrust.

Is there a way to rotate a vector about the co-ordinate system of the part that the facing is being take from and not the one of the current control part? That way while the player would have to work out the orientation of the mesh within the CAD package the rotation would always be the same for that part no matter how it was placed.

I will point out that I do have a workaround for this but it is not very nice, it involves part clipping a sepatron between the tank and engine and then querying the facing of the sepatron instead:

Note the 0 fuel in the sepatron - really not good if you accidentally stage it wile it is full.

Edited October 14, 2014 by TDW
Google docs image hosting issues

[Dunbaratu]

Spoiler=Image heavy

This section of the post contains no images, making it almost impossible to follow what you're talking about. I think the spoiler tag is hindering the images.

[TDW]

This section of the post contains no images, making it almost impossible to follow what you're talking about. I think the spoiler tag is hindering the images.

Oops: They are on google docs trying to work out permissions now.

EDIT: Fixed (I think) apparently you cant use right click "copy image URL" for google docs:rolleyes:

Edited October 14, 2014 by TDW

[Dunbaratu]

Oops: They are on google docs trying to work out permissions now.

EDIT: Fixed (I think) apparently you cant use right click "copy image URL" for google docs:rolleyes:

Okay now that I can see what you're talking about the problem is understandable.

[Dunbaratu]

I seem to recall from another mod I was making that when you model parts in the Unity editor you need to make them such that the rocket-up direction is the +Y axis, but that for steering purposes in game, KSP refers to rotations that presume the initial starting point is the +Z axis... It may be this difference that is the problem. Perhaps all we have to do is that for part transforms, make their default roation the +y rather than the +z and it will come out right... I'll have to see, but it will take a few days to get to diagnosing this further.

[Trewor007]

Hi!

I got a very simple "smart" missile script written. And I'm wondering is there a possibility to make a program witch:

a) loads itself to the missile probe core.

does not affect plane steering.

c) still function after detaching from plane?

[erendrake]

Hi!

I got a very simple "smart" missile script written. And I'm wondering is there a possibility to make a program witch:

a) loads itself to the missile probe core.

does not affect plane steering.

c) still function after detaching from plane?

you should be able to add a kOS processor to the missile probe core. It could have a boot file for these cores that is a guidance computer that only kicks in when you tell it to (eg when the mass gets low enough to know it is detached).

[Trewor007]

Thanks for the tip. I just need some info on the targeting. after detaching my missile is no longer pointing itself for the target is there something like "set target to current:ship:target" command?

Edited October 16, 2014 by Trewor007

[tasuit]

Thanks for the tip. I just need some info on the targeting. after detaching my missile is no longer pointing itself for the target is there something like "set target to current:ship:target" command?

I'm not sure, but I think you could use vectors to target your ship. Get the position of your ship, and subtract it with the position of your rocket, this gives you a directional vector pointing at your ship. Don't know if this works, or is possible, but thats probably the first thing i would try

[madlemur]

Thanks for the tip. I just need some info on the targeting. after detaching my missile is no longer pointing itself for the target is there something like "set target to current:ship:target" command?

Well... You should be able to get the parent vessel by name. The problem is that I can't find any documentation (or easily found reference in the source) for getting the target of a different vessel.

Along with erendrake's mass check, you could also check various part counts (only one engine? I've been launched!)

Hmmm... We need a decent way for cores to talk to one another. I suppose you could do some log file trickery to cause a file to appear in the volume for the missile, which could include a quick script to set the target and run its own guidance program. Once we get access to the right-click actions, you could even have the missile decouple and launch itself!

Quick question for erendrake and/or Steve Mading: If a script tries to get a handle on a vessel by name, and there are a number of vessels with the same name, does it return a list?

edit: Here's a thought! Have the missile turn itself off (or better, have a non-missile core power off all the missiles). Then when you want to fire the missile, build the aforementioned "log file" as a boot file for the missile and power it on. The missile will read in the targeting info from its boot file, and then go on to run its guidance routine.

Edited October 16, 2014 by madlemur

[erendrake]

Well... You should be able to get the parent vessel by name. The problem is that I can't find any documentation (or easily found reference in the source) for getting the target of a different vessel.

Along with erendrake's mass check, you could also check various part counts (only one engine? I've been launched!)

Hmmm... We need a decent way for cores to talk to one another. I suppose you could do some log file trickery to cause a file to appear in the volume for the missile, which could include a quick script to set the target and run its own guidance program. Once we get access to the right-click actions, you could even have the missile decouple and launch itself!

Quick question for erendrake and/or Steve Mading: If a script tries to get a handle on a vessel by name, and there are a number of vessels with the same name, does it return a list?

edit: Here's a thought! Have the missile turn itself off (or better, have a non-missile core power off all the missiles). Then when you want to fire the missile, build the aforementioned "log file" as a boot file for the missile and power it on. The missile will read in the targeting info from its boot file, and then go on to run its guidance routine.

I agree, we do need a nice way to send information between cores. Right now targeting a vessel by name gets the "first" instance of that name. with no real implied order.

[Trewor007]

Well... You should be able to get the parent vessel by name. The problem is that I can't find any documentation (or easily found reference in the source) for getting the target of a different vessel.

Along with erendrake's mass check, you could also check various part counts (only one engine? I've been launched!)

Hmmm... We need a decent way for cores to talk to one another. I suppose you could do some log file trickery to cause a file to appear in the volume for the missile, which could include a quick script to set the target and run its own guidance program. Once we get access to the right-click actions, you could even have the missile decouple and launch itself!

Quick question for erendrake and/or Steve Mading: If a script tries to get a handle on a vessel by name, and there are a number of vessels with the same name, does it return a list?

edit: Here's a thought! Have the missile turn itself off (or better, have a non-missile core power off all the missiles). Then when you want to fire the missile, build the aforementioned "log file" as a boot file for the missile and power it on. The missile will read in the targeting info from its boot file, and then go on to run its guidance routine.

I kinda new to kOS so for the moment "log file trickery" is out of my reach. I guess waiting for the right click actions is the only option for me. Maybe then ill be able to save a number of targets (3) to a list, and than open the cargo door and fire one missile when my plane be close to one of the targets. But that's not my level for the moment i just learned today about the existence of a boot file

[Dunbaratu]

I agree, we do need a nice way to send information between cores.

Marianoapp had added some code to the project that looks like it's designed to allow one SCS unit to tell another SCS unit to run a command on it, but it's not really tested or done. If you want to see it, look at src/Interprocessor.

I'd prefer it if instead of actually directly having control to run something on the other SCS unit, there was just a messaging system in place to send/get messages between CPUs and let the CPUs decide what to do about the messages.

[Laie]

How do I identify a particular part?

I want to set "control from" a forward-facing docking port. Any port will do as long as it's facing in the right direction. I built a ship with a single forward-facing port and it's facing differs noticably from ship:facing -- so it's not as simple as I hoped. How do I find a suitable port on a more complex vessel?

Edited October 17, 2014 by Laie

[Cairan]

I don't think you can set the thrustlimit in kerbscript. You might consider one of the throttle plugins that allows you to use action groups to control the throttles. Of course, then you're limited to the 10 default action groups (until/unless someone adds AGX support to kOS)...

It would be nice to set :THRUSTLIMIT because that would enable to balance out parallel stacks, similar to the STS... just throttle up or down the appropriate engines to balance out the torque vector. I'm doing that manually at the time, but there is a way to automate this.

[Laie]

It would be nice to set :THRUSTLIMIT

That works already. Just try it.

[TDW]

It would be nice to set :THRUSTLIMIT because that would enable to balance out parallel stacks, similar to the STS... just throttle up or down the appropriate engines to balance out the torque vector. I'm doing that manually at the time, but there is a way to automate this.

Read the post after the one you quoted (and the one 2 above it)

They include a working script that throttles individual engines and a craft file for a demo craft that uses them. It's part of a much larger script i was working on but have stalled because it I need to re-write it (that or set a silly config:ipu). But that fragment should still work.

Engines in that script are identified by putting them in their own stage, however you could identify them by ISP (throttle back the engines with the lowest ISP first, during launch to stay below max q) or use any other engine/part suffix to identify them.

[madlemur]

It would be nice to set :THRUSTLIMIT because that would enable to balance out parallel stacks, similar to the STS... just throttle up or down the appropriate engines to balance out the torque vector. I'm doing that manually at the time, but there is a way to automate this.

I was wrong! Mea cupla! Mea Maxi Culpa!

I've edited my original misinformation to make it clear that I was wrong. Alternatively, you could ask my wife. She'll tell you I was wrong. About anything...

[Cairan]

Read the post after the one you quoted (and the one 2 above it)

They include a working script that throttles individual engines and a craft file for a demo craft that uses them. It's part of a much larger script i was working on but have stalled because it I need to re-write it (that or set a silly config:ipu). But that fragment should still work.

Engines in that script are identified by putting them in their own stage, however you could identify them by ISP (throttle back the engines with the lowest ISP first, during launch to stay below max q) or use any other engine/part suffix to identify them.

Aehm... Well, sorry then. I was looking for a confirmation about the info that's present in the mod's documentation:

http://ksp-kos.github.io/KOS_DOC/structure/engine/index.html

Suffix Type Get Set Description

[...]

:THRUSTLIMIT Number yes no If this an engine with a thrust limiter (tweakable) enabled, what percentage is it limited to?

So yeah, it's everybody's fault Except madlemur's wife. She's right on everything! *runs*

[Dunbaratu]

Just a bit of teaser to tide people over while we keep plugging away at kOS v0.15 :

The two mods being used in the example are LaserDist and Infernal Robotics, but the principle is that it generically works on any mod provided you spend some time at the terminal printing out various exploratory fields to find out what the mod calls things:

[Drew Kerman]

Oh man I'm so happy that I won't have to "cheat" by disabling RT signal delay so I can perform science from the probe I plan to drop into Duna's atmosphere Great work, Steven and erendrake!! This is going to make kOS soooo powerful...

[Cairan]

I've been searching in the documentation ... I'm writing a little bootloader of sorts to load all files in the Archive volume into Volume 1 (it's a quick test for a later idea I've got).

This code fails, even though programmatically it should work, but obviously there is a feature I haven't caught on... Granted I'm biased by years of Python and PHP coding, but unless I am mistaken, kOS doesn't substitute "prog" with the actual content of the "prog" variable from the FOR... loop.

// Bootloader
// This script will copy every program in the Archive into Volume 1.
RENAME VOLUME 1 TO Kerbston.
SWITCH TO Archive.
LIST FILES IN ls.
FOR prog IN ls {
  PRINT "Loading " + prog.
  COPY prog TO Kerbston.
}.
SWITCH TO Kerbston.
PRINT "Loaded progs:".
LIST FILES.

[Trewor007]

I've been searching in the documentation ... I'm writing a little bootloader of sorts to load all files in the Archive volume into Volume 1 (it's a quick test for a later idea I've got).

This code fails, even though programmatically it should work, but obviously there is a feature I haven't caught on... Granted I'm biased by years of Python and PHP coding, but unless I am mistaken, kOS doesn't substitute "prog" with the actual content of the "prog" variable from the FOR... loop.

// Bootloader
// This script will copy every program in the Archive into Volume 1.
RENAME VOLUME 1 TO Kerbston.
SWITCH TO Archive.
LIST FILES IN ls.
FOR prog IN ls {
  PRINT "Loading " + prog.
  COPY prog TO Kerbston.
}.
SWITCH TO Kerbston.
PRINT "Loaded progs:".
LIST FILES.

Switch to Kerbston and than copy the programs FROM the archive.

[TDW]

@Cairan

The copy command does not currently recognise prog as a variable but instead looks for a file called prog (same apply to the other file I/O commands - found here).

The current work around is to log commands to a temporary file then run that.

So instead of:

COPY prog TO kerbstone.

you would need

LOG "COPY "+prog+" TO kerbstone." TO temp.
//  I don’t know if you need prog or prog:name for this.

after you have completed the for loop run temp.

Worth noting that you cant modify temp after you run it (well you can but you the program wont load the modified file unless you restart the program). e.g.

 LOG "PRINT 1." TO temp.
RUN temp.
LOG "print 2." TO temp.
RUN temp.

This will print 1 1 not 1 1 2.

Edited October 18, 2014 by TDW

[Cairan]

Thanks a lot both to Trewor007 and TDW ... With that small tweak, my bootloader test now works ... But better yet, I renamed it "bootload.txt" in the Archive, and wasn't I surprised to open the monitor and see that it ran itself while at the launchpad. But something caught my attention, I had a duplicate "bootload" program, one named bootload, the other "boot"... After further tests I renamed it "boot.txt" and sure enough it works without a duplicate now... So if a program is named "boot.txt" it gets loaded and runs right at vessel initiation on the launchpad. I'm not sure if this is an undocumented feature, but it just made my day!

For further reference, here's the full code:

// Bootloader
// This script will copy every program in the Archive into Volume 1.
DECLARE prog.
DECLARE ls.
RENAME VOLUME 1 TO Kerbston.
SWITCH TO Archive.
LIST FILES IN ls.
SWITCH TO Kerbston.
FOR prog IN ls {
  PRINT "Loading " + prog.
  LOG "COPY "+prog+" FROM Archive." TO temp.
}.
RUN temp.
WAIT 3.
DELETE temp.
PRINT "Loaded progs:".
LIST FILES.

I could have included "DELETE boot" after I clean up the "temp" self-generated copy program, but I elected to keep it so I can do a "soft reset" by calling "run boot" while in flight.