[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Hans Dorn]

Since I did the complete terminal velocity calculation in the above post, guess I'm excused in the future

I'm getting at the exact same result.

cheers

[S.O.P.H.I.A.]

the problem is fixed with release 0.12P1

I've been having this exact same problem, where I get flagrant errors whenever I try to get engine stats. Can you tell me how to get .12P1? I can't find it on the github site.

Also, I have two questions. I'm pretty new at this, so I don't know if they're super trivial or insanely complicated.

First: What is the best way to determine if my airplane is upside-down? (I'm making a vtol, and I want the engines to cut out if I flip over so I don't jet downwards).

Second: What is the best way to determine if I'm moving sideways relative to my current facing? So if, for example, my nose is facing North, how do I determine my east/west speed? (similarly, it would be useful, but not as useful to me, to determine my forwards/backwards speed relative to my facing).

Thanks!

Edited March 16, 2014 by S.O.P.H.I.A.

[Camacha]

Really? That's a bit too ... Mechjeb. I'd rather have the components that go into the calculation than the final result of it. We're supposed to be writing the autopilot ourselves here.

I hear you and very much agree. You should be enticed to investigate what terminal velocity actually is to build a nice script for it

[Hans Dorn]

I'm doing this for staging right now:

// set up fuel levels for staging
set f_lev to list().
set f_lev:add to 4*360.
set f_lev:add to 360.
set f_lev:add to 0.01.


... snip...

// inside control loop:
// staging
if ship:liquidfuel < f_lev#0 { // check first entry of list
	stage.
	if f_lev:length > 1 {
		set f_lev:remove to 0. // remove first entry
	}.
}.

Not as versatile as iterating through your engines, but pretty fast.

Cheers.

[Jordansinn]

Is there anyway to get this working with Remote Tech 2? Both mods say they have some sort of integration however when out of RT2 communication range kOS is unable to alter steering or throttle.

[Camacha]

Is there anyway to get this working with Remote Tech 2? Both mods say they have some sort of integration however when out of RT2 communication range kOS is unable to alter steering or throttle.

There still seem to be some kinks in the interoperation between the two

[S.O.P.H.I.A.]

Oh, I had an idea. It would be awesome if, in addition to .txt's, kOS could open a unique file type (ex. .kos). if you typed 'run xScript' in the console and there was an xScript.txt and a xScript.kos, it would prioritize the .kos for simplicity.

The main benefit would be that you could set a different default program to edit .kos files, such as notepad++ or one of the dedicated kOS editing programs, and notepad++ could then detect the file being used and use the default user-defined language for it (because really, most of us probably have one that we slapped together).

[Camacha]

The main benefit would be that you could set a different default program to edit .kos files, such as notepad++ or one of the dedicated kOS editing programs, and notepad++ could then detect the file being used and use the default user-defined language for it (because really, most of us probably have one that we slapped together).

I am not sure I understand you. Are you proposing some kind of version management? Because I think the Saturn IDE was going that way too.

[Jordansinn]

What is the unit id for?

[Dunbaratu]

I am not sure I understand you. Are you proposing some kind of version management? Because I think the Saturn IDE was going that way too.

No. It's saying give it a unique filename suffix because of how many programs there are out there that use the filename suffix to identify what type of file it is. Programmer's text editors tend to do that to decide what syntax to expect in the file for color highlighting purposes.

Calling them .txt tends to make them just generic ascii text, which makes it hard to define special syntax highlights for them without those rules also ending up being applied to all other ascii text files too.

[Camacha]

Ah, right. As long as we can also keep everything working with .txt, I do not see any objections.

[Kethevin]

I've been practicing landing programs on Kerbin.

What I typically do is set a maneuver node on the opposite side of the planet from where I plan to land, lowering the periapsis to a point where the atmosphere helps ensure I land close to where I am targeting.

I've gotten good with a script to execute the node itself but I'm wondering what the best way (if any) of setting something up so that K-OS can create the node. It's often in an area with my first landing, so I have nothing specific there to target.

[aNewHope]

Hi there,

a few months ago I have written a kOS launching program. It worked very well, but then a new KSP version came out and I forgot about kOS and the program. Now that Erendrake is working on this new version of kOS (thank you very much, your work is awesome), I have used the last two weeks to update for the current version and make it usable with FAR (now it's almost only usable with FAR). It works almost perfect, uses a correct gravity turn trajectory (follows surface:prograde very closely) and utilizes maneuver nodes to complete its orbit.

So here it is, just for you:

staging doesn't works with kOS 11.1 !

kOS programs

Javascript is disabled. View full album

PS.: It works by using a lot of sub-programs. L1 is the master-program. Run it with the parameters

(your orbit altitude in m, launch inclination (0 = east; 90 = north; etc.), number of stages on your rocket).

Edited March 22, 2014 by aNewHope

[frencrs]

@SBaL: wrap the two IFs with a loop, something like "until false { .... }". Oh, and add parenthesis to the expressions, they work like they should most of the time but there may be some weird behavior with operator precedence.

marianoapp, do you have a copy of the grammar and syntax you're using for "the_merge" branch? I'm trying to get more familiar with your changes.

[marianoapp]

marianoapp, do you have a copy of the grammar and syntax you're using for "the_merge" branch? I'm trying to get more familiar with your changes.

Actually the new version is not based on that branch, the code is in the new github organization here.

The grammar and syntax of the language remain the same, the changes were made in how that language is interpreted and executed. Anyway we now use a formal grammar to describe the language, and you can find it here.

[frencrs]

Actually the new version is not based on that branch, the code is in the new github organization here.

The grammar and syntax of the language remain the same, the changes were made in how that language is interpreted and executed. Anyway we now use a formal grammar to describe the language, and you can find it here.

Awesome, thank you!

[erkha343]

hmm, does the line "lock steering to node." not work in this version? It doesn't work for me...

[Dunbaratu]

Awesome, thank you!

Are there plans of a new development release soon? The fix for the bug with ship:solidfuel is done according to github but I don't have the development environment set up to compile the source myself. I'm waiting on ship:solidfuel before I continue the work on the mission I'm trying to tweak. (I'm trying to make my generic do-everything ascent script handle asparagus staging even when the ship has a combination of liquid and solid fuel. Because it's doing asparagus staging, using stage:solidfuel (which does work) isn't good enough for my needs, as asparagus staging tends to confuse the mod's calculation of what qualifies as being "part of this stage". Because there's decouplers connecting to parts of the ship that are currently active it's not clear what the "right" answer is about that, so I just want to use the ship's total fuel to calculate the fuel loss rate.

(The key to my asparagus algorithm is that if I haven't changed the throttle setting and yet I notice a sudden drop in how fast the fuel is disappearing, I assume that must be because one or more engines have run dry, so that's what means its time to hit the next stage button. When I wanted to add support for solid boosters I realized that essentially, strapping solid boosters on the side of a liquid rocket is so similar to asparagus staging that I should be able to use the same algorithm for both. The key to the staging activator on asparagus staging is the need to support the idea that you shouldn't wait for all the engines to run dry to hit "stage", but instead just hit strange when at least some engines have stopped. And that's basically also what you're doing when you peel off solid boosters from the side of a liquid engine stage.)

[Dunbaratu]

hmm, does the line "lock steering to node." not work in this version? It doesn't work for me...

"nodes" are now structures containing many 'suffix' components. To steer in the direction of the node you need to "lock steering to node:deltav". Node:deltav is the vector of the total delta V that comes from summing together the prograde, radial out, and normal components of the node.

[erkha343]

"nodes" are now structures containing many 'suffix' components. To steer in the direction of the node you need to "lock steering to node:deltav". Node:deltav is the vector of the total delta V that comes from summing together the prograde, radial out, and normal components of the node.

Thanks mate, something else...

I'm making a simple script to LKO. It runs perfectly until it's time for the circularization burn...

wait until apoapsis >80000.

lock throttle to 0.

lock steering to prograde.

print "Gravity turn end.". wait 2.

print "Coasting to Ap.".

wait until eta:apoapsis <30.

print "Begining circularization burn.".

lock throttle to 1.

wait until periapsis >80000.

lock throttle to 0.

print "Launch complete, vessel in 80km LKO.".

It works well, the periapsis is 80km, but the apoapsis burns to >300km. How do I do some kind of If statement so that it makes an eccentric 80km orbit?

[erendrake]

Are there plans of a new development release soon?

Done! https://github.com/KSP-KOS/KOS/releases/tag/v12.0P2

[marianoapp]

It works well, the periapsis is 80km, but the apoapsis burns to >300km. How do I do some kind of If statement so that it makes an eccentric 80km orbit?

The problem is that as soon as your periapsis is higher than your apoapsis the periapsis becomes the apoapsis and that's why the "wait until periapsis > 80000" statement doesn't work as expected.

This subject was discussed previously, starting from this post.

[Dunbaratu]

Why would I get the ouput

AAA
Variable mysteer* is not defined
Instruction 588

From this part of my code:

print "AAA".
set mysteer to up.
print "BBB".

I put the print statements in there to try to narrow down where the error message was being produced. It prints AAA but not BBB, thus making me think it's coming from the statement "set mysteer to up."

But... of *course* mysteer isn't set. That's why I'm trying to set it.

Also, weirdly, I don't know where the asterisk is coming from in the error message. It doesn't seem to be there in the line of source code in github that builds the exception message, making me think it's actually trying to look up a variable name that includes an asterisk in the variable name, for some reason, even though that's not in my script code anywhere.

I could provide the entire script for you to run if it would help, but it's a lot of pieces to post and so I'd prefer to put it on pastebin or google drive than paste it in the forum.

[marianoapp]

Variables with asterisks are function pointers used by locks, so I'm betting you are locking mysteer to an expression somewhere on the script. We'll have to find a way to deal with this identifiers that are used both as variables and locks in the same script.

[Dunbaratu]

Variables with asterisks are function pointers used by locks, so I'm betting you are locking mysteer to an expression somewhere on the script. We'll have to find a way to deal with this identifiers that are used both as variables and locks in the same script.

Does it parse through the entire script first and therefore decide that mysteer is used in a lock somewhere, then go back and actually run the script? I ask because while it's true that I do also lock mysteer, I don't do it until later, further down, after the line where the error is coming. FIRST I use 'set' with mysteer and then don't change to using 'lock' until later.

Hm.. Well, I just ran the following test script and it seems to prove that yeah if there is a lock anywhere in the script, even in the "future", then it retroactively messes up "sets" that occur on the same variable earlier. (So I presume there must be some sort of pre-parsing going on or that would be impossible).

print "Before setting.".
set thingy to "some set val".
print "After setting.".

print "Before locking.".
lock thingy to "some locked val".
print "After locking.".

Output:

Before setting.
Variable thingy* is not defined
Instruction 10.

At least now that I know what's causing it I can go through and fix it by essentially making sure that if a variable ever gets used with 'lock', that it always gets used with "lock" everywhere even in places where the value is an unchanging constant.

Edited March 21, 2014 by Steven Mading