[1.3] kOS Scriptable Autopilot System v1.1.3.0

[erendrake]

@Luis It would be helpful if you would add a feature request to the github issue tracker. If they are only on the forum they are likely to be lost in the shuffle.

[togfox]

Can anyone suggest the reasons for a file failing to copy from archive? I'm working on a long and complex script but I've broken it down into small files - mostly for my debugging sanity.

myprog.txt

copy filea from archive.

copy fileb from archive.

copy filec from archive.

until {

run filea.

run fileb.

run filec.

etc

}.

For some inexplicable reason the program will work well for ages, and then all of a sudden throw an error saying that filex could not be loaded. I'm doing a LOT of editing - like - an edit every 60 seconds. I ctrl-c, edit a file in notepad, save - run program again - but that shoulddn't matter. I'll be editing filea and that will through a fatal error - so I // comment out the offending code, and then I get a message that filec couldn't load.

I'm like "what? I didn't even touch file c".

A lot of waffle there - but I'm finding errors sometimes get thrown unexpectedly against code that has always worked and not recently touched. Maybe a bug in kOS but its so random I'd never prove/disprove it. Right now I'm dealing with a file that can load by itself (filec), but as part of a larger script, it won't load - even if it use to.

I'm on the launchpad with a full battery of energy. Cheers.

edit: oh dear - just restarted ksp and that failed script is now working ...

Edited February 6, 2014 by togfox

[togfox]

Moving on - can someone do this for me please:

print arcsin(0.45).

and confirm for me they get 26.743683950403, and then confirm for me the correct answer is 0.466765339.

Cheers.

[Dunbaratu]

Moving on - can someone do this for me please:

print arcsin(0.45).

and confirm for me they get 26.743683950403, and then confirm for me the correct answer is 0.466765339.

Cheers.

0.46676 radians = 26.74368 degrees. All the angles in kOS are given in degrees.

I do think that radians would be mathematically better for all of the usual math reasons, but also for a purely computer engineering reason: in floating point representations, the closer to zero a number is the less error it has so ranging between 0 and 2*pi is going to give you more accurate representations than ranging between 0 and 360.

[AeroEngy]

I've got a quick question regarding the available suffixes in an orbit object.

I was wondering, if at this time it's already possible to access the Vector3d returning functions, for example

Vector3d getRelativePositionAtT(double T)

(Referencing from here : http://wiki.kerbalspaceprogram.com/wiki/API:Orbit)

If i overlooked this functionality shame on me and disregard this, otherwise consider it as a possible feature request

thanks for the info!

Looking at the Orbit API another very useful number to return would be eccentricAnomaly. It can be calculated using existing information however it involves some iterative numerical methods that I would rather not have to do in kOS script. Also I see inclination in the Orbit API as well. Is that already available somehow in kOS if not that would be good as well. I have no idea how GitHub works so I didn't add this as a feature request there ...

I had stepped away from this mod when it went unsupported for awhile. I am thankful it has been picked back up and look forward to getting back into it.

[Dunbaratu]

until {

run filea.

run fileb.

run filec.

etc

}.

Is that valid syntax? I've never seen a kOS "until" loop with no boolean condition expression like that. Is it basically a "loop forever"? (the same as "until false")?

The only thing I can think of is that if the file copy operation would cause your local volume to exceed the 10,000 byte limit then the copy will be denied (but it won't tell you that that's why it failed. It will just say it failed.).

[togfox]

No. Probably not correct syntax. I still get random behavior with files that are proven to be solid and find the best way to fix them is to restart a launch, which is not a problem if testing a script, or restart ksp.

Still loving this mod though.

[erendrake]

Looking at the Orbit API another very useful number to return would be eccentricAnomaly. It can be calculated using existing information however it involves some iterative numerical methods that I would rather not have to do in kOS script. Also I see inclination in the Orbit API as well. Is that already available somehow in kOS if not that would be good as well. I have no idea how GitHub works so I didn't add this as a feature request there ...

I had stepped away from this mod when it went unsupported for awhile. I am thankful it has been picked back up and look forward to getting back into it.

in v0.11 We will have the following values in ORBIT

APOAPSIS - Altitude

PERIAPSIS - Altitude

BODY - Reference Body, has a bunch of its own data.

PERIOD - in seconds

INCLINATION

ECCENTRICITY

SEMIMAJORAXIS

SEMIMINORAXIS

TRANSITION - How the current orbit patch will end

INITIAL,

FINAL,

ENCOUNTER,

ESCAPE,

MANEUVER,

PATCHES - all of the proceeding orbit patches. which have all of these same values.

we have an open issue for adding more to orbit. feel free to add your thoughts

https://github.com/erendrake/KOS/issues/18

[Dunbaratu]

APOAPSIS - Altitude

PERIAPSIS - Altitude

BODY - Reference Body, has a bunch of its own data.

PERIOD - in seconds

INCLINATION

ECCENTRICITY

SEMIMAJORAXIS

SEMIMINORAXIS

TRANSITION - How the current orbit patch will end

INITIAL,

FINAL,

ENCOUNTER,

ESCAPE,

MANEUVER,

PATCHES - all of the proceeding orbit patches. which have all of these same values.

This are all handy. In the past they required some messy bits of code to get the numbers indirectly (i.e. taking the cross product of my up vector and my velocity vector to obtain a vector normal to my orbit plane, and then dot-producting that normal vector with a Y-axis unit vector (which is always in the direction of a ray pointing up out of the north pole) to work out my inclination angle. That's a lot of lines of code (especially since vector operations like cross product had to be done manually) just to obtain one number that is now just one variable expression.). But keeping things hard for bragging sake is just pointless so I'm very glad you've been adding these things. When I go back to revamping the Duna mission I suspect the addition of these things will allow me to make much shorter programs.

I especially like being able to see the encounter without a maneuver node. Having to make dummy null maneuver nodes (maneuver nodes with zero delta V) just to get kOS to report the encounter I'm currently heading for always felt a bit silly to me.

I'm very happy that these changes are there, and that you picked up this mod and ran with it.

[erendrake]

I'm very happy that these changes are there, and that you picked up this mod and ran with it.

You are welcome, this has been a fun project. Documentating these changes is my last step to getting the next release up and i am avoiding it by playing...wait for it....KSP

[Dunbaratu]

You are welcome, this has been a fun project. Documentating these changes is my last step to getting the next release up and i am avoiding it by playing...wait for it....KSP

Yeah. I decided that once the documentation is out I'll try to go through and revamp my Duna mission to clean all the excess crud from it. For one thing I'll no longer need to maintain my own bodystats database.

[togfox]

I think I need to start learning kOS memory management.

- how much memory is available;

- how do I tell how much I've used;

- how do I reduce memory usage (should I strip comments? Declare less variables?)

- how do I convince the mod coder there should be a switch to remove this limitation.

[erendrake]

- how much memory is available;

10000 Bytes

- how do I tell how much I've used;

LIST FILES.

- how do I reduce memory usage (should I strip comments? Declare less variables?)

If you look at Steven's Duna mission. he has quite a few methods for dealing with this problem.

- how do I convince the mod coder there should be a switch to remove this limitation.

I am ready to make many changes to this mod to add access to data and features, we might even add the ability to slave multiple parts together to form one "volume" but some limit stays as long as i am maintaining the releases. Kevin was always emphatic that it would stay and i see no reason to change it.

Edited February 7, 2014 by erendrake
fixed size

[KvickFlygarn87]

Erendrake, I'd like to correct your above post. More accurately, this:

1000

First of all, you didn't list a unit - you need to tell him if it's 1000kB, 1000m^{2, 1000 krakens, 1000 dollars, etc.}

^{Second of all, the number is downright wrongsource}! It's 10,000kB, and honestly - you should know that, you're maintaining the mod!

[erendrake]

Erendrake, I'd like to correct your above post.

Sorry, i actually looked in the code, typed out the full line, and then mangled the text i just typed

and it is not 10000kB. It is 10000B.

[Dunbaratu]

10000 Bytes

togfox asked about how much "memory" not how much "disk". (Granted, it may have been a sloppily phrased question, as I often do hear people refer to disk space as "memory", and of course with swapping and virtual memory, I guess some of the time "memory" *is* disk space.)

togfox, there is no RAM memory cap in kOS (should there be as an added challenge? I don't know). Of course there's the RAM memory cap within KSP itself, from the fact that it's a 32-bit program so its memory plus its mod's memory have a cap at about 3-ish GB when summed all together, but kOS doesn't add any additional memory caps on top of that.

But there is a "disk" cap, and that's the 10000 bytes that erendrake mentioned. It's a cap on the size of one local volume.

There is one local volume per SCS part. It's 10000 bytes. You can add more volumes by adding more SCS parts to the ship. The archive volume, on the the other hand, can be as big as your native computer's disk drive will allow.

If you look at Steven's Duna mission. he has quite a few methods for dealing with this problem.

To a certain extent it's a self-imposed problem because I refuse to use terse variable names. If I was willing to name variables like "gka" and "dbq" and the like then it would decrease the code size. kOS is weird in that it's trying to simulate old-school computers and yet is presuming the CPU on the computer is running a "machine language" that is the actual high-level scripting language expressed in human readable ascii text. (So you "pay" disk space for commenting, indenting, and using long variable names.)

I could have saved a lot of space by using shorter variable names, but that would make it hard for me to read my own code if I put it away for a few months and then came back to it as I'm doing now. It was actually less effort to make a system where it constantly swaps programs in and out of the local volume than it would have been to try to read obfuscated short code.

I am ready to make many changes to this mod to add access to data and features, we might even add the ability to slave multiple parts together to form one "volume" but some limit stays as long as i am maintaining the releases. Kevin was always emphatic that it would stay and i see no reason to change it.

What I'd like to see is a bit more variety so there's more than one kind of SCS part to choose from. One thing that might be nice would be a separation of CPU part and disk volume part into two different parts. Instead of always getting the number of CPUs = the number of disk volumes, you could add them in any arrangement you like. Add 1 CPU part and 3 disk parts to the craft to get 30000 bytes with only one program running at a time from them, or add 1 disk part and 3 CPU parts to the craft to get just 10000 bytes of code, but three copies of programs can be run at the same time from it.

[Camacha]

Although I am not opposed to a storage size limit, I think the current one is too frugal. As has been pointed out a number times now, kOS is supposed to be an accessible language for beginners. The one thing you do not want to do is force people to create badly commented, hardly spaced and illegible code (or script even) for the sake of brevity. Beginners should be enticed to code nicely.

One could circumvent these problems by using a stripper that eliminates comments, spaces and replaces long variable names with short systematic ones (think Tiny URL), but I feel that is not something that should be relied on from a developer's point of view.

Edited February 7, 2014 by Camacha

[Dunbaratu]

Although I am not opposed to a storage size limit, I think the current one is too frugal. As has been pointed out a number times now, kOS is supposed to be an accessible language for beginners. The one thing you do not want to do is force people to create badly commented, hardly spaced and illegible code (or script even) for the sake of brevity. Beginners should be enticed to code nicely.

Or count the 'tokens' rather than the ascii characters and use that as the disk size. That way you decide how much space a mention of a variable in the code takes, and all variables take the same amount whether their name is 3 letters long or 30, and you can skip comments and whitespace that way too.

That would (sort of) simulate the effect of having compiled code, where adding legibility to the source code costs you nothing and so there's no incentive to avoid doing it.

For example both of the following would compile to the same exact length of executable code if there was a compiler:

set   myLongVariableName   to
           anotherLongVariableName + someOtherLongVariableName. // This is a comment.

set A to B+C.

Counting the 'cost' of storage for the program would simulate this effect if you just counted tokens. Both of the above are just:

"Set" Keyword

variable

"To" keyword

variable

Plus Sign

Variable

End Period.

[jcramb]

Hi all! I am new to the thread but am reading through the kOS source (its an awesome mod ) and will submit pull requests soon after to help with dev.

Regarding program size limit I have the viewpoint that a fixed byte limit is not realistic for a number of reasons. The main one being that the byte limit should apply to a compiled program, not one written in an interpreted language. This would mean that the size limit would not penalise developers for using comments or more verbose code structures for clarity. Ideally, kOS should have an assembler but I understand that it is designed for the general ksp public.

With a fixed limit it is also hard to show the advancement of technology in kOS. Ideally there would be multiple script control parts with a range of drive space / clock rate parameters. Then the low space, slower components could be a status symbol of hard mode early day automation, leading to the more advanced / accurate systems required for more complicated interplanetary trips.

Steven's suggestion above sounds like a good interim idea though, counting tokens (but not comments) rather then byte size.

[Panichio]

Sorry to interrupt the intellectual discussion here, but I have an idiotic question if that's alright. Can kOS actually execute a node, or can it only make them?

[jcramb]

Sorry to interrupt the intellectual discussion here, but I have an idiotic question if that's alright. Can kOS actually execute a node, or can it only make them?

You need to write the code to execute the node, ie. lock steering to node and calculate the time required for the burn, then commence the burn half of that time before the node.

[togfox]

Thanks for the tips on memory management. I am writing very complex code for something that has never been attempted (to my knowledge) and yes - my code could be refactored, but right now I'll reduce my comments and abbreviate all my variables to two letters so I fit within the style others are forcing upon me.

(Just making a point. I really like this mod and I appreciate the efforts of the original developer and if erendrake didn't take this over I'd still be in the dark ages using 0.22. I'm now reduced from producing something awesome many people believe is not possible to poring through my code looking for byte savings. A config file setting or a kOS command "set memory to unlimited." will let those that like 'realism' do so while others who just want to code can also do so. Thanks. Love you all - especially erendrake - in a manly type way.)

[togfox]

so if I do this:

set c to 310. // compass heading, i.e. 0=north,90=east,180=south,270=west.
set p to 20.  // pitch, i.e. -90=down,0=horizon,90=up.
lock steering to heading c by p.

Then my craft will turn as expected. However, if I follow with this:

print heading.

I get the value 0. I'm expecting 310 - and the navball in game says 310. What am I not getting?

[togfox]

this is very far from perfect, but for throttle control during launch i use this "subroutine":

calculateTWR.txt

The script you provided is for a launch - but I was after a landing. Fear not, I took the important bits and made a rather smooth landing script thanks to you.

set newtwr to 1.

until alt:radar < 5 {

	run calculateTWR (newtwr).

	if verticalspeed > -1 { set newtwr to newtwr - 0.010. }  //if verticalspeed is too positive (going up) then reduce thrust.
	if verticalspeed < -2.5 { set newtwr to newtwr + 0.010. } //if vertical speed is too negative (dropping too fast) then increase thrust.

	if verticalspeed >= -1 and verticalspeed >= -2.5 { set newtwr to 1 }.  //This line resets the thrust if it gets too extreme

}

And your unmodified calculateTWR.txt

declare parameter desiredtwr.

set g to 9.81.
set t to ship:maxthrust.
set w to ship:mass.

set twr to  t / (w * g ).
//print "twr = " + twr.

set thrustLevel to desiredtwr / twr.

This sets a vertical speed between 1 and 2.5. I aim for a landing speed of 2.0 so this provides a little tolerance each side. Not super smooth and not as precise as MechJeb - but it fits my purposes. Thx.

[Luis]

@Luis It would be helpful if you would add a feature request to the github issue tracker. If they are only on the forum they are likely to be lost in the shuffle.

Done and done. Fingers crossed!