[1.3] kOS Scriptable Autopilot System v1.1.3.0

[madlemur]

Ummm...

SET MyEngine TO <however you get your engine>.

LOCK MyISP to MyEngine:ISP.

Now, MyISP will recalculate either every update, or once every update that it's read.

Which Wiki were you reading? I suggest you use the documentation site, which is pretty good (and includes ISP). In fact, the example at the beginning of the engine section steps through all the engines, and gives their ISPs.

Edited August 28, 2014 by madlemur
Adding documentation links

[postalbyke]

I don't "<however i get my engine>", usually I maxthrust, thrust, stage:resource, add universal constants and do the math myself, but this one was a real pickle...

Thanks for the tip, I'll head over there now!

[postalbyke]

So if I want the Isp of the engine I am currently using, I have to tell the program to go and get every engine, then figure out which one I'm using (by stage or ignition), then get the Isp for that engine? Or just scan the list for a non-zero Isp... hmm...

edit: messy but effective. I try not to loop "unnecessarily," but I will accept this begrudgingly

Edited August 29, 2014 by postalbyke

[Drew Kerman]

kOS will eventually be able to access right-click fields. ISP is something shown in the right-click menu. So at some point you'll be able to use the partname to get the ISP of the specific part

[Dunbaratu]

So if I want the Isp of the engine I am currently using, I have to tell the program to go and get every engine, then figure out which one I'm using (by stage or ignition), then get the Isp for that engine? Or just scan the list for a non-zero Isp... hmm...

edit: messy but effective. I try not to loop "unnecessarily," but I will accept this begrudgingly

We were trying to come up with better querying methods for the LIST PARTS so you can do stuff like LIST PARTS IN MYVAR WHERE (condition), but sadly it looks like this would be no more efficient than just doing it in your own loop, as it would still work by the same sequential search under the hood.

[postalbyke]

Bummer. I had noticed that some other mods have access to the things I want (such as Engineer, etc.), and I had just hoped that I had missed something in the documentation. until then, I have a solution!

LIST ENGINES IN myVariable.

FOR eng IN myVariable

{

set Isp to eng:ISP.

if Isp > 0

{

break.

}.

}.

(This only works for single-engine stages, or craft with all the same engine type.)

Edited August 29, 2014 by postalbyke

[Dunbaratu]

If there was an abstraction that gave the ISP for the whole ship, what would you want it to tell you?

- the total highest ISP of any one engine, calculated among the ones that are active now, or calculated across the whole ship?

- the total lowest ISP of any one engine, calculated among the ones that are active now, or calculated across the whole ship?

- the weighted average ISP of all the engines, calculated among the ones that are active now, or calculated across the whole ship?

- the weighted average ISP of all the engines, calculated among the ones that are active now, and taking into account the fact that all the engines might not shut off together at the same time (asparagus) so it's weighted also by how long each would burn for?

And of course, if you're moving through the atmosphere, ISP changes as the air get thinner, so the ISP right now may not be the same as the ISP later on, making predictive calculations on it a bit messier.

Incidentally, you can calculate the rate of fuel loss that's occurring at the moment by, in a loop, comparing the current fuel left on the ship to the previous fuel left on the ship on the previous iteration, and compare that to the throttle setting you had during that moment and how long that moment took, to dynamically calculate your own ISP for the previous moment. I don't know if this suits your needs.

Now that I think of it, there's two types of fuel you're burning, liquid and oxidizer, and I don't even know which one the game's ISP numbers are calculating - the total sum of combined mass of both that's being burned? I guess if you're using it for DV calculations it would have to be that.

Edited August 29, 2014 by Steven Mading

[Lilleman]

Bummer. I had noticed that some other mods have access to the things I want (such as Engineer, etc.), and I had just hoped that I had missed something in the documentation. until then, I have a solution!

LIST ENGINES IN myVariable.

FOR eng IN myVariable

{

set Isp to eng:ISP.

if Isp > 0

{

break.

}.

}.

(This only works for single-engine stages, or craft with all the same engine type.)

You can try this if you want a more precise value (correct me if this is wrong):

set d_ISP to 0.
set d_FTot to 0.
set d_FISPTot to 0.
list engines in l_eList.
for eng in l_eList {
if eng:isp > 0 {
set d_FTot to (d_FTot + eng:maxthrust).
set d_FISPTot to (d_FISPTot + (eng:maxthrust / eng:isp)).
}.
 }.
if d_FISPTot > 0 {
set d_ISP to (d_FTot / d_FISPTot).
}
else {
set d_ISP to 0.
}.

[postalbyke]

@Steven Mading:

I couldn't focus once I'd quoted you so here goes without:

I'm looking for

"What is the (current effective) Isp for the current engine on the current stage?"

I use Isp, Thrust, and little g to predict fuel rate of the engine I'm using (in kg/s) (which rules out the units used for fuel and oxidizer, and reduces calculations required to check how much of each I'm going to need)

"Incidentally, you can calculate the rate of fuel loss that's occurring at the moment by, in a loop, comparing the current fuel left on the ship to the previous fuel left on the ship on the previous iteration, and compare that to the throttle setting you had during that moment and how long that moment took, to dynamically calculate your own ISP for the previous moment. I don't know if this suits your needs."

Using loops and comparing fuel levels can be inaccurate in their own way. Also, it takes time and processor away from the burn, which I'm trying to make more accurate.

"Now that I think of it, there's two types of fuel you're burning, liquid and oxidizer, and I don't even know which one the game's ISP numbers are calculating - the total sum of combined mass of both that's being burned? I guess if you're using it for DV calculations it would have to be that."

The Isp is the ratio of the velocity of the exhaust products to the acceleration due to gravity ASL on Earth. This avoids all the confusion about fuel and oxidizer, all you need to worry about is the mass leaving the ship thru the engine.

I try really hard to make rockets that are "realistic" or "practical." It hurts my head to see the asparagus and onion rockets fly. Typically I use the Isp while in orbit to ensure crisp burns.

In the case I had more than one engine doing a burn, I would probably make a program that calculates the delta vee and delta em contributions of each engine, and runs a burn accordingly.

[Dunbaratu]

@Steven Mading:

I couldn't focus once I'd quoted you so here goes without:

I'm looking for

"What is the (current effective) Isp for the current engine on the current stage?"

A general case solution, which is what kOS would have to be written to provide, not just a solution for your case, cannot use the word "the" here, as that makes it stop being general case and instead makes it only work if you design a rocket with one engine firing at a time. If there's more than one engine firing, then you either iterate over them yourself or you get one lump sum from kOS for all of them. If it has to be returned as one lump sum, should it be an average of their current ISP's?

What counts as "in the current stage" is a very messy algorithm in general, because people can use fuel lines and/or crossfeed to blur the dividing line between stages. At the moment, the definition kOS uses (for things like stage:liquidfuel) for "in the current stage" is to walk the parts graph starting from each currently active engine, truncating the walk at any point where a connection between parts is not crossfeed capable, and throwing away all the duplications (engine 1 sucking fuel from tank 12345 and engine 2 also sucking fuel from tank 12345 - both find the tank in their walks, but the tank should only count once), and summing up all fuel found during that walk.

Because that's the definition used, and it seems to match the definition KSP itself is using to calculate its little green bar graphs of fuel, the only sort of meaning "this stage" could have for ISP would be "all the engines that are currently active". Would this do?

"Now that I think of it, there's two types of fuel you're burning, liquid and oxidizer, and I don't even know which one the game's ISP numbers are calculating - the total sum of combined mass of both that's being burned? I guess if you're using it for DV calculations it would have to be that."

The Isp is the ratio of the velocity of the exhaust products to the acceleration due to gravity ASL on Earth. This avoids all the confusion about fuel and oxidizer, all you need to worry about is the mass leaving the ship thru the engine.

Jet engines have an ISP number as well, but take their oxygen from the atmosphere, not from the fuel tanks. So the assumption inherent in that sort of calculation, that all the mass being thrown out the engine at that velocity is mass that came from the ship's fuel being carried, doesn't hold for jets.

The ISP doesn't have units because it's actually measured lots of different ways to come to the same number. Another measurement is that it's a unit of time - the number of seconds that a given amount of fuel will last if being used to push steady at a particular constant force (how many seconds of thrust do you get from 1 kilogram of ship mass being thrown out the back (fuel being burned) at a throttle setting that pushes at only 1 Newton.) This is the calculation that's useful for calculating fuel consumption and how much DV can you achieve. But the problem is that I don't know what the game is using for this calculation in the case of jet engines where not all the output mass is coming from the ship's own input mass, and some of the output mass was sucked out of the atmosphere.

[postalbyke]

"It represents the force with respect to the amount of propellant used per unit time." (Wikipedia, specific impulse). I would hope that makes it easier to calculate. In fact, the loop method could come up with a close approximation for this.

I know that Engineer has a readout under "Vessel" that shows current Isp, I wonder if they couldn't be asked how it was accomplished.

Edited August 30, 2014 by postalbyke

[Dunbaratu]

It represents the force with respect to the amount of propellant used per unit time.

Which is the same figure I described. The reason it has no units is that all the units cancel out in the calculation as it's essentially a ratio that can be inserted into formulas in a few different ways.

The problem is over what KSP means by it, not what the real world means by it. Citing real world definitions won't alleviate that problem. In this case, I don't know which "propellant" they're counting - the sum of both? The sum of both only if it's NOT a jet, and just the liquidfuel if it is a jet? If you're using it to calculate how much dV you can achieve from it then you have to to answer that first. You have to know if it's exactly including the propellant *that is being carried on board* or if you have to fudge the numbers because it's also including propellant not carried on board (jets counting the oxygen) or failing to count propellant that is carried on board (rockets not counting the oxygen).

It's not "I don't know how real rocket programs do it".

It's "I don't know how SQUAD did it.".

I could just utterly ignore the problem of not knowing what SQUAD includes in their ISP numbers and just hand you the number from the API as-is and let you deal with it - but then I cannot also calculate the dV. To get the dV I do need to know which propellant(s) they used in the ISP number.

In general I think the solution is just to provide a way to LIST ENGINES THAT ARE ACTIVE INTO VAR. (not with that exact syntax of course). Then you can decide what you want to do with the ISP numbers that come out ( and if you only have 1 engine active at a time, then you don't need to work out how to average them together and how to weight that average.)

Edited August 30, 2014 by Steven Mading

[Joe32320]

The way I calculate ISP of the engine(s) that are currently being used is to list all the engines, then check the engines to see if they have been ignited AND aren't flamed out, then using stats from the engine I calculate the ISP using equations found here: http://wiki.kerbalspaceprogram.com/wiki/Isp

Note, I think that once an engine has been staged once, it counts as being ignited even if you shut it down again from the right hand menu, so for complex designs/ships that have docked together, it may not be a valid way of doing it but otherwise it seems to work. A way around might be to lower the thrust limit in the right hand menu to 0, then take that into account within the loop for the calculations.

[postalbyke]

Isp in KSP has unit (seconds).

Squad uses the real-world definition. (which results in unit (seconds).)

For rockets (in KSP), the amount of fuel used for thrust/deltaVee/Isp is both oxidizer and liquidfuel.

I don't know why one would use dV for a jet, but you could see for yourself by calculating Isp using the thrust and liquidfuel rate to calculate it (don't forget little g = 9.81, and the conversion rate of 5 kg/unit liquidfuel), and compare that to the Isp printout from Engineer.

edit: The wiki says in m/s, but I get very good results when applying the Isp as given in the unit(seconds) way.

Edited August 30, 2014 by postalbyke

[whaaw]

i have an old script that im trying to get running.

set nd to nextnode.

lock np to R(0,0,0) * nd:deltav.

lock steering to np.

wait until abs(np:pitch - facing:pitch) < 0.1 and abs(np:yaw - facing:yaw) < 0.1.

error is:

Suffix PITCH not found on object

and

if wp != oldwp {

print "T+" + round(missiontime) + " Warp " + warp + ", remaining wait " + round(rt) + "s".

set oldwp to wp.

}

gives a syntax error here:

!=

edit: lock steering to nextnode turns the ship to the node but the ship rotates crazy in the roll axis.

Edited August 30, 2014 by whaaw

[Dunbaratu]

lock np to R(0,0,0) * nd:deltav.

There is no need to do R(0,0,0)* anymore, because kOS can steer from raw vectors themselves.

error is:

Suffix PITCH not found on object 

This is because we fixed rotation*vector so it returns a vector instead of returning a rotation, which was nonsensical ("I want to rotate this vector" makes sense, but what it did before was "I want to vector this rotation", which doesn't.)

So when you do:

lock np to r(0,0,0) * nd:deltav

You get a vector out of it now, not a rotation. (and since the rotation was zero, you in fact get a copy of nd:deltav).

Thus the complaint about PITCH. PITCH isn't a suffix because what you now have is a vector, not a rotation.

If you really do want a rotation, then you can get it from any vector with the :DIRECTION suffix, like so:

lock np to nd:deltav:direction.

But then you do have the information loss that a vector doesn't have an "up" direction so the roll orientation will be something arbitrary.

!=

This is <> instead of != now. Nivekk's old "!=" feature was undocumented, so when the system was rebuilt from the ground up, according to the spec, there was no 'not equal' operator implemented because we didn't know it was there, being undocumented. Then a new not-equal was implemented (again not knowing there was one already), and it was named '<>'.

[whaaw]

thx for your reply it helps me alot.

i still have some wired behavior with lock steering with the small kos machine roll axis go crazy with the big kos maschine lock steering works but i cant unlock the steering im using 32bit

EDIT:

ok it works now the bug is gone so far. Its scary because i cant reproduce it and i changed nothing.

clearscreen.
set nd to nextnode.
set deactivateFlag to 0.
on AG1 set deactivateFlag to 1.
lock np to nd:deltav:direction.
lock steering to np.
until deactivateFlag=1 {
set tpitch to abs(np:pitch - facing:pitch).
set tyaw to abs(np:yaw  - facing:yaw).
print tpitch at (0,10).
print tyaw at (0,20).
}
unlock steering.
print "stop".
//wait until abs(np:pitch - facing:pitch) < 0.1 and abs(np:yaw - facing:yaw) < 0.1.

Edited August 31, 2014 by whaaw

[Dunbaratu]

(By the way, please quote your code using [ code ] blocks, not [ quote ] blocks, because the forum deletes all but the outermost nest level of [ quote ] blocks when replying (even with multiquote enabled, which is broken), making it a PITA to reply to the code because I have to manually cut and paste to do it.)

You do not need to do this:

lock steering to np.

over and over and over each iteration. Why is it inside the loop? Just do it once before the loop starts. That may have something to do with why it has a hard time keeping the steering straight. You're constantly re-setting it and making it have to start over from scratch.

[qwesr]

Does KOS have support for variable references/pointers? I.e Set a to &b

I'm sure this question has been asked before but I cant for the life of me find an answer.

[beelzebub]

Hey gang,

first time playing with kOS since 0.6, thanks very much for re-invigorating it! Quick request for some help/advice, since I'm thoroughly stuck. The steering (lock steering to x) is ineffective, as has been discussed, so I've been writing my own PID controller to do ship:control:pitch/yaw/roll. However, I'm experiencing difficulties calculating a pitch/yaw error that is independent of the roll (i.e. it doesn't care which way around the rocket is, just points it in the right direction. Up - ship:facing still wants to correct for roll...).

Does anyone have advice, or a sample script, that could help me with this? Alternatively, advice on getting steering working effectively would be grand, but that seems the easy way out

Edited August 31, 2014 by beelzebub

[Dunbaratu]

I'm experiencing difficulties calculating a pitch/yaw error that is independent of the roll (i.e. it doesn't care which way around the rocket is, just points it in the right direction. Up - ship:facing still wants to correct for roll...).

One of the changes since 0.6 is that kOS now has much better vector support. What it sounds like you want is to get the error between the wanted vector and the current facing in two components - the yaw component relative to the ship, and the pitch component relative to the ship.

Check this video and see the bit at the end where I give a brief overview of one way to do it with dot products, starting at position 2:50 in the video.

[Dunbaratu]

Does KOS have support for variable references/pointers? I.e Set a to &b

I'm sure this question has been asked before but I cant for the life of me find an answer.

No, but weirdly it does adhere to the common way things work in OOP where primitives are copied by value and complex structures are copied by reference.

If you do this:

set x to 1.0.

set y to x.

then x and y refer to two different instances of the number 1.0, that you can edit separately.

But if you do this:

set V1 to V(10,20,30).

set V2 to V1.

Then V1 and V2 refer to the SAME vector, and doing something like SET V1:X TO 20 ends up changing the value of V2:X as well because they are just references to the same vector.

This is because of how it's built on top of C# and it's inheriting this behavior from C# itself. I'm not very happy with this, as it's not intuitive, and kOS does not expose the difference between value and reference anywhere else to the script programmer, so it introduces a confusion that you lack the tools to do anything to control.

[beelzebub]

What it sounds like you want is to get the error between the wanted vector and the current facing in two components - the yaw component relative to the ship, and the pitch component relative to the ship... Check this video...

Thanks, Steve - I'll have a fiddle and report back

[whaaw]

Hi,

im still looking for a good solution for Kerbin KSC landing from a stable orbit.

i searched alot but its hard to find somthing.

[qwesr]

No, but weirdly it does adhere to the common way things work in OOP where primitives are copied by value and complex structures are copied by reference.

If you do this:

set x to 1.0.

set y to x.

then x and y refer to two different instances of the number 1.0, that you can edit separately.

But if you do this:

set V1 to V(10,20,30).

set V2 to V1.

Then V1 and V2 refer to the SAME vector, and doing something like SET V1:X TO 20 ends up changing the value of V2:X as well because they are just references to the same vector.

This is because of how it's built on top of C# and it's inheriting this behavior from C# itself. I'm not very happy with this, as it's not intuitive, and kOS does not expose the difference between value and reference anywhere else to the script programmer, so it introduces a confusion that you lack the tools to do anything to control.

Huh, so lets say I pass a List type to another file as a parameter, will the same thing still apply or would a copy of the list be made locally in that file?