kOS Autopilot

[Camacha]

Has the increasing stutter when looping been adressed? With it testing was pretty doable, but missions extending past 5-15 minutes were suffering badly from degrading performance.

Personally I would really like to get a couple of things:

- Direct access to WASD and translation controls, so you can write your own avionics software without the somewhat cheaty lock steering to.

- Indirect user inputs, so that a kOS program can translate those inputs into controls, effectively making fly-by-wire possible. At the moment this is possible in some form, but the way the buttons respond - for instance when continuously pressing a key - makes a practical implementation hard, if not impossible. It would be great to create some safety features or control programs for hard to do feats.

As for the so much discussed drive size limit: why not make it a configurable option? That way players that like the challenge can leave it as it is, and the folks that want more freedom or have other reasons can adjust according to their needs.

Finally, I noted an optional feature in your notes:

PID Controller

I feel this is a great use of kOS, but should strictly be designed and implemented by users themselves.

I love your efforts, keep up the good work!

Edited February 9, 2014 by Camacha

[erendrake]

Has the increasing stutter when looping been adressed? With it testing was pretty doable, but missions extending past 5-15 minutes were suffering badly from degrading performance.

Personally I would really like to get a couple of things:

- Direct access to WASD and translation controls, so you can write your own avionics software without the somewhat cheaty lock steering to.

- Indirect user inputs, so that a kOS program can translate those inputs into controls, effectively making fly-by-wire possible. At the moment this is possible in some form, but the way the buttons respond - for instance when continuously pressing a key - makes a practical implementation hard, if not impossible. It would be great to create some safety features or control programs for hard to do feats.

As for the so much discussed drive size limit: why not make it a configurable option? That way players that like the challenge can leave it as it is, and the folks that want more freedom or have other reasons can adjust according to their needs.

Finally, I noted an optional feature in your notes:

I feel this is a great use of kOS, but should strictly be designed and implemented by users themselves.

I love your efforts, keep up the good work!

First off you're welcome

* Direct control of rotation and translation are definitely on their way, maybe even in v0.12.

* thats a great idea that i hadn't thought about, I think you are right though, unless i have some kind of event structure (eg KeyUp, KeyDown) it will be a hack. we should also allow for joystick control!

* What i am thinking about is making the limit higher in sandbox mode and then tying a bunch of feature unlocks into the tech tree for career. I think it would be against Kevin's vision for the mod to make it simple to turn off.

* For the pid, I was thinking about letting the scripters make a new one (eg "PID(1,0.5,0.7)" then feed it settings and input or maybe even lock it to an expression. Then they would get an output value. just to make the guts a little easier to deal with. Is that what you are thinking? or would you like to keep it like it is where scripters make their own from scratch?

[erendrake]

I have a new prerelease available for testing!

this one takes care of most of the reported bugs and I would really appreciate feedback.

Download:

https://github.com/erendrake/KOS/releases/tag/v0.11.0RC

Documentation:

https://github.com/erendrake/KOS/tree/develop

## This is a prerelease, expect some bugs

- CHANGELOG

- Thanks to enkido and jwvanderbeck for your help.

• Basic RemoveTech Intergration
  
• Added VOLUME:NAME for getting the current volume
  
• Lists can now be populated with basic data that you can loop over or index [Full Info](/wiki/List/)
  
• A Lot of bug fixes and refactoring
  
• Constants (eg G, E, PI) are now retrieved using CONSTANT().
  
• Commands resolve in order of descending specificity, rather than in the pseudorandom order they were in before
  
• Added Math operators LN, LOG10, MIN, MAX.
  
• Removed NODE:APOAPSIS and NODE:PERIAPSIS. They are now available in NODE:ORBIT:APOAPSIS
  

Basic list types:

• Bodies (eg Kerbin, Mun, Duna)
  
• Targets - All Vessels other than current
  
• Engines - Active engines on the craft
  
• Resources - All Ship Resources
  
• Parts - All Ship Parts (slow)
  
• Sensors - (eg Pres, Grav, Accel)
  
• Elements - All flights connected to the active vessel
  

Edited February 9, 2014 by erendrake

[Camacha]

* For the pid, I was thinking about letting the scripters make a new one (eg "PID(1,0.5,0.7)" then feed it settings and input or maybe even lock it to an expression. Then they would get an output value. just to make the guts a little easier to deal with. Is that what you are thinking? or would you like to keep it like it is where scripters make their own from scratch?

To be honest, I am a big fan of letting the scripters do it from scratch. Without an idea what happens under the hood, behaviour is hard to understand and tune. At the same time PID-controllers are not that hard to create with all the online resources available, and constructing one yourself is immensely educational, as is finding the most effective implementation for your job.

Long story short, I think the shortcut will not make life that much easier, as comprehension of the workings is relevant for proper application. If people really want to take the lazy route, they can just copy and paste an example of someone else's code. I feel kOS should provide tools and not solutions and that a ready made PID is just a bit too much of the latter.

Good news on the rest, this promises to become very interesting indeed

Edit: o yeah, any word on the stutter?

Edited February 10, 2014 by Camacha

[erendrake]

To be honest, I am a big fan of letting the scripters do it from scratch. Without an idea what happens under the hood, behaviour is hard to understand and tune.

I'll skip it then How would you feel about making a Tutorial on it, we can add it to the wiki

Edit: o yeah, any word on the stutter?

I haven't had trouble with it. Do you have a craft/script that i could try that expresses it?

[Dunbaratu]

For what it's worth, I too vote against replacing the player's effort in making a PID controller. Giving the player access to data so they can do things themselves is good. So for a PID controller the purpose of the Mod is to give the player measurements of velocity and position to allow the player to write the PID controller, and those things already exist.

By the way, thank you on the effort on user documentation. That was always one of the big problems with Kevin's kOS - the user community had to guess by trial and error how things worked and then write the docs themselves on the wiki, which of course meant they were often a bit wrong.

[Dunbaratu]

I intend to use the new list iterator to have the script "learn" the parachutes on the craft and use them in atmo drag calculations. Thanks for adding that.

[Dunbaratu]

Here's an idea - I don't know how hard this would be to do. All parts have a "rightclick" menu. All parts can register a set of activities accessible through the rightclick menu and they can be accessed through the same uniform API (i.e. "do the thing on this part's rightclick menu labelled as 'decouple node'.") If that could be accessed by scripts it would open up a LOT of abilities to scripters with one set of uniform code on your part.)

[erbmur]

I have been testing your .11 pre-release and I think I have found a bug...

kOS sees a crewed pod with no stages as a probe core with no connection to KSP.

Test set-up as follows:

1 man pod & kOS part held aloft by a launch stabilizer.

run "STAGE.", everything runs fine, pod drops to the floor, now no stages are present. Type "STAGE." again, or any other code, and the following is returned "signal interrupted. Transmission lost."

[CrAzY GeNiUs]

Nice mooooooooooood

[Dunbaratu]

Minor documentation bug:

The links in the new documentation that point at the supposed full description of how to use Lists are pointing to 404 Not Found. Either the link is typed wrong or the page was never uploaded or something.

[erendrake]

@erbmur Sorry i crossed over to the other thread

I have it listed as a bug https://github.com/erendrake/KOS/issues/27

let me know if that wording is correct

[Camacha]

I'll skip it then How would you feel about making a Tutorial on it, we can add it to the wiki

At the end of last year I put quite some time into understanding the inner workings of a PID-controller, so I guess that qualifies me. I was planning on doing something like a couple of blogposts on the subject, but (un)fortunately I am currently in my graduation period - i.e. busy as a number of bees, bevers and whatnot. I am not making any promises on whether it will happen or when it will happen if it happens at all, but I will keep it in mind, as I was looking for information like that myself.

I haven't had trouble with it. Do you have a craft/script that i could try that expresses it?

Pretty much any program that runned in a single prolonged loop displayed this behaviour. Running an until loop introduced a lagspike after running for a while, ever increasing until KSP became pretty much unplayable. The problem could be mitigated by running multiple shorter until loops in succession, but that is not the prettiest solution - or actually not a real solution at all.

Steven Mading and I discussed this problem a couple of times in the old kOS thread

Edited February 10, 2014 by Camacha

[erendrake]

Minor documentation bug:

The links in the new documentation that point at the supposed full description of how to use Lists are pointing to 404 Not Found. Either the link is typed wrong or the page was never uploaded or something.

That should be fixed now. I really dislike the wiki feature in github because it is not integrated into GIT you only get one wiki and keeping the readme linked to it apparently breaks once you branch.

[erendrake]

I am not making any promises on whether it will happen or when it will happens if it happens at all, but I will keep it in mind, as I was looking for information like that myself.

Understood, good luck with graduation!

I am hoping to recruit a few people to help me promote and support the mod in ways that dont require direct code submission which is not for everyone.

Pretty much any program that runs in a single prolonged loop displayed this behaviour.

Gotya, I think i know why that would be and that is going to be a bear to fix. Ill add an issue in github.

[erbmur]

@erbmur Sorry i crossed over to the other thread

I have it listed as a bug https://github.com/erendrake/KOS/issues/27

let me know if that wording is correct

Looks good to me.

Talking about the loss of connection for probes, would it be worth having a command that has the ability to check (true or false) as to whether the probe has connection or not?

[erendrake]

Looks good to me.

Talking about the loss of connection for probes, would it be worth having a command that has the ability to check (true or false) as to whether the probe has connection or not?

Of course I have to head to work but if you keep coming up with cool features like that would you mind adding them to the backlog on github?

[Dunbaratu]

I'm trying the new 0.11 dev build with my old Duna mission.

One change I came across right away is that the built-in variable "body" used to be a string - it was the name of the current body. Now it's the the Body structure of your current body. (i.e. to get the old behavior I could go through my scripts and change all occurrences of "body" to "body:name".)

Was this change intentional or accidental? If it's intentional I'll go through and change the scripts. I think the new way actually makes more sense and is more self-consistent and therefore worth breaking backward compatibility for, but I'm just checking for whether it was intentional before I go and change all my scripts.

[Dunbaratu]

Pretty much any program that runned in a single prolonged loop displayed this behaviour. Running an until loop introduced a lagspike after running for a while, ever increasing until KSP became pretty much unplayable. The problem could be mitigated by running multiple shorter until loops in succession, but that is not the prettiest solution - or actually not a real solution at all.

Steven Mading and I discussed this problem a couple of times in the old kOS thread

Good news. I just tested two of my scripts that used to exhibit the most lag stutter - the ascent and descent scripts - and in 0.11 there didn't seem to be any stutter with them anymore. The ascent script rose all the way up using the enormous 487-part ship without any of the previous freeze-frame behavior. The descent script brought me down to a smooth landing on the Mun (I didn't send it all the way to Duna this time as I wanted to hurry up and perform the test) without any animation pauses. I have no idea what changed but I know eerandrake was fiddling with some parsing internals and I sort of suspected that it might have been the parsing behavior that was responsible in the past - something "leaking worse and worse" the more and more times it re-parsed the loop.

But at any rate, one of the things you changed, eerandrake, whether intentionally for this problem or not, it seems to have reduced or perhaps even eliminated the problem now (crossed fingers).

Edited February 10, 2014 by Steven Mading

[erendrake]

I'm trying the new 0.11 dev build with my old Duna mission.

One change I came across right away is that the built-in variable "body" used to be a string - it was the name of the current body. Now it's the the Body structure of your current body. (i.e. to get the old behavior I could go through my scripts and change all occurrences of "body" to "body:name".)

Was this change intentional or accidental? If it's intentional I'll go through and change the scripts. I think the new way actually makes more sense and is more self-consistent and therefore worth breaking backward compatibility for, but I'm just checking for whether it was intentional before I go and change all my scripts.

This was an intentional change.

I should have marked it with BREAKING in the changelog, in the future i will try to have smaller releases that i can remember everything i break

[erendrake]

Edit: o yeah, any word on the stutter?

But at any rate, one of the things you changed, eerandrake, whether intentionally for this problem or not, it seems to have reduced or perhaps even eliminated the problem now (crossed fingers).

Speaking of forgetting stuff. I had an excellent pull request from enkido that addressed this issue.

https://github.com/erendrake/KOS/commit/38a54e08e78d5768d41f5f40d8814fd2eae4196a

So i gladly deny credit for this fix.

Edited February 10, 2014 by erendrake

[Camacha]

Good news.

That does indeed sound like good news. Quite a number of my scripts are continuously running and watching over certain processes or aspects of a missions, so this is a great step towards making them more useful.

Speaking of forgetting stuff. I had an excellent pull request from enkido that addressed this issue

Hurray for enkido, let us hope this puts that problem behind us.

Edited February 10, 2014 by Camacha

[Dunbaratu]

Speaking of forgetting stuff. I had an excellent pull request from enkido that addressed this issue.

https://github.com/erendrake/KOS/commit/38a54e08e78d5768d41f5f40d8814fd2eae4196a

So i gladly deny credit for this fix.

I was curious about what was wrong all this time. So I looked at the commit. As near as I can tell kOS creates a temporary execution context for a single iteration of a loop, and then when it gets to the end of the loop it marks it as "done" and makes a new one for the next iteration. At each time slice kOS goes through all execution contexts in its master superloop and sees if they have any statements queued up that need executing. Ones that are marked as "done" don't need anything executed.

As far as I can tell, the error was that it was merely marking the old iterations' execution contexts as "done" when it should have been fully deleting them. So by the time you were on iteration 2000 of a loop for example, you'd have 1 execution context that actually needed work done (the current iteration of the loop), but it was buried among the other older 1999 "done" execution contexts from previous iterations. The superloop's time was wasted iterating over them to see if they needed work done. (They didn't, but they still occupied execution time checking each one in turn to find out that it's in "done" status.) Thus why loops got more laggy the more previous iterations they've been through.

[erendrake]

Thus why loops got more laggy the more previous iterations they've been through.

Once i heard what the symptoms were, i was pretty sure it was a problem with execution contexts. It would have taken me much longer to find if enkido hadn't squashed it i love pull requests!

[erendrake]

New full release v0.11

Spaceport

Changelog

- Thanks to enkido and jwvanderbeck for your help.

- BREAKING: BODY, SHIP:BODY, TARGET:BODY now all return a Body structure rather than the name of the body
- BREAKING: Removed NODE:APOAPSIS and NODE:PERIAPSIS. They are now available in NODE:ORBIT:APOAPSIS

- Basic RemoveTech Intergration 
- Added VOLUME:NAME to getting the current volume
- Lists can now be populated with basic data that you can loop over or index [Full Info](/wiki/List/)
    - Bodies (eg Kerbin, Mun, Duna)
    - Targets - All Vessels other than current
    - Engines - Engines on the craft
    - Resources - All Ship Resources
    - Parts - All Ship Parts (slow)
    - Sensors - (eg Pres, Grav, Accel)
    - Elements - All flights connected to the active vessel
- A Lot of bug fixes and refactoring
- Constants (eg G, E, PI) are now retrieved using CONSTANT() rather than spreadout.
- Commands resolve in order of descending specificity, rather than in the pseudorandom order they were in before
- Added Math operators LN, LOG10, MIN, MAX.