[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Horman]

On 31.3.2016 at 11:44 AM, Polnoch said:

 

I'm not a Apple user, I'm Linux user, but OS X is *nix system, and here this way probably works:

1) copy content of ${gamefolder}/Ships/Scripts in Apple cloud dir, for example:

/Users/${YourUserName}/Library/Mobile\ Documents/com\~apple\~CloudDocs/Documents/

2) create a symbol link to this doc, from your steam KSP folder, in my Linux system:

ln -s /home/***/.local/share/Steam/SteamApps/common/Kerbal\ Space\ Program/ /Users/${YourUserName}/Library/Mobile\ Documents/com\~apple\~CloudDocs/Documents/kOs

In your system path must be different. You can check path in Steam client (view local content button).

Please be  careful, and don't delete your files by mistake. Test it on new/test directories!

I am not an Apple user either...
I tried this in Win7, but that way it doesn't seem to work.
So it seems, this would have to be done in the .dll's... 

Would love to work with my codes in my off-time at work...

[hvacengi]

v0.20.0 KSP 1.1 Hype!

 

This release is functionally identical to v0.19.3, it is recompiled against the
KSP 1.1 release binaries (build 1230)

BUG FIXES

• [KSP1.1] Removing a node leaves an artifact (#1572 #1576)
• [KSP1.1] Toolbar button doesn't display (#1573 #1569)

Downloads

Download from github: https://github.com/KSP-KOS/KOS/releases/tag/v0.20.0

Download from spacedock: http://spacedock.info/mod/60/kOS:%20Scriptable%20Autopilot%20System

Download from curse: http://kerbal.curseforge.com/projects/kos-scriptable-autopilot-system/files

[hvacengi]

On 4/17/2016 at 4:49 PM, Horman said:

If I understand this right, I should try starting setting my THROTTLE TO MAXTHRUST and as soon as I have used this, I should be able to use a calculated lower value?

BTW: Is there a way to "unlock" a STEERING? For example, at launch I give my rocket a slight push for the gravity turn, but from that moment on, I want it to let the gravity do the rest of the turn?!

You can lock the throttle to 0 and query the initial maxthrust before you first throttle up.

Also, you literally nearly gave the steering command already

unlock steering.

That will release kOS's control over steering.

[Camacha]

You guys rock, that was a quick release. I have not played KSP very much lately and without kOS picking it up again would be out of the question

[Kartoffelkuchen]

I've once again made big progress on my project to create a program, emulating the SpaceX landing approach. This time, I've got steering to work properly!

 

In my next video, I will combine the steering and the suicide burn which I already showed off in earlier videos in one program, to make a fully autonomous landing on the landing pad (or whereever).

[Horman]

46 minutes ago, Kartoffelkuchen said:

I've once again made big progress on my project to create a program, emulating the SpaceX landing approach. This time, I've got steering to work properly!

 

In my next video, I will combine the steering and the suicide burn which I already showed off in earlier videos in one program, to make a fully autonomous landing on the landing pad (or whereever).

Very cool!

Thats one goal I would like to achieve someday - right now, I am working on my first ascent script!

[troyfawkes]

Gah, I thought I was done with landing scripts. Now i need to try this :/

[Camacha]

Do we still need to deal with the wonky KSP reference frame shenanigans, or has that been covered by a nicely painted fourth wall by now?

Edit: I just found this. I have not been using KSP for a long time. Can anyone point me to the correct way of using this?

Oh, and how can I turn off that bleeping bleep?

Edited April 21, 2016 by Camacha

[Horman]

And another question to understand this:
If I want to lock my steering just to a direction - lets say, lets go east - without wanting to lock to a pitch too... is there a way to program this? Is it enough to LOCK STEERING TO EAST?

[Alchemist]

Lock the steering to direction that is constructed using your current pitch angle (or something like this). Check the vector math documentation... 

one of the options I can think of is

lock steering to vxcl(az+90, ship:facing:vector).

(where az is the target azimuth). Warning - this won't work if point more than 90 degree from direction. Or, if you want to include roll control

lock steering to lookdirup(vxcl(az+90, ship:facing:vector), up:vector)

This way it'll point your azimuth the way you want, but will have only dampening effect on the pitch

[Polnoch]

On 4/19/2016 at 1:26 AM, Horman said:

I tried this in Win7, but that way it doesn't seem to work.

 

You sad about Apple Cloud, and I thought, you use OS X...

[Horman]

8 minutes ago, Polnoch said:

 

You sad about Apple Cloud, and I thought, you use OS X...

No problem, wanted to ask for as many ways possible

 

[dlrk]

I have a bug report, unfortunately. ALT:RADAR returns altitude above sea level, not true altitude.

http://imgur.com/vxkjCji

EDIT: Never mind, turns out it doesn't become accurate until a lower altitude.

Edited April 25, 2016 by dlrk

[Camacha]

On 21/04/2016 at 4:32 AM, Camacha said:

Do we still need to deal with the wonky KSP reference frame shenanigans, or has that been covered by a nicely painted fourth wall by now?

Edit: I just found this. I have not been using KSP for a long time. Can anyone point me to the correct way of using this?

Oh, and how can I turn off that bleeping bleep?

Does anyone have any input on this?

[troyfawkes]

@Camacha AFAIK nothing major has changed around reference frames. You can check what's upcoming here and in the issues tab:

https://github.com/KSP-KOS/KOS/milestones

If you've wrapped your head around it and have a good idea on how to implement it, I bet the devs would love to hear from you I personally hate the reference frame system too but I kind of just... gave up on it

[Camacha]

1 minute ago, troyfawkes said:

@Camacha AFAIK nothing major has changed around reference frames. You can check what's upcoming here and in the issues tab:

https://github.com/KSP-KOS/KOS/milestones

If you've wrapped your head around it and have a good idea on how to implement it, I bet the devs would love to hear from you I personally hate the reference frame system too but I kind of just... gave up on it

I am not sure we understand each other correctly The reference frame will be there in the future, so much I accept. It is just that I understand that using this library prevents me from having to deal with it, allowing me to work with kOS in a proper fourth wall way. After trying to use the library, I have to admit I have no idea how to work this code into my own to get it ticking. Do I use it as a separate file that I load when needed? Do I copy paste the code?

Nothing I tried really seemed to yield usable results.

[hvacengi]

5 hours ago, Camacha said:

I am not sure we understand each other correctly The reference frame will be there in the future, so much I accept. It is just that I understand that using this library prevents me from having to deal with it, allowing me to work with kOS in a proper fourth wall way. After trying to use the library, I have to admit I have no idea how to work this code into my own to get it ticking. Do I use it as a separate file that I load when needed? Do I copy paste the code?

Nothing I tried really seemed to yield usable results.

No matter how much abstraction we may provide, you will still need to know how reference frames effect things in order to work with them.  If all you mean is that some values are in local coordinates and others in world coordinates, then you can use directions (rotations) to convert between the whatever reference frame you want.  You can see a good explaination here: https://www.reddit.com/r/Kos/comments/3kx83f/fun_with_rotations_conversion_to_a_shipship/cv1flsv

As for lib_navball, you can find examples of how to use it in the same repository you found the script in, under the examples directory: https://github.com/KSP-KOS/KSLib/tree/master/examples just copy the two scripts into your directory, and either run them from the archive or copy to the processor's hard drive and run them.

Edited April 28, 2016 by hvacengi

[BevoLJ]

Wondering if anyone might be able to help point me in a correct direction. I am currently trying to get info (visp, thrust, ...) on non-active engines to plan burn times and such prior to ullage. Tried a few things, but none are working out how I'd like.

One is listing my engines but can't get thrust info. So for example:

local en is list(). LIST ENGINES IN en. local enlength is (en:length-1).

LOCAL Eng_isp is en[enlength]:visp.	LOCAL eng_maxthrust is en[enlength]:FUELFLOW.

print "An engine exists with ISP = " + Eng_isp.
print "An engine exists with mTh = " + eng_maxthrust. //can't get thrust to work

So I thought I'd change how I do my ullage and activate the engine with throttle at 0 so I don't waist any ignitions. That sort of works, but code gets messy if ullaging with solids for obvious reasons.

Another idea I had was tagging the stages in VAB.

LOCAL en is list(). LIST engines IN en.
FOR eng IN en IF ship:partstagged("CoreEng") 
	{ LOCAL Eng_isp is eng:visp. }

print "An engine exists with ISP = " + Eng_isp.

I feel this would be a perfect way to accomplish what I'd like, but it doesn't work.  I can't figure out why. It gives an error saying it can't cast to destination type, but I don't understand what that means. Perhaps someone who is more knowledgeable might be able to enlighten me? =)

Edited April 30, 2016 by BevoLJ

[Camacha]

Is there any way to turn off the console bleep?

On 28/04/2016 at 8:55 PM, hvacengi said:

No matter how much abstraction we may provide, you will still need to know how reference frames effect things in order to work with them.  If all you mean is that some values are in local coordinates and others in world coordinates, then you can use directions (rotations) to convert between the whatever reference frame you want.  You can see a good explaination here: https://www.reddit.com/r/Kos/comments/3kx83f/fun_with_rotations_conversion_to_a_shipship/cv1flsv

As for lib_navball, you can find examples of how to use it in the same repository you found the script in, under the examples directory: https://github.com/KSP-KOS/KSLib/tree/master/examples just copy the two scripts into your directory, and either run them from the archive or copy to the processor's hard drive and run them.

My intention is to write code for a surface craft without having to deal with the specific KSP frame of reference and its strange peculiarities. That is simply a skill I do not desire to have or know about. Writing code for a craft that could exist in the real world, even though it is simplified, it something that interests me a lot.

Thank you for your link to the example code. After some fiddling I have gotten things to tick, though kOS did not seem to like me cutting and pasting the code into a file. I needed to download the Raw file for kOS to execute the file as it should. That seems a bit strange, considering copying and pasting my own code from this thread did not give me any trouble at all.

Edited April 30, 2016 by Camacha

[hvacengi]

1 hour ago, BevoLJ said:

Wondering if anyone might be able to help point me in a correct direction. I am currently trying to get info (visp, thrust, ...) on non-active engines to plan burn times and such prior to ullage. Tried a few things, but none are working out how I'd like.

...

I feel this would be a perfect way to accomplish what I'd like, but it doesn't work.  I can't figure out why. It gives an error saying it can't cast to destination type, but I don't understand what that means. Perhaps someone who is more knowledgeable might be able to enlighten me? =)

We do not currently support getting information off of inactive engines.  It's a topic that has been discussed multiple times but honestly we have things higher than it on the priority list.  I am curious about the error however.  Where does it throw the error, in the string addition or elsewhere?

[BevoLJ]

30 minutes ago, hvacengi said:

We do not currently support getting information off of inactive engines.  It's a topic that has been discussed multiple times but honestly we have things higher than it on the priority list.  I am curious about the error however.  Where does it throw the error, in the string addition or elsewhere?

 

[hvacengi]

2 hours ago, BevoLJ said:

Another idea I had was tagging the stages in VAB.

LOCAL en is list(). LIST engines IN en.
FOR eng IN en IF ship:partstagged("CoreEng") 
	{ LOCAL Eng_isp is eng:visp. }

print "An engine exists with ISP = " + Eng_isp.

I feel this would be a perfect way to accomplish what I'd like, but it doesn't work.  I can't figure out why. It gives an error saying it can't cast to destination type, but I don't understand what that means. Perhaps someone who is more knowledgeable might be able to enlighten me? =)

I may have found your problem.  That isn't valid syntax.  You have to put the "if" information within the code body, not in the "for" statement.  Also, the local variable within "for" loop will be discarded once you leave that scope (anything within the brackets).  That's the only thing there that I see that would cause an issue.  But the error could probably be improved.

LOCAL en is list().
LIST engines IN en.
FOR eng IN en {
    IF ship:partstagged("CoreEng") {
        LOCAL Eng_isp is eng:visp.
        print "An engine exists with ISP = " + Eng_isp.
    }
}

[BevoLJ]

Thanks for the suggestion! I tested that code and it is still giving the same error.  It is still erroring on the ship:partstagged("CoreEng"). If I could get that to work, that would open up tons of new opportunities in RO/RSS being able automate calculations. For now I think I will just stick to uploading manual updates from my own pen/paper calculations to the vessel prior to ullage.

Thanks anyway! =)

Edited April 30, 2016 by BevoLJ

[pellinor]

15 minutes ago, BevoLJ said:

IF ship:partstagged("CoreEng")

I don't see what this is supposed to do. Furthermore it does not depend on the 'eng' variable so why is it inside of the FOR loop?

In my understanding ship:partstagged("something") will return a list of parts. Probably the IF is trying to convert that list to a bool. In some languages this is equivalent to "the list is non-empty", but I don't think that kOS supports that.

Edited April 30, 2016 by pellinor

[Camacha]

Is there any way to turn off the console bleep?