kOS Scriptable Autopilot System 0.9

[cfds]

Loops with only a WAIT statement are ignored by KOS. Perhaps something like

until 0 {

wait 1.

set ix to 0.

}.

will work better.

[Dunbaratu]

I finally got some video recording software set up, so here's my descender/skycrane dropper in action:

[drtedastro]

Very nice. I have my 'folding' rover craft and skycrane ready to go, and now i need to start the code part. You have shown it can be done and done nice. Great work...

[check]

I finally got some video recording software set up, so here's my descender/skycrane dropper in action:

Great work! Looks like a very robust method that's smooth and fuel efficient. Good job with the code annotation too.

[Sma]

I finally got some video recording software set up, so here's my descender/skycrane dropper in action:

Nice! Very Nice! lol

Eventually I might try this with the KAS mod, guess I'd have to bind the winch to action groups though, but thats the least of my problems lol. I'm going to redo my launch program though as with the speed increase it needs some tweaking.

[Bizz Keryear]

When did "log to" become a thing? Was just watching ep2 of the journey to the ~~north pole~~ south pole and he was talking about this. I guess I must have missed it some how. Dunno what I'd use it for just yet, but I'll have to play around with it and figure something out.

log to isn't implemented in the official version as far as I know.

@Payload

Most of the times I try not to use endless loops at all.

Even when I should.

But this is the kOS-interpreter. It works there, and its the shortest possible code.

Purpose of the loop was to run until the vessel becomes unusable.

Achievement of the program (dunno if its because 0.65 or whatever) making it run made KSP unusable (see below).

And the stutter sometimes becomes really evil. Worst so far: intervals of 1 second KSP at normal speed. And the game freezes for half a second. While my CPU and GPU idles.

I think the code needs an overhaul. Just before I quick saved while having a program running. End of this song was that I had to delete the vessel manually from the persistent.sfs...

[Dunbaratu]

log to isn't implemented in the official version as far as I know.

@Payload

Most of the times I try not to use endless loops at all.

Even when I should.

But this is the kOS-interpreter. It works there, and its the shortest possible code.

Purpose of the loop was to run until the vessel becomes unusable.

Achievement of the program (dunno if its because 0.65 or whatever) making it run made KSP unusable (see below).

And the stutter sometimes becomes really evil. Worst so far: intervals of 1 second KSP at normal speed. And the game freezes for half a second. While my CPU and GPU idles.

I think the code needs an overhaul. Just before I quick saved while having a program running. End of this song was that I had to delete the vessel manually from the persistent.sfs...

Did you have the ability to check memory usage when you were looking at CPU and GPU usage?

I've seen the same problem from other mods and I believe the common problem might be that a mod gets stuck in a never-ending loop that happens to be allocating some memory. If I'm right then what's happening is that when a mod causes KSP to run out of memory it then starts making major mistakes elsewhere in the program outside of the mod that end up saved in the persistence file. I've had half the parts on the ship just randomly disappear from existence when KOS gets stuck. The longer I leave it the worse it gets.

And since it's a 32-bit program, if you have a lot of RAM it doesn't necessarily need to use up all the memory of the machine - just use up as much as a 32-bit program can use (4GB).

This happens with the mismatched quote mark problem, for example. If KSP hangs because there's a mismatched quote mark in the KOS script, then behind the scenes the KOS mod is spinning in an infinite loop and if you leave it like that too long the state of the game gets really broken.

[yum]

log to isn't implemented in the official version as far as I know.

Seems to be working for me here.

//logger
clearscreen.
print "Attempting log" at (0,15).
set toLog to "X,Y,Z".
set difference to 0.001.
set lastLat to latitude + difference + difference.
set lastLong to longitude + difference + difference.

set shipHeight to 1.27. //input your ships height (alt:radar while on ground)

until 0 {
	set curAlt to altitude - (alt:radar - shipHeight). //should have named this ground elevation!
	if alt:radar = -1 { set curAlt to 0. }. //for when alt:radar bugs out...not sure why
	set curLat to latitude.
	set curLong to longitude.
	print altitude + " - (" + alt:radar + " - " + shipHeight + ")  " at (15,3).
	print "ELEVATION = " + curAlt + " m        " at (0,4).
	print "LAT       = " + curLat + " degrees  " at (0,6).
	print "LONG      = " + curLong + " degrees  " at (0,7).
	if abs(lastLat - curLat) > difference or abs(lastLong - curLong) > difference {
		set toLog to curLat + "," + curLong + "," + curAlt.
		print "Logging Active    " at (0,15).
		print "toLog     = " + toLog + "     " at (0,9).
		log toLog to logfile.
		print "Last log print: " + missiontime + "    " at (0,20).
		set lastLat to curLat.
		set lastLong to curLong.
	}.
	wait 0.5.
}.

Just log variable to filename.

If we had arrays and could read from the log...things could get more interesting.

Side note - alt:radar returns -1 seemingly randomly, anyone know why?

[check]

Side note - alt:radar returns -1 seemingly randomly, anyone know why?

alt:radar will return -1 when you're above 3500m from the ground or flying over deep ocean.

[yum]

@check

It doesn't seem to be consistent however. Sometimes I make it to 9000m before it freaks out (just flying around KSC). But you're right, definitely doesn't work over deep water.

Is there a reason why it fails? If we had more range, and could get elevation for arbitrary lat-long values, we'd have a working mapsat and could find ideal landing zones (low slope).

( hi from toronto! )

Edited September 27, 2013 by yum

[check]

@check

It doesn't seem to be consistent however. Sometimes I make it to 9000m before it freaks out (just flying around KSC). But you're right, definitely doesn't work over deep water.

Is there a reason why it fails? If we had more range, and could get elevation for arbitrary lat-long values, we'd have a working mapsat and could find ideal landing zones (low slope).

( hi from toronto! )

Hmm, not sure then. If your program is dependant on radalt, you can have it switch from looking at alt:radar to altitude when alt:radar <0 (or when alt:radar > altitude for over water).

(Sup from London.)

[JewelShisen]

alt:radar will return -1 when you're above 3500m from the ground or flying over deep ocean.

I've had it be fine even as high as 10000m

[check]

I've had it be fine even as high as 10000m

Well then I'm not sure what it looks at then. I remember it freaking out when I was above 4000m or so so I assumed it went by the gauge limit of 3500 (or is it 3000?) in IVA and just wrote my code based on that assumption.

[JewelShisen]

Well then I'm not sure what it looks at then. I remember it freaking out when I was above 4000m or so so I assumed it went by the gauge limit of 3500 (or is it 3000?) in IVA and just wrote my code based on that assumption.

No clue. I know mine was for a test program I was making to land a probe. I was having to write it to account for Kerbin's gravity rather than Duna (Where the probe will be landing for real)

[yum]

@check

Yeah that would work for most programs, but my program calculates ground elevation and is dependent on both

altitude - (alt:radar - shipHeight) where shipHeight is just alt:radar when the ship is on the ground.

For now I'll just pretend it's a real LIDAR without a large range, and keep my altitude low when scanning.

[JewelShisen]

Check has inspired me to make my own kOS powered missile!!!

and a flight program!

declare parameter targ.
clearscreen.
set targalt to 500.
set target to targ.
set turn to target:heading.
set pitch to ( ( targalt - alt:radar ) / targalt ) * 90.
lock steering to heading turn by pitch.
lock throttle to 1.
stage.
print "Starting Countdown.".
set i to 10.
until i = 0 {
print i + "...".
set i to i - 1.
wait 1.
}.
print "FIRE!".
stage.

print "Distance to target:".
print "Current Pitch:".
print "Radar Alt:".
until target:distance < 1500 {
set pitch to ( ( targalt - alt:radar ) / targalt ) * 90.
print target:distance at (22,12).
set turn to target:heading.
print pitch at (18,13).
print alt:radar at (14,14).
}.

unlock throttle.
lock steering to target.

print "Final glide.".

wait until i = 1.

[Dunbaratu]

@check

Yeah that would work for most programs, but my program calculates ground elevation and is dependent on both

altitude - (alt:radar - shipHeight) where shipHeight is just alt:radar when the ship is on the ground.

Does anyone know the height of the launchpad? In order to measure the craft's height on the launchpad I'd have to know how much extra altitude the launchpad is adding above the ground.

[Dunbaratu]

Another trick you can do with the new logfile feature is to use it to write self-modifying code - because the KOS mod does not differentiate between log files and program scripts. They're all ".txt" files behind the scenes.

For example, the following works:

log "print x^2 ." to squared.
set x to 5.
run squared.
25
Program ended.

[JewelShisen]

Another trick you can do with the new logfile feature is to use it to write self-modifying code - because the KOS mod does not differentiate between log files and program scripts. They're all ".txt" files behind the scenes.

For example, the following works:

log "print x^2 ." to squared.
set x to 5.
run squared.
25
Program ended.

Next thing you know somebody will make HAL9000...

[yum]

Does anyone know the height of the launchpad? In order to measure the craft's height on the launchpad I'd have to know how much extra altitude the launchpad is adding above the ground.

Try the runway maybe?

Nice, self modifying code, I hadn't thought of that!

EDIT: Does that launchpad obliterator mod still exist?

Edited September 27, 2013 by yum

[Dunbaratu]

Unfortunately you can't use the self-modifying code idea to make a program that contains any literal strings in it, since Kosscript doesn't include a way to protect a quote mark inside a quote string, as far as I know. You can't say something like this:

log "print \"hello\". " to progfile.

Nor this:

set qmark to "\"".

set statement to "print " + qmark + "hello" + qmark + "." .

log statement to progfile.

or anything else that might let you do that. If anyone has any ideas let me know.

[razark]

It's a pain, but:

In the modifying program:

log "print h + e + l + l + o." to modified.

In the modified program:

set h to "h".

set e to "e".

set l to "l".

set o to "o".

[Bizz Keryear]

Did you have the ability to check memory usage when you were looking at CPU and GPU usage?

I've seen the same problem from other mods and I believe the common problem might be that a mod gets stuck in a never-ending loop that happens to be allocating some memory.[...]And since it's a 32-bit program, if you have a lot of RAM it doesn't necessarily need to use up all the memory of the machine - just use up as much as a 32-bit program can use (4GB).

[...]

Well I just checked this with a vessel on the way to mün. ... The Mem usage goes (very) slowly up. I assume it is on command. But I have to validate that.

KSP begins with ~2,600,000k on my computer at 2,646,588k the stutter becomes noticeable, but its still playable. Funny thing: after a while of a short stops and only short normal periods there comes a time where almost no stop is only to get much worse afterwards. At ~2,670,000k it gets real laggy. And in the moment I end the program KSP works fine again, even though the mem usage does need a while to change.

Its definitly a overflow of some mem or buffer. But not the ksp reserved in general. (Also otherwise KSP would crash, I know that firsthand)

Seems to be working for me here.

//logger
clearscreen.
print "Attempting log" at (0,15).
set toLog to "X,Y,Z".
set difference to 0.001.
set lastLat to latitude + difference + difference.
set lastLong to longitude + difference + difference.

set shipHeight to 1.27. //input your ships height (alt:radar while on ground)

until 0 {
	set curAlt to altitude - (alt:radar - shipHeight). //should have named this ground elevation!
	if alt:radar = -1 { set curAlt to 0. }. //for when alt:radar bugs out...not sure why
	set curLat to latitude.
	set curLong to longitude.
	print altitude + " - (" + alt:radar + " - " + shipHeight + ")  " at (15,3).
	print "ELEVATION = " + curAlt + " m        " at (0,4).
	print "LAT       = " + curLat + " degrees  " at (0,6).
	print "LONG      = " + curLong + " degrees  " at (0,7).
	if abs(lastLat - curLat) > difference or abs(lastLong - curLong) > difference {
		set toLog to curLat + "," + curLong + "," + curAlt.
		print "Logging Active    " at (0,15).
		print "toLog     = " + toLog + "     " at (0,9).
		log toLog to logfile.
		print "Last log print: " + missiontime + "    " at (0,20).
		set lastLat to curLat.
		set lastLong to curLong.
	}.
	wait 0.5.
}.

Just log variable to filename.

If we had arrays and could read from the log...things could get more interesting.

Side note - alt:radar returns -1 seemingly randomly, anyone know why?

OK, I missed that, since it wasn't included last time I was a bit sloppy on the manual, so i missed the to no wonder it wasn't working. Good thing we have spoken about that.

alt:radar will return -1 when you're above 3500m from the ground or flying over deep ocean.

Why? That's a k-OS limitation isn't it? I mean Steamgauges is showing radar:alt up to 20k.

Another trick you can do with the new logfile feature is to use it to write self-modifying code - because the KOS mod does not differentiate between log files and program scripts. They're all ".txt" files behind the scenes.

For example, the following works:

log "print x^2 ." to squared.
set x to 5.
run squared.
25
Program ended.

The only problem is that you have to delete the file for each edit and you cant read the file either.

Unfortunately you can't use the self-modifying code idea to make a program that contains any literal strings in it, since Kosscript doesn't include a way to protect a quote mark inside a quote string, as far as I know. You can't say something like this:

log "print \"hello\". " to progfile.

Nor this:

set qmark to "\"".

set statement to "print " + qmark + "hello" + qmark + "." .

log statement to progfile.

or anything else that might let you do that. If anyone has any ideas let me know.

Thought of simple quotation marks (or whatever that is called in English) but that also doesn't work.

edit: Propose on github your own C code that is has escaping characters...

Edited September 28, 2013 by Bizz Keryear

[togfox]

Im assuming this doesnt do orbit calculations automatically? Like, i cant say "transit duna" and it works that out? I assume ive got to do my own math and work out my own thrust points?

[JewelShisen]

Im assuming this doesnt do orbit calculations automatically? Like, i cant say "transit duna" and it works that out? I assume ive got to do my own math and work out my own thrust points?

You are correct!