[1.3] kOS Scriptable Autopilot System v1.1.3.0

[PTGFlyer]

ugh.

I can't believe I forgot that.

Thanks.

What lines need rewriting?

[ElWanderer]

1 hour ago, PTGFlyer said:

ugh.

I can't believe I forgot that.

Thanks.

What lines need rewriting?

The line that compares the node's pitch and yaw to the ship's is gibberish (but presumably worked some time in the past). I'd use a vdot or vang between the node's deltav vector and SHIP:FACING:FOREVECTOR.

There may be other problems, but that is the main one. Test it and see!

[meyerweb]

I’ve started to think about stage-independent actions.  This is where my Kerboscript scans the entire ship for parts like launch clamps, engines, decouplers, and fairings, and manages the lighting of engines and ejection of clamps and stages and fairings.

Building lists of parts, I can do.  Once I have those lists, are there reliable ways to tell which part is which, short of naming them ahead of time?  For example, how to tell which engines are on the first stage, so that I light those to get off the pad and not, say, the engine on the probe I’m lifting to orbit.  Similarly, if I’m sending a landing probe to Eve, is there an easy way to tell which fairing is on the probe (which I don’t want to eject until I’m in Eve’s atmosphere) and which is on the lifting vehicle (which I want to eject at ~50km altitude during launch)?

I do know about the STAGE command, but I’m just thinking about ways to do things that don’t rely on having a specific staging order.

I can post a specific vehicle file if that would help, though I’ll have to build it first.

[PTGFlyer]

3 hours ago, ElWanderer said:

The line that compares the node's pitch and yaw to the ship's is gibberish (but presumably worked some time in the past). I'd use a vdot or vang between the node's deltav vector and SHIP:FACING:FOREVECTOR.

There may be other problems, but that is the main one. Test it and see!

What's vdot and vang?

And how do you use them?

[ElWanderer]

3 minutes ago, PTGFlyer said:

What's vdot and vang?

And how do you use them?

They are functions that return the vector dot product and the angle (respectively) between two vectors. Both can be used to check how aligned two vectors are. VDOT is used further on in the example burn script. VANG is a bit more understandable if you're not comfortable with vector mathematics.

http://ksp-kos.github.io/KOS_DOC/math/vector.html

[Dunbaratu]

6 hours ago, meyerweb said:

I’ve started to think about stage-independent actions.  This is where my Kerboscript scans the entire ship for parts like launch clamps, engines, decouplers, and fairings, and manages the lighting of engines and ejection of clamps and stages and fairings.

Building lists of parts, I can do.  Once I have those lists, are there reliable ways to tell which part is which, short of naming them ahead of time?  For example, how to tell which engines are on the first stage, so that I light those to get off the pad and not, say, the engine on the probe I’m lifting to orbit.  Similarly, if I’m sending a landing probe to Eve, is there an easy way to tell which fairing is on the probe (which I don’t want to eject until I’m in Eve’s atmosphere) and which is on the lifting vehicle (which I want to eject at ~50km altitude during launch)?

I do know about the STAGE command, but I’m just thinking about ways to do things that don’t rely on having a specific staging order.

I can post a specific vehicle file if that would help, though I’ll have to build it first.

I'm sure you've noticed in building in the VAB how in reality the ship is a tree structure (with the exception that struts are allowed to link cousins and siblings and thus slightly violate that tree structure).  Well, in kOS you could walk this structure because each part has a :PARENT suffix and a :CHILDREN suffix (PARENT is a single part, and CHILDREN is a LIST() of parts.)

So using that you could figure out which parts are "closer to" the root part, and which parts would "fall off" when a decoupler is triggered.

[leviathan01]

Is there a way to get the retrograde vector of the relative velocity to the target.

Edited August 28, 2016 by leviathan01

[ElWanderer]

50 minutes ago, leviathan01 said:

Is there a way to get the retrograde vector of the relative velocity to the target.

Yes, TARGET:VELOCITY:ORBIT - SHIP:VELOCITY:ORBIT. At least, I think that's the right way around. It gives you the vector you need to burn to match velocity with the target.

Edited August 28, 2016 by ElWanderer

[Dunbaratu]

10 hours ago, ElWanderer said:

Yes, TARGET:VELOCITY:ORBIT - SHIP:VELOCITY:ORBIT. At least, I think that's the right way around. It gives you the vector you need to burn to match velocity with the target.

I think that's the target-relative prograde vector.  If I'm right, you'd need to subtract it the other way around (or multiply it by -1) to get the retrograde version.

EDIT: No, it was right the first time.  Ignore me.

Edited August 28, 2016 by Steven Mading

[Jacke]

8 hours ago, ElWanderer said:

Yes, TARGET:VELOCITY:ORBIT - SHIP:VELOCITY:ORBIT. At least, I think that's the right way around. It gives you the vector you need to burn to match velocity with the target.

 

4 hours ago, Steven Mading said:

I think that's the target-relative prograde vector.  If I'm right, you'd need to subtract it the other way around (or multiply it by -1) to get the retrograde version.

@ElWanderer's formula is correct:

SHIP:VELOCITY:ORBIT + DELTA_V = TARGET:VELOCITY:ORBIT

DELTA_V = TARGET:VELOCITY:ORBIT - SHIP:VELOCITY:ORBIT

 

[Dunbaratu]

2 hours ago, Jacke said:

 

@ElWanderer's formula is correct:

SHIP:VELOCITY:ORBIT + DELTA_V = TARGET:VELOCITY:ORBIT

DELTA_V = TARGET:VELOCITY:ORBIT - SHIP:VELOCITY:ORBIT

 

Yeah, you're right.

I knew that "velocity of A relative to B" means subtracting B's velocity from A's, but forgot that the navball isn't showing you the target's velocity (relative to you) when in target mode.  It's showing you your velocity (relative to target).

Edited August 28, 2016 by Steven Mading

[leviathan01]

Thank you your formulas, I needed both prograde and retrograde, and they both worked.

 

[Blazing Sun]

Ok, I'm probably just an idiot, but I can't seem to figure out the new 'Copypath' command. I try getting the thing to copy a script from the archive to to the vessel, but when I try to run the script, I always get an error message to the effect of that the file does not exist, even though I got no error message when I copied the file in the first place. This is what I type to copy the file; CopyPath("0:/boot", "1:/boot").

[ElWanderer]

1 hour ago, Blazing Sun said:

Ok, I'm probably just an idiot, but I can't seem to figure out the new 'Copypath' command. I try getting the thing to copy a script from the archive to to the vessel, but when I try to run the script, I always get an error message to the effect of that the file does not exist, even though I got no error message when I copied the file in the first place. This is what I type to copy the file; CopyPath("0:/boot", "1:/boot").

Is your file called boot and what path are you trying to run? Because it is the name of the directory where kOS looks for boot files, I'd treat "boot" as a reserved name and avoid using it.

Usually I'd expect the copypath command with those parameters to copy the contents of the boot directory on the archive to the boot directory on the craft. Edit: Or maybe it'd copy the archive's boot directory into the craft's boot directory (so you'd end up with "1:/boot/boot/”)

And if in doubt, run "LIST." (and possibly "CD(boot). LIST.") on the craft to see what's there.

Edited August 29, 2016 by ElWanderer

[Blazing Sun]

1 hour ago, ElWanderer said:

Is your file called boot and what path are you trying to run? Because it is the name of the directory where kOS looks for boot files, I'd treat "boot" as a reserved name and avoid using it.

Usually I'd expect the copypath command with those parameters to copy the contents of the boot directory on the archive to the boot directory on the craft. Edit: Or maybe it'd copy the archive's boot directory into the craft's boot directory (so you'd end up with "1:/boot/boot/”)

And if in doubt, run "LIST." (and possibly "CD(boot). LIST.") on the craft to see what's there.

Yes, the file is titled 'Boot.ks'. I created it in the last version of kOS, not knowing they'd make this kind of change with the next update. The run command I input is this; RunPath("1:/boot"). So, should I try renaming it to, say, 'Startup' and then telling it to run 'RunPath("1/boot/startup").'?

[ElWanderer]

15 minutes ago, Blazing Sun said:

Yes, the file is titled 'Boot.ks'. I created it in the last version of kOS, not knowing they'd make this kind of change with the next update. The run command I input is this; RunPath("1:/boot"). So, should I try renaming it to, say, 'Startup' and then telling it to run 'RunPath("1/boot/startup").'?

If this is a boot script, then my advice would be to create a boot directory within your Ships/Scripts directory and put the file there. Then you should be able to select it as a boot file while editing a craft, so it'll be copied across on putting the craft on the launchpad/runway, and run automatically every time the craft loads. Having files in the boot directory (and they no longer have to have "boot" in the name) is the new way of locating boot scripts, as of v1 kOS.

If you don't want it to be an actual boot file, then yes, I'd rename it and COPYPATH("0:/newname.ks","1:/newname.ks"). then RUNPATH("1:/newname.ks"), where newname is whatever you want to call it. If you're not booting it, there's no need to put it in the boot directory on the craft.

Edited August 29, 2016 by ElWanderer

[MasterJos]

Hi,

I just upgraded to KOS 1.0.0 and the ship:status always return "LANDED" even when flying from few minutes.

It was working perfectly before, I'm I the only one having this issue?

 

[hvacengi]

1 hour ago, MasterJos said:

Hi,

I just upgraded to KOS 1.0.0 and the ship:status always return "LANDED" even when flying from few minutes.

It was working perfectly before, I'm I the only one having this issue?

Status appears to be working fine on my local copy.  What version of KSP are you using?  There was a similar bug when using v19.x with KSP 1.1.x, as well as other combinations.

[MasterJos]

Kerbal Space Program - 1.1.3.1289

I Have very few addons, and I just changed the Kos today and the problem started.

I checked again and the status remains LANDED until I get to approx 8000M then it changes to FLYING.

It defitely was faster then that before.

I used it to know when to adjust my heading since in some occasion I would rotate to early and I scraped the flood turning.

 

Thanks !

Edited August 29, 2016 by MasterJos

[hvacengi]

18 hours ago, MasterJos said:

Kerbal Space Program - 1.1.3.1289

I Have very few addons, and I just changed the Kos today and the problem started.

I checked again and the status remains LANDED until I get to approx 8000M then it changes to FLYING.

It defitely was faster then that before.

I used it to know when to adjust my heading since in some occasion I would rotate to early and I scraped the flood turning.

 

Thanks !

Are you saying that previously the status wouldn't change immediately?  In the past, and in my current testing, the status changes the moment that the ship leaves the ground.  Could you share your code and a log file for us to review the behavior you're seeing? (via dropbox, google drive, paste bin, or your preferred sharing service if possible to prevent a post on the forum itself from getting too long)

[dlrk]

What references do I need to compile kOS from source? I'm trying to compile it with CalebJ2's trajectories add-on.

[hvacengi]

8 hours ago, dlrk said:

What references do I need to compile kOS from source? I'm trying to compile it with CalebJ2's trajectories add-on.

See item 3 here for applicable dlls and location: https://github.com/KSP-KOS/KOS/blob/develop/CONTRIBUTING.md#setting-up-the-solution-dependencies

You do not need to download KSPAPIExtensions.dll, that was previously used for utilities that are now included in stock and apparently we forgot to remove that line in the text.

I will probably be trying to move this addon into an external addon package soon.  I got a notification a week or so ago that trajectories merged CalebJ2's PR there with the foundation necessary for the addon to work properly (rather than needing to compile your own version of trajectories) which means that there shouldn't be an issue with us releasing the compiled addon to the public.

[dlrk]

I was able to compile it by adding "[kOSAddon("TR")]" at the top below the namespace, but Trajectories isn't being detected. Looks like the code needs to be changed a bit, I'm not sure exactly what to do however.

Looks like it can't get the API class from trajectories.

Edited September 2, 2016 by dlrk

[ColKlonk]

Anybody else having a Cooked Control problem wrt engine gimbals ? (RSS/Realism Overhaul mods)

On KSP v105 the engine gimbals work OK.

With KSP113, with the 'same' KOS program.. the gimbals don't work with any Locked steering..etc

Edt:

 

Adding to this.. how many straight assignment locks could one execute per physics tic.

It's subjective due to PC speeds, but I'm trying to find min/max figures before my locks overrun the tic time - making sure I don't have too many.

 

For example, say in the top of the file... 

Lock steering to heading(myCourse, myPitch).

..where myCourse, myPitch are calculated in a function similar to ...

.. a TmpVar is

.. assigned result of a few

.. calculations

Set myCourse to TmpVar.

 

So AFAIK, in this case, there is no Lock interrupt routine code, except to assign myCourse to the KSP control system

Would this be a correct assumption ?

Edited September 4, 2016 by ColKlonk
adding more info

[Lookerksy]

In next version, would you mind add part's temperature data (current temp & max temp) into right-mouse menu of the part?
Sometimes when my vessel flight at high speed, 
    my kOS program can't find any information to tell me how to do to avoid overheat explosion.

Thanks.