kOS Autopilot

[erendrake]

@devs I'll be more than happy to contribute to kOS by providing documentation. If you're interested we should probably set up some sort of more direct communication over the weekend.

sweet! we have been using Google Hangouts a lot for team meetings and Although I have a lot of painting going on this weekend. I would love to make time to discuss helping out with anyone who wants to chip in.

[Camacha]

T]It may feel weird and pedantic but the reason it's like that is because there could be other multiple ways to get to objects later on that I can't predict for. There is *currently* one answer to the question "how do I get to an engine" and that's "you call LIST ENGINES", but if there then were other ways invented later should I keep adding them to the Engine page? It's not *technically* where they belong. There's a programming principle that one should never try to do the same exact thing in two different places if at all possible because it opens up the chance for later edits of the code to cause inconsistency if they only edit one of those places. That same principle applies to making reference documentation. If, say, BODY describes how to get to an ATMOSPHERE, and ATMOSPHERE also describes how you get to itself from a BODY, then the same thing is described in two places.

I understand this line of reasoning, I really do. The thing is that, as it stands, the documentation is hard to understand and use if you are not already familiar with how certain things are used. Even with quite a bit of trying, reading and piecing information together, some things are at best cryptic. Although I applaud your efforts to create unified documentation - which is very valuable for reasons you explained well and should be the way to go - I feel that documentation that hardly anyone understands is not very useful, or even useless.

However, I think it does not have to be one or the other. With some more detailed information, probably a couple of pages with background information on how kOS commands are internally structured and proper links (therefore it being in the place it belongs) to the information you do need to get something functioning, people should get the tools they need to figure it all out. Just the bare essentials on how a command operates and how you can get it to tick in whatever script. Like you said, everything should in essence be in there and I feel at the moment it is not.

Tutorials, example scripts that actually do useful things and stuff like that are indeed a higher level/type of documentation or instruction. Though important to get people started and into kOS, those are a later concern. I am strictly talking about looking up a command and getting the information that is needed to implement it without much further research, guessing and all that.

Edited June 25, 2014 by Camacha

[erendrake]

Anyone who wants to be involved with this conversation this weekend, What timezone are you in and when are you available?

@Camacha? and @MrOnak?

[MrOnak]

sweet! we have been using Google Hangouts a lot for team meetings and Although I have a lot of painting going on this weekend. I would love to make time to discuss helping out with anyone who wants to chip in.

Pretty much any time works for me this weekend. I'm in GMT+1 (Germany) and aside from a bit of shopping on Saturday I can't think of anything we need to get done. Its probably best if you PM me a time that works for you guys and I'll be there.

[Camacha]

For one thing, a really good piece of kOS code that actually works universally and does the job smartly is a thing to brag about and show off. The documentation shouldn't be doing that sort of bragging and showing off. The examples will need to be crude and simplistic and full of caveats.

To be honest, if you want a good piece of ready made software you should look at something like MechJeb. The whole point of kOS is to learn about the factors involved and puzzle something together that utilizes those in a smart, efficient and useful way. Of course, getting inspiration from others is fine if that helps you - it is a good way of learning - but nothing feels better than making *the* best script for the job.

[Camacha]

Anyone who wants to be involved with this conversation this weekend, What timezone are you in and when are you available?

@Camacha? and @MrOnak?

I think I will be available this weekend, though I need to spend time with some friends I neglected due to the project I am working on. Oh, and work on that project

Edited June 25, 2014 by Camacha

[erendrake]

Download From Github

MAJOR

BREAKING: Commrange has more or less been removed from stock kOS, we realized that most of the behavior of it was copied by other mods and was invisible to users
BREAKING: Body:Velocity now returns a pair of orbit/surface velocities just like Vessel:Velocity does. (previously it returned just the orbit velocity as a single vector.)
This version does not include a module manager file, if you still have one in your folder from P1, delete it.
SHIP:APOAPSIS and SHIP:PERIAPSIS are deprecated for removal later, you can find them both under SHIP:OBT

New Features

Added the ability to get and set the current timewarp "Mode" either RAILS or PHYSICS
Added Boot files that will run when you get to the pad automatically, you select which one will run in the VAB thanks @WazWaz
Vessels and Bodies now can be used interchangeably as much as possible.
Three new prediction routines for finding state of an object at a future time:
POSITIONAT( Object, Time ).
VELOCITYAT( Object, Time ).
ORBITATAT( Object, Time ).
you can now get the FACING of all parts.
ITERATOR:END is now split into :NEXT and :ATEND

Known Issues

due to issues with the new version of RemoteTech, you will always have a connection available for use with kOS, this will be resolved before final release.

Fixes

if you have a target and attempt to set a new target and that fails, you would no longer have a target
increased power requirement of the kOS Module
Bodies are now targetable
MAXTHRUST no longer includes flamed out engines
resource floating values are now truncated to 2 significant digits to match the game UI and behavior
files saved to the local volume maintain their linebreaks
radar altimiter now returns a double
fixed an issues where setting some controls blocked the rest.
allow empty bodies on {} blocks
locks called from another lock are not correctly recognized

Prior changes from Pre-Releaes 1

BREAKING: All direction references are now relative to the controlling part, not the vessel, this will only break on vessels there these two directions are not the same.

Added a 3d Drawing tool for letting you draw lines and labels.

This is the first version but i am very excited about it.
Tour: https://www.youtube.com/watch?v=Vn6lUozVUHA
Added a new and improved file editor so the edit command actually works again in game!
Added the ability to switch to MapView and back in code
Other bug fixes

[Camacha]

Ooh, nifty. That bootfile is going to save me some tedious work. I am not sure what I will use the vector drawing for, but I am sure it will really come in handy when debugging certain scripts, or as a user interface.

Edit: I am loving the new boot functionality already. It is very basic, but can be used quite effectively. There might be a small issue though; when I return to the VAB, unset the bootscript and launch again, it still gets executed. Only deleting the kOS unit and adding a new one will remove the boot script.

Edited June 26, 2014 by Camacha

[Camacha]

Oh, I was wondering, I get the "Tried to push Infinity into the stack" warning/error a lot and I am not sure what is happening. Could someone maybe elaborate a bit?

Edited June 26, 2014 by Camacha

[MrOnak]

Good chance is that you're dividing by zero somewhere. That seems to be the case for me in most cases this message appears.

[Dunbaratu]

It used to be the case that kOS allowed you to have numbers that were Infninity or NaN. They kept causing KSP to crash when they were passed in to the KSP Api routines because apparently KSP doesn't protect itself from weird inputs. So to prevent this from ever happening the rather draconian step was taken of disallowing ANY Infinity or NaN values *anywhere* in a kOS program, regardless of whether or not they'll be passed on to a KSP API routine.

If you want to take your chances and allow yourself the risk of having variables storing values of Infinity or NaN, you can do so by changing CONFIG:SAFE to false.

[Rakh]

Anyone who wants to be involved with this conversation this weekend, What timezone are you in and when are you available?

@Camacha? and @MrOnak?

Would you perchance mind a noob modder (but one with a lot of coding experience), who is interested in contributing but thus far totally uninvolved, sitting in on the meeting? I'd love to see what's going on and maybe where I can help.

[erendrake]

Would you perchance mind a noob modder (but one with a lot of coding experience), who is interested in contributing but thus far totally uninvolved, sitting in on the meeting? I'd love to see what's going on and maybe where I can help.

of course, PMed!

[erendrake]

DOWNLOAD FROM GITHUB

* BREAKING: Direction:Vector will always return a unit vector.

* Direction can now always return a proper vector.

* IE SHIP:FACING returned V(0,0,0) before

* Neutralizing the controls will clear the values of all controls.

This change also contains all of the changes from 0.12.2P1 and 0.12.2P2

[ElasticRaven]

nextnode is always giving a null reference exception:

System.NullReferenceException: Object reference not set to an instance of an object

  at kOS.Suffixed.Node.FromExisting (.Vessel v, .ManeuverNode existingNode, kOS.SharedObjects shared) [0x00000] in <filename unknown>:0 

  at kOS.Binding.FlightStats.<AddTo>b__11 (kOS.Execution.CPU param0) [0x00000] in <filename unknown>:0 

  at kOS.Binding.BoundVariable.get_Value () [0x00000] in <filename unknown>:0 

  at kOS.Execution.CPU.GetValue (System.Object testValue) [0x00000] in <filename unknown>:0 

  at kOS.Execution.CPU.PopValue () [0x00000] in <filename unknown>:0 

  at kOS.Function.FunctionPrint.Execute (kOS.SharedObjects shared) [0x00000] in <filename unknown>:0 

  at kOS.Execution.CPU.CallBuiltinFunction (System.String functionName) [0x00000] in <filename unknown>:0 

  at kOS.Compilation.OpcodeCall.Execute (kOS.Execution.CPU cpu) [0x00000] in <filename unknown>:0 

  at kOS.Execution.CPU.ExecuteInstruction (kOS.Execution.ProgramContext context) [0x00000] in <filename unknown>:0 

  at kOS.Execution.CPU.ContinueExecution () [0x00000] in <filename unknown>:0 

  at kOS.Execution.CPU.Update (Double deltaTime) [0x00000] in <filename unknown>:0 

(Filename: C:/BuildAgent/work/d3d49558e4d408f4/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 53)

Code Fragment

0000    jump 1    

0001    push $nextnode    

0002    call print()    <<

0003    EOF   

Pull request: https://github.com/KSP-KOS/KOS/pull/176 (hope I did that right)

Edited June 30, 2014 by ElasticRaven

[Camacha]

I see that ship:facing:yaw:vector does not work. Is that intentional or did that one slip through? Without the vector term it works all right, and when not asking for a specific term the vectors seem to work right too.

[Dunbaratu]

I see that ship:facing:yaw:vector does not work. Is that intentional or did that one slip through? Without the vector term it works all right, and when not asking for a specific term the vectors seem to work right too.

Ship:facing:yaw:vector doesn't work because ship:facing:yaw is just a single scalar number. I can't even guess what result you were expecting here. Did you want a vector pointing out the side of the craft? I'm just trying to figure out what you had in mind.

If you want a vector pointing out the side of the craft (again I don't know if that's what you want. I'm trying to guess), you can do:

Now, before erendrake releases the version with the direction*vector fix in it, you have to do this:

SET sideDir TO SHIP:FACING * V(1,0,0).

SET sideVec TO sideDir:VECTOR.

Soon, after erendrake releases the version with the direction*vector fix in it, you will have to change that to this simpler code:

SET sideVec TO SHIP:FACING * V(1,0,0).

(The bug is that multiplying a rotation by a vector should rotate the vector and return it, but currently it rotates the vector and then converts that back into a direction and then returns that, so you have to convert it back to a vector again, thus the extra line of code difference between the two examples above.)

Using this rotate-a-vector method to get a vector relative to the ship's orientation works like this:

Use the X axis for left/right sides.

Use the Y axis for top/bottom sides.

Use the Z axis for fore/aft sides.

Edited July 4, 2014 by Steven Mading
Gateway error occurred on submitting my post, garbling the text.

[postalbyke]

edit: I just figured out who I can contact about this. Game on, y'all.

Edited July 10, 2014 by postalbyke

[Dunbaratu]

I just posted a "WIP" thread for a tiny mod that I'm planning to have work with kOS in the future.

The idea is to make an instrument that reads distances by laser, let you place several of them on your vessel, and then read their values to have script code work out things like terrain slope in 3-D, or whether or not there's a mountain to the side of you.

It's still very alpha at this point, as I still need to implement a proper use of KSP's distant terrain height mapper (called PQS), that right now is crude and gives inaccurate values, but for distances less than about 7000 meters or so, it seems to be correct.

[Kethevin]

I apologize for not reading beyond the first few pages, but I wasn't seeing an answer or download.

I'm curious about the option of a KOS and Remotetech 2 pair up. I haven't been able to get it to work (assuming it's possible), any help would be appreciated, thank you.

[Pondafarr]

I apologize for not reading beyond the first few pages, but I wasn't seeing an answer or download.

This thread is primarily for discussing coding of an autopilot script, the mod release thread is in the addons forum.

[erendrake]

I apologize for not reading beyond the first few pages, but I wasn't seeing an answer or download.

I'm curious about the option of a KOS and Remotetech 2 pair up. I haven't been able to get it to work (assuming it's possible), any help would be appreciated, thank you.

We have a beta for RemoteTech kOS integration that you can turn on and try in the kOS config file. there is a known issue in the change notes for 12.2

[Kethevin]

We have a beta for RemoteTech kOS integration that you can turn on and try in the kOS config file. there is a known issue in the change notes for 12.2

The version of KOS I have says 13.1.

If I backtrack to 12.2, are there any significant changes I should know? I've noticed some differences in the syntax used from when I used it six months ago and I think I'm finally familiar with the current use.

[erendrake]

The version of KOS I have says 13.1.

If I backtrack to 12.2, are there any significant changes I should know? I've noticed some differences in the syntax used from when I used it six months ago and I think I'm finally familiar with the current use.

I just wanted you to see the known issue in the patch notes from the old issue because it is still an issue and i only had a moment to respond before my meeting. Please use the most recent 13.1

[dlrk]

Is there an IDE available for the newer version of KOS?