kOS Autopilot

[marianoapp]

You should make a fork of the github repo, commit your changes there and then create a pull request (how to create a pull request).

BTW I like this change

[Camacha]

I like that booty... eh, bootfile!

[Dunbaratu]

Sigh. As it turns out, the Unity TextArea widget doesn't understand the concept of tabs, so when you indent your source code with tabs, the in-game editor won't even show one single space for them. Instead the widget assumes that hitting "TAB" means "go to next field", and as there is no next field, nothing happens.

I'm not sure it's fixable. But serious editing should be done outside the game anyway, so I guess it's workable for quick-and-dirty looking at files.

[baloan]

I've encountered a FlightControl class in the git repository which looks like having suffixes for controlling thrusters. Are those suffixes available from the terminal?

[erendrake]

I've encountered a FlightControl class in the git repository which looks like having suffixes for controlling thrusters. Are those suffixes available from the terminal?

Yes, they are detailed in the flight docs

http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/

under Raw Control

[IronGremlin]

So this took me all day to figure out - not sure if this is a feature or a bug, but it sure as hell isn't documented...

If you have no reaction wheels anywhere on your craft, 'lock steering to y' will instead try to maintain current vessel heading. Adding a part with reaction wheels restores normal function. Also, ship:control seems to be unaffected.

Might want to post that somewhere where all the RSS/RO folks can find it.

[erendrake]

So this took me all day to figure out - not sure if this is a feature or a bug, but it sure as hell isn't documented...

If you have no reaction wheels anywhere on your craft, 'lock steering to y' will instead try to maintain current vessel heading. Adding a part with reaction wheels restores normal function. Also, ship:control seems to be unaffected.

Might want to post that somewhere where all the RSS/RO folks can find it.

This is a bug that we have known about for some time. The reason it isnt documented is that past me would be pissed that the bug is still around we dont use engine torque to determine LOCK steering.

We had most of a solution https://github.com/erendrake/KOS/pull/48 but that has clearly not finished development. Sorry for the trouble

[IronGremlin]

This is a bug that we have known about for some time. The reason it isnt documented is that past me would be pissed that the bug is still around we dont use engine torque to determine LOCK steering.

We had most of a solution https://github.com/erendrake/KOS/pull/48 but that has clearly not finished development. Sorry for the trouble

Hey, no worries - Now that I figured it out I'm having a great time writing all kinds of fun scripts. Thanks so much for all the hard work on an awesomely fun mod!

Just to check -

This also kills aerodynamic control surfaces in absence of reaction wheels. They don't turn off, mind you, they just don't quite work - near as I can figure it provides some sort of weird attempt to hold current heading, but not real well. Once the reaction wheels exist, the aerodynamic control surfaces behave normally.

Just wanted to be sure we're talking about the same behavior.

[baloan]

Anyone knows a way/mod to display a latitude/longitude grid on a planet or moon?

Or to have an enhanced mouse cursor that displays latitude/longitude next to the mouse cursor?

I am looking for a way to visually select latitude/longitude of a landing zone for my lander.

[deepholecaver]

Is there some data structure that I can get my ship's current stage number from? I can't find anything in the docs except list parts which does not help me.

[baloan]

I am looking for commands to end a program. The use case looks like this:

declare parameter name.
if ship:vesselname <> name { 
    print "WARNING! This script maybe incompatible.".
    print "Designed to work with '" + name + "'".
    print "         Current ship '" + ship:vesselname + "'".
    // end program
}

Is there an existing solution? Otherwise I want to open a ticket to add an "end" command.

[SolarLiner]

Nope there isn't. Currently the workaround is to create an error on purpose so that the script stops working.

[MrOnak]

I end my scripts by using "break" to exit the main loop. Of course that assumes that your script runs in a loop, but mine tend to do that.

Alternatively I use "until AG10=on {}" or something similar where I know that the action group in question is unused.

[Dunbaratu]

Nope there isn't. Currently the workaround is to create an error on purpose so that the script stops working.

The problem with that workaround is that it breaks out of all sub-programs, not just the current one. If your script calls a script that calls a script, there's a need to differentiate between quitting the current program and quitting all programs.

kOS definitely could use some sort of an "exit". The reason I haven't pushed harder for it though is that its wrapped up with the idea of having functions - what is the difference between a return and and exit, does an exit return an exit code like a real program does, etc. So I'd like to wait and see how functions end up being dealt with.

[baloan]

What do you think about monthly releases?

12.2p1 has been published on May 21st and I see fixes and changes accumulating on github.

In order to have some transparency and consistency with release naming I suggest:

1. only fix bugs between a 12.2* and the final 12.2 release.

2. put new features in the next release 12.3 branch.

Does it make sense?

[erendrake]

What do you think about monthly releases?

12.2p1 has been published on May 21st and I see fixes and changes accumulating on github.

In order to have some transparency and consistency with release naming I suggest:

1. only fix bugs between a 12.2* and the final 12.2 release.

2. put new features in the next release 12.3 branch.

Does it make sense?

The current lag in release is my fault, i started a new job May 5th and it has really slowed my development. I have wanted to do a new release but i have been stymied by a new bug were RemoteTech + kOS == KSP world destroy.

I am hoping to steal some tech from the RT team to make a real continuous pre-release available.

[Camacha]

The implementation of the new :VECTOR suffix for a direction is a bit limited, as it only works for some types of Direction and you have to know how the C# code implemented the Direction to know which ones it works for and which ones it doesn't. I want to fix this, because mathematically is is possible to get a unit vector from any Direction. I know because I did it in script code ages ago. But the implementation of it in the kOS suffix is a bit limited right now.

I know you are busy elsewhere, so you should in no way take this as pressure to get to work, but I was wondering whether these missing vector outputs are something I can expect to be fixed any time soon? There is something I would like to work on that could really use this, but if it is going to take a while I would rather wait than implement some workaround that will be redundant later.

Take your time and make sure to have fun

Edit: I checked out the angular momentum and velocity vectors as an alternative and those are not implemented either.

Edited June 24, 2014 by Camacha

[Camacha]

I seen that running empty loops is not possibly anymore:

until ag2 = "True" {}.

This gives me an "Object reference not set to an instance of an object" error. Is this intentional?

[Dunbaratu]

I know you are busy elsewhere, so you should in no way take this as pressure to get to work, but I was wondering whether these missing vector outputs are something I can expect to be fixed any time soon? There is something I would like to work on that could really use this, but if it is going to take a while I would rather wait than implement some workaround that will be redundant later.

Take your time and make sure to have fun

Edit: I checked out the angular momentum and velocity vectors as an alternative and those are not implemented either.

I want to fix this, as well as provide a way to have vectors "know" their own reference frame, as in "this vector knows that it's in raw coords, and this other vector knows that it's in navball coords", etc. But that was blocked for a while.

I often run into problems where changes that by all rights *should* be quick and easy aren't because the KSP API is not documented at all. The only documentation for it is that created by the fan community by peeking into the DLL's public namespace, and given how long it takes to relaunch KSP after each tiny change to the mod code, the trial and error process can be quite time consuming for working out what an API routine actually does.

I do want to fix Direction:Vector to always work, but my current planned queue is this:

(1) Implement Future Position Solver, as in:

SET MyFuturePos TO POSITIONAT( SHIP, TIME+60*60*24*10 ). // get predicted position 10 days from now, taking into account all maneuver nodes on your flight plan and SOI transitions.

(This is [possibly] done already - I have a pull request for it but I want to bang on it with more testing first.)

(2) Return the intercept data the that player can see on the map view - the little red and orange chevrons for predicted closest pass with another object.

(I have to do #1 first because the intercept is returned as a timestamp. Until you have a way to transform a timestamp into a location, it's not meaningful.)

#1 and #2 were projects I started on because of the planned goal of "make docking possible". If you can't plan an intercept, then you can't dock.

Only then will I want to start on:

(3) Vector and Direction reference frames. At the moment the XYZ system of KSP is pretty insane and making users have to live in that coordinate system all the time is a pain. Improving vectors and directions so they may be automatically transformed between several convenient reference frames is a goal I have. Fixing the :VECTOR suffix of Direction is something that I'd wait on until I hit this topic.

[Camacha]

(1) Implement Future Position Solver, as in:

SET MyFuturePos TO POSITIONAT( SHIP, TIME+60*60*24*10 ). // get predicted position 10 days from now, taking into account all maneuver nodes on your flight plan and SOI transitions.

I know you are a big supporter of letting the user figuring things out and build neat solutions, rather than handing them a solution. This seems to my uninitiated eyes a little bit of a deviation from that, even though it sounds like a useful and advanced addition. Is there any specific reason you are working on this?

Only then will I want to start on:

(3) Vector and Direction reference frames. At the moment the XYZ system of KSP is pretty insane and making users have to live in that coordinate system all the time is a pain. Improving vectors and directions so they may be automatically transformed between several convenient reference frames is a goal I have. Fixing the :VECTOR suffix of Direction is something that I'd wait on until I hit this topic.

Having the :vector suffix fixed would be very useful (especially for my current projects), but finally breaking free from the underlying KSP coordinate system would be truly a major step in making kOS more accessible. It can already be a bit of a steep learning curve if you do not have a programming background already and throwing in something like that really leaves it to a limited few enthusiasts.

[Dunbaratu]

I know you are a big supporter of letting the user figuring things out and build neat solutions, rather than handing them a solution. This seems to my uninitiated eyes a little bit of a deviation from that, even though it sounds like a useful and advanced addition. Is there any specific reason you are working on this?

The math problem "where will this orbiting object be at time T?" has no analytical solution unless the orbit is perfectly circular. The only solutions known to exist for the more generic elliptical case are messy numerical series approximations. There is value in executing them quicker than kOS script can do it, and, importantly, KSP already implements such an algorithm under the hood and uses it to find the red and orange chevrons in map view for intercepts. kOS should present information to the player that is as similar as possible to what the player sees when playing manually. This information is already available in the manual map view.

[IronGremlin]

... kOS should present information to the player that is as similar as possible to what the player sees when playing manually.

How do you feel about allowing KoS to call the estimated burn time value on a maneuver node?

I've been on the fence about whether or not it seems like a consistent KoS feature myself, but am curious to know your take.

[Dunbaratu]

How do you feel about allowing KoS to call the estimated burn time value on a maneuver node?

I've been on the fence about whether or not it seems like a consistent KoS feature myself, but am curious to know your take.

Good question. Because while it's true that the game provides it, it's also true that the game provides it *wrongly*. The estimated burn time KSP presents to you presumes that no staging occurs during the burn and that the loss of mass during the burn is negligible.

So, I'd be reluctant to present wrong information to the player as would happen if that was just passed through as-is, but also reluctant to do the work of determining fuel loss from burning and predicted staging.

[IronGremlin]

Good question. Because while it's true that the game provides it, it's also true that the game provides it *wrongly*. The estimated burn time KSP presents to you presumes that no staging occurs during the burn and that the loss of mass during the burn is negligible.

So, I'd be reluctant to present wrong information to the player as would happen if that was just passed through as-is, but also reluctant to do the work of determining fuel loss from burning and predicted staging.

That's a fantastic point, but honestly I feel that the inaccuracies in the default data are at least a known quantity.

I'd be more worried about how it doesn't calculate until you 'throttle up.'

I feel that kOS suffers from a bit of an identity crisis; it's split between quick and dirty functional scripting, and trying to satisfy a small group of enthusiasts with prior coding experience that want a more fully featured language.

I'm not sure how much of the 'quick and dirty' part comes from a desire to implement proof of concept ideas prior to fleshing out the particulars, and how much comes from trying to make basic script goals approachable.

More on point:

I'd lean towards saving this until functions are implemented, and making it a kind of ' included library feature' rather than a core language feature. It's one of those things that is a piece of code that every user will end up using at once point or another, so it seems silly not to include it at all. Including some basic importable scripts with things like a burn time calculator or a warp to time stamp script would save new players some headache and provide neat bits of learning material.

Anyway, just some thoughts.

[Camacha]

I was thinking that it might be an interesting feature (for a later point in the far future) to have individual parts report a vector and scalar about their position relative to the CoM and/or point of control of a vehicle. This will enable users to do stuff like figuring out the dimensions of a vehicle and how the the thrust of engines relates to the CoM. Right now those things are guesswork or a matter of trial and error by a self calibrating ship, but not easily or cleanly done.

What do you think about his? I understand there are a lot of other priorities, but it came to mind and I feel it could be rather useful.

That's a fantastic point, but honestly I feel that the inaccuracies in the default data are at least a known quantity.

I'd be more worried about how it doesn't calculate until you 'throttle up.'

I agree here. I feel that passing on slightly wrong information is to be preferred over introducing a second calculation with a different result about which the user knows little. The original result is what KSP gives you and that is pretty much what the user has to deal with

I feel that kOS suffers from a bit of an identity crisis; it's split between quick and dirty functional scripting, and trying to satisfy a small group of enthusiasts with prior coding experience that want a more fully featured language.

I am really glad to hear you say that, as I have been thinking the same for the past week. Due to other obligations I have not used kOS since Kevin dropped development. This means that I have been getting to terms with the changes and improvements made by erendrake, Steven and the other contributors for the past week, as I have finally installed both KSP and kOS again, enabling me to make a good comparison between the two.

It is really good to see there have been major improvements in a lot of areas. Kevin pretty much jumped into the project without much prior planning or system and sometimes it showed. Now, everything is quite a bit more coordinated and structured. However, kOS was initially intended to be a high level programming language that almost everyone could use. Despite some oddities, I think Kevin succeeded pretty well. Most people could just get going and be pretty well versed after a week or so. I feel the newer iteration of kOS is drifting from this approach. In itself this is not a bad thing, but you probably want to be careful not to exclude anyone without prior programming knowledge. It would leave kOS to a very select group and I think it could and should be so much more, as it is a wonderful introduction into programming, robotics and control theory. It could pretty much change people's lives by showing them this is a neat career to pursue.

I see two solutions for this issue - one being another change of structure to make everything a little more simple and plain. This is probably not ideal, as it means a lot of work has to be redone and it might hurt the usefulness of kOS. The other is expanding the documentation with examples of the minimum code to make a specific command work. Some are not as obvious as others, especially to people without any experience, and a simple illustration would help a lot. Seeing how much trouble people have with simple issues, such as scripts ending right after their commands, they could probably use a little help.