kOS Scriptable Autopilot System 0.9

[Sacred Aardvark]

No go on v0.85. Syntax Error on line 2.

Line 2 is a blank line.

Program runs fine in 0.71.

Also programs that would run just fine on 0.84 now exhibit the same behavior.

syntax error on random line number.

Shy of inserting a print statement after every line, there is no way to debug this.

EDIT: That wont work either. I set line 0 to...print "passed".

I still get the same error and it never prints passed.

Since it runs fine in 0.71 it probably isn't the same problem, but I had issues with perfectly fine commands throwing syntax error in 0.71, possibly due to excessive variable length. i.e. "set finalOrbitalHeight to 100000." didn't work, but changing it to "set Height to 100000." made it work. I also had a print "30" at(30,30). which gave a "unknown variable ' "30" at(30,30) ' error, deleting and retyping said line fixed it. Try deleting said blank line and see if it'll work. Beyond that, the code might help with troubleshooting, and help verify the problem isn't localized to your installation.

[edit] I'm assuming the code in question is your space computer, tried out the ascent script and it gave me a syntax error on line 4, regardless of whether the line was empty or had a command in it.

[edit 2] Further investigations; I had some issues with 0.71 with lines long enough to cross the border of the screen, scrolling past the screen caused random bits of lines appear in wrong places, which seemed to cause syntax errors, so I tried shortening the lines and removing the comments in your space computer ascent script. That resulted in the syntax error jumping from line 4 to line 0. The display issue with going past the screen edge seems to be fixed in 0.85, and my own script is giving a syntax error on line 0 as well, so it's probably unrelated to the crossing of the screen edge thing in 0.71. (though I've no idea why your ascent script even works in 0.71, since if I typed that long lines it went potty, but yours works fine in my .71 )

[edit 3] Should probably mention the tests were done in the sandbox not career, in case it has any bearing on anything.

Edited October 24, 2013 by Sacred Aardvark

[KevinLaity]

Both of these set up a trigger that will be executed when the condition is met.

Then the program ends, and the triggers it set up are wiped out.

You can run either of these lines outside of a program, and they should work. Or, you can set up a program such as:

WAIT UNTIL ALTITUDE > 69999.
TOGGLE AG10.

This sets up a waiting condition, and execution of the program will wait until that condition is true before stepping to the next line. (Of course, this means that your program will not do anything else until then. There are other ways to set it up, too.)

I wonder if there's a way to have a warning that's like "Hey, you set up a trigger just before a program ended".

[KevinLaity]

Some questions please:

1. How do I target bodies?

2. How do I lock my steering to node? "lock steering to node" doesn't work, as it doesn't seem to recognize "node".

For #1, there's no support for that yet. It's something I haven't gotten around to.

For #2, locking steering to a node should work, but I believe the node needs to be added first.

SET x TO NODE(A,B,C).

ADD x.

LOCK STEERING TO x. // or.... LOCK STEERING TO NEXTNODE. because you've added it and NEXTNODE represents the active node that you see on the GUI

// Later on when you want it gone...

REMOVE x. // or... REMOVE NEXTNODE.

Or create the node though other means and use NEXTNODE. But I'll fire it up tonight and test it.

[KevinLaity]

Kevin, how's updating to .22 going?

Very well! 0.85 is out which is built on 0.22. (I realize you posted this before then)

I didn't come up with any 0.22 specific problems in my testing. I'm waiting to see how things go for the community.

[KevinLaity]

Having peeked at the github code it looks like there is a calculation that makes electrical drain depend on clock speed. The faster the clock rate the faster the electrical drain. But you don't notice that this calculation is taking place because currently there's only one kind of CPU with one hardcoded clock speed. It seems as if the groundwork is there to be able to support multiple different speeds of CPU in the future.

Correct! And at the current 5x speed, it uses the same power that it did before I made that change.

In the future you'll be able to overclock your CPU at the cost of power.

[KevinLaity]

I've perused the wiki but I'm having trouble finding an answer.

When a craft unloads, the code its running ceases to function and does not restart with the computer when it is reloaded later on. Is there any way to modify or replace that startup functionality to have codes run when the craft loads? Such as to ensure a space station remains properly oriented to its parent planet or to keep a long-range missile on target.

Well my intent is to have everything persist, including which program you have loaded and where you are in the execution of that program. It's not something I'm looking forward to coding.

Issuing a command that does an autoexec when a craft loads sounds like a good stop-gap. I may look into that soon.

[Camacha]

Very well! 0.85 is out which is built on 0.22. (I realize you posted this before then)

I didn't come up with any 0.22 specific problems in my testing. I'm waiting to see how things go for the community.

Welcome back! Thanks for this amazing work and - of course - don't forget to have fun

In the future you'll be able to overclock your CPU at the cost of power.

That sounds pretty cool. So at the expense of a lot of power directly controlling your rocket might become feasible? As in, coding full on guidance instead of locking to a heading?

Edited October 24, 2013 by Camacha

[Sacred Aardvark]

Okay, I'm giving up for now. I can't find the problem with my code. Sure, it ain't the neatest thing, but a line 3 syntax error isn't one of it's faults as far as I can tell. Fresh pair of eyes might help, so if anyone can shed light on why this code would work with KSP 0.21.1 and kOS 0.71, but not with KSP 0.22 and kOS 0.85, it'd be appreciated

code nuked, problem apparently figured out bit lower. {} bug out if spanning lines

I'm pretty sure my code is inefficient, possibly silly and definitely hastily commented but a moment ago, so I don't know if it makes any sense. The indentation is a bit random as well due to being coded partially with kOS IDE and then partially rebuilt ingame while figuring out what works in practice and what doesn't. Still, it works in an older version, so is there some syntax change I've might have missed between 0.71 and 0.85?

Edited October 25, 2013 by Sacred Aardvark

[razark]

I wonder if there's a way to have a warning that's like "Hey, you set up a trigger just before a program ended".

I think that would be good to have. Also, a way to list active triggers and a way to clear them would be useful.

[Dunbaratu]

Well my intent is to have everything persist, including which program you have loaded and where you are in the execution of that program. It's not something I'm looking forward to coding.

Issuing a command that does an autoexec when a craft loads sounds like a good stop-gap. I may look into that soon.

How about, along similar lines, if it runs when you toggle power off and on on the unit?

[Sma]

- For nodes, :DELTAV:MAG now works correctly. Note that :DELTAV is now effectively the same as :BURNVECTOR

Is it just me? I can't help but laugh every time I see this line. Even on the spaceport page. :DeltaV lol I guess we can be excited that :DELTAV:MAG works. Though I haven't tried it yet because science.

[Dunbaratu]

0.85 broke multi-line parenthesized expressions. Now you can't open a parenthesis on one line and then close it on a later line. The closer has to be on the same line as the opener now. For example:

set x to (
  ( 100 - 50 )  / ( 30 - 10 ) * 1.01
  ).

That gives a syntax error now. It didn't before. If I join it all together onto one line like this:

set x to (  ( 100 - 50 )  / ( 30 - 10 ) * 1.01  ).

Then it works. But it makes it a lot harder now to make long complex math expressions that look readable. Now they have to be strung together all on one line.

[Payload]

By systematically testing my program line by line in a new file, I have narrowed down my problem to a certain block.

Well, at least one of the problems anyway. I have written a test block that I have been trying to get to work. This errors the whole block without executing anything as far as I can tell.

It doesn't even clear the screen much less print "hello".

clearscreen.
print "hello".
set go to 0.
set tOrbit to 100000.
set hAtmo to 69500.
set hAlt to tOrbit - 5000.
when apoapsis > tOrbit then
 {
 set tThr to 0.
 toggle ag5.
 until altitude > hAtmo
  {
  if apoapsis < hAlt { set tThr to .1. }.
  if apoapsis > tOrbit { set tThr to 0. }.
  }.
 }.
wait until go = 1.

Edited October 25, 2013 by Payload

[Sacred Aardvark]

0.85 broke multi-line parenthesized expressions. Now you can't open a parenthesis on one line and then close it on a later line. The closer has to be on the same line as the opener now. For example:

set x to (
  ( 100 - 50 )  / ( 30 - 10 ) * 1.01
  ).

That gives a syntax error now. It didn't before. If I join it all together onto one line like this:

set x to (  ( 100 - 50 )  / ( 30 - 10 ) * 1.01  ).

Then it works. But it makes it a lot harder now to make long complex math expressions that look readable. Now they have to be strung together all on one line.

Thank you! The issue seems to be bigger and affecting all multi line expressions.

By systematically testing my program line by line in a new file, I have narrowed down my problem to a certain block.

Well, at least one of the problems anyway. I have written a test block that I have been trying to get to work. This errors the whole block without executing anything as far as I can tell.

It doesn't even clear the screen much less print "hello".

This version of your code works(in the sense that it doesn't give an error), just slapped the whole bit between {} into one line:

this really really didn't want to display properly so f-it.

:|

[edits 1, 2 and 4.] okay the code doesn't want to display as it should, but there shouldn't be line breaks between "when" and the last }. making a really long line if one was to spend a whole program in a loop.

[edit 5] Yeah, went and changed my own script to put everything between {} into one line, which was about 4/5 of the whole thing. It works now, but is a bit of a bitch to read through a single 2000 character line

[edit 6] Thank god for edit, I really need to start gathering stuff together before posting Just noticed that while the script works, the game is running really really slow when it's running, though it ran fine in 0.71, and my print commands are showing 11 to 15 decimal points for altitude, speed and fuel, when before they would show 4 decimals. Was this changed somewhere between 0.71 and 0.85?

Aaand it apparently ends in a flagrant error on line 0 after all, just before completion. Probably messed something up while combining everything into one monster line to get it started. :|

Edited October 25, 2013 by Sacred Aardvark

[Dunbaratu]

A warning about the new comm antenna from the KSP 0.22 update.

I just discovered the hard way that the new 0.22 antenna, called the Comms DTS-M1, is not yet implemented in KOS's code. If you add them to your vessel expecting to be able to reach the archive with them, it won't work. I assume this will be addressed eventually, but for now it's a good idea to avoid them.

[Dunbaratu]

Very well! 0.85 is out which is built on 0.22. (I realize you posted this before then)

I didn't come up with any 0.22 specific problems in my testing. I'm waiting to see how things go for the community.

Do you have any thoughts on how KOS will be integrated into the tech tree for career mode? (Right now you have to be playing a sandbox game to have access to the SCS module.)

[aNewHope]

Compatibility update for 0.22 ? Niiicee! If my SSTO launch program still works, I'll upload it soonâ„¢.

Which features will be added next?

I really'd love to see actual thrust output of your rocket (would solve all asparagus problems and'd be very helpful at all).

Getting more info about your post-node trajectory would be very cool as well (Pe, Ap, etc...).

I really love this mod. Keep up the good work Kevin!

And don't stress yourself tooo much.

[Dunbaratu]

Compatibility update for 0.22 ? Niiicee! If my SSTO launch program still works, I'll upload it soonâ„¢.

Which features will be added next?

I really'd love to see actual thrust output of your rocket (would solve all asparagus problems and'd be very helpful at all).

I assume there's a reason that (maxthrust * current throttle setting) doesn't give you your current thrust? I've been using this pretty reliably but never in a context with asparagus staging. Is there something about asparagus staging that breaks using that as a calculation?

Getting more info about your post-node trajectory would be very cool as well (Pe, Ap, etc...).

I've been working out the math for how to get the location of the Pe, Ap, and intercept with planet surface, and it is doable right now, but only by being *extremely* roundabout with how you arrive at the calculations. It would help to have that information more "natively".

1. It is possible to transform any of the script language's Euler rotation directions (like "up", for example) into a unit vector in XYZ terms instead. It requires running some matrix math that would make a lot more sense to do natively in C# instead of as lines of KOSscript but it is doable.

2. It is possible to work out your current normal vector (and therefore your angle of inclination from the body's equator) from your velocity vector cross product'ed with the unit vector version of your current Up direction.

3. It is possible to work out your current true anomaly angle (the angle between the periopsis of your elliptical orbit and your current location in the orbit) from comparing your current radius (altitude plus body radius) to the major axis of the ellipse (Ap height plus Pe Heght, plus diameter of body).

4. Because you know your current Up vector, and your current altitude and can look up the radius of the SOI body, you do essentially have your current position, but expressed in polar coordinates instead of in Cartesian coordinates.

5. Putting it all together should fix the exact picture of your current orbital ellipse, including where Ap and Pe are, where your impact with the Planet is, and so on.

I have page after page of scribbled equation notes doing all that, BUT, it really feels like this is unnecessary work because I'm pretty sure the underlying API must have more information about your current predicted orbital ellipse than KOSscript is currently exposing to the user.

As part of my attempt to make the landing script better, I'm trying to work out all that math with one goal in mind: Find the LATLONG of my current predicted impact point on the planet. If I have that, then I can use it as the beginnings of making an "aimed" landing.

[aNewHope]

Is there something about asparagus staging that breaks using that as a calculation?

The problem with asparagus is, that when one stage is out of fuel, all engines are still active --> maxthrust gives the value of ALL engines combined, not thrust of currently working engines. Also there is the problem with turbojets, whose thrust is also dependent on speed and IntakeAir.

In theory it should be quite easy to get the real thrust, due to the fact that by right clicking the engine you get the exact current thrust.

I've been working out the math for how to get the location of the Pe, Ap, and intercept with planet surface, and it is doable right now, but only by being *extremely* roundabout with how you arrive at the calculations.

Yeah, I have worked with some of the equations as well (probably not quite as many). For example, it's very easy (and accurate) to do the maths on prograde and retrograde burns. I use this to calculate my ∆V for Hohmann transfers and orbit circularization:

Hopefully Kevin will add post-node readouts soon. It would save so much work.

[Dunbaratu]

The problem with asparagus is, that when one stage is out of fuel, all engines are still active --> maxthrust gives the value of ALL engines combined, not thrust of currently working engines.

Presumably in an asparagus staging that's exactly the moment when you want to detach the dead weight, so it's only going to be incorrect for the few brief moments before you activate the next stage.

Well, in the meantime until such a feature exists, here's an idea that might help:

The real problem that you need a way to detect when an engine has become starved of fuel so you know when to activate the stage. If you knew that then you wouldn't need to deal with calculating the max thrust with starved engines because you'd be getting rid of the starved engines as soon as they got starved.

Here's an idea that might work - detect and record the rate of mass change as you burn. In a loop, keep track of the difference in mass between consecutive iterations, and the delta of missiontime it took to perform the iterations.. As long as the only reason you're losing mass is that you're burning fuel (you haven't activated any stages to drop off parts), and as long as the same number of engines are burning fuel, then the throttle setting divided by the mass loss rate should remain constant or close to constant (i.e. the mass loss at throttle 1.0 will be twice what it was at throttle 0.5, so the expression (throttle/massloss) should remain constant regardless of the throttle setting as long as the throttle is nonzero.)

So it might be possible to use that to detect when an engine has stopped burning fuel. The rate of mass loss should be expected to fluctuates a little bit (due to slight variances in how long it takes to execute KOSscript commands. The time between when you measured missiontime and when you measured mass in the next command will never be exactly the same). But even though it's normal for it to fluctuate a little bit it wouldn't be normal for it to suddenly drop a LOT in one instant. That's the trigger you look for. If the rate of mass loss suddenly changes by more than a fuzzy small tolerance, then assume this is because fewer engines are burning than previously were, so it's time to decouple a stage.

That doesn't help your other issues with jet engines, but it might help make asparagus staging work for vanilla rocket engines.

Edited October 26, 2013 by Steven Mading

[aNewHope]

Well, in the meantime until such a feature exists, here's an idea that might help:

Thanks! I never thought of using the mass-change to detect stage burn out. I'll try it out.

PS: kOS .85 is still quite buggy. For example there is no way of getting this piece of code to work (Always gives an error message):

when eta:apoapsis < (DV/(2*acc) + 30) then {set warp to 1.
when eta:apoapsis < (DV/(2*acc) + 15) then {set warp to 0.}}

DV is the ∆V needed for a burn. Acc the acceleration my craft has under full throttle.

Edited October 27, 2013 by aNewHope

[Sacred Aardvark]

For example there is no way of getting this piece of code to work (Always gives an error message):

when eta:apoapsis < (DV/(2*acc) + 30) then {set warp to 1.
when eta:apoapsis < (DV/(2*acc) + 15) then {set warp to 0.}}

DV is the ∆V needed for a burn. Acc the acceleration my craft has under full throttle.

Give this a go:

when eta:apoapsis < (DV/(2*acc) + 30) then {set warp to 1.  when eta:apoapsis < (DV/(2*acc) + 15) then {set warp to 0.}}

If the code tags bug out again, I simply deleted the line break and that got it working on my comp (after consequently adding set dv and set acc commands prior to it). 0.85 doesn't seem to like it when you close a parenthesis (or brace, probably not brackets either) on a different line than it's been opened on.

[Mzxs]

are you able to add a new volume?

[Sacred Aardvark]

are you able to add a new volume?

You can make a ship with multiple volumes, but AFAIK you can't add volumes to ships that are on the pad or air-/spaceborne. (well, maybe with KAS, if it plays nice with this)

Further details

http://kos.wikia.com/wiki/Archive_and_Volumes#Multiple_Volumes_on_one_Vessel

Edited October 28, 2013 by Sacred Aardvark

[Dunbaratu]

Thanks! I never thought of using the mass-change to detect stage burn out. I'll try it out.

PS: kOS .85 is still quite buggy. For example there is no way of getting this piece of code to work (Always gives an error message):

when eta:apoapsis < (DV/(2*acc) + 30) then {set warp to 1.
when eta:apoapsis < (DV/(2*acc) + 15) then {set warp to 0.}}

DV is the ∆V needed for a burn. Acc the acceleration my craft has under full throttle.

I assume this was meant to originally be formatted like so, but you had to join the lines to avoid the other bug?

when eta:apoapsis < (DV/(2*acc) + 30) then {
  set warp to 1.
  when eta:apoapsis < (DV/(2*acc) + 15) then {set warp to 0.}
}

Is there a reason it doesn't work to have those as two separate conditions at the same level without nesting?

when eta:apoapsis < (DV/(2*acc) + 30) then { set warp to 1. }
when eta:apoapsis < (DV/(2*acc) + 15) then { set warp to 0. }

It should work provided that you know the first condition will always happen prior to the second condition.