kOS Scriptable Autopilot System 0.9

[mushroomman]

If you copied it directly, then it won't work, I just noticed that I wrote verticalspeed wrong on the second line, there can not be a space in between the vertical and speed, all one word... so:

until verticalspeed = 0{
 if verticalspeed > 10{
  set tVal to tVal + 0.1.
 }.
}.

No, that wasn't the problem. I still haven figured out exactly what's wrong but by removing the "if verticalspeed" line it does increase the throttle

properly.

Edit: I think the problem is because I am going down, not up, the vertical speed needs to be a negative value. I might be able to get this to work somehow.

Edit 2: Yes this is the case. My proof is that I could get my ship to hover by using

until altitude < 70 {
if verticalspeed < 0 {
set tval to tval + 0.1.
}.
if verticalspeed >0 {
set tval to tval - 0.1.
}.
}.

Edited August 28, 2013 by mushroomman

[neogoo123]

@mushroomman Yea I was just thinking about that... welp, now we know, though it seems blatantly obvious now...

[mushroomman]

@mushroomman Yea I was just thinking about that... welp, now we know, though it seems blatantly obvious now...

You'd think it is, but now it just slowly throttles to %50 and flies away. Using this code:

until altitude < 70 {
if verticalspeed < -10 {
set tval to tval + 0.05.
}.
if verticalspeed > -5 {
set tval to tval - 0.05.
}.
}.

Edit: Wouldn'tcha know it! I forgot a period. It's working now. Wonderful!

Edited August 28, 2013 by mushroomman

[neogoo123]

lol, them periods! Well I'm glad to hear it! I was just gunna hop into KSP and see if I could get something to work using what we've just learned..... Though now I feel challenged to create some automated re-entry craft.... I have Ferram's Aerospace Research downloaded as well as Deadly Re-entry.... this should be fun.... If I get it to work I will make a video.

[mushroomman]

I'm so happy!

[Gaius]

Is there some way (or could some way be added) to set how aggressively the computer tries to turn the ship? I have a rocket that if I tell it to roll over to -60 at 8km, it's literally clear of the atmosphere before it finishes the turn. Using manual control or MechJeb, it turns to whatever angle I want in seconds rather than minutes, so I know the rocket's capable of turning much more quickly, the kOS computer just doesn't want to turn it.

Also, there does seem to be an issue with one of my rockets where it appears kOS is trying to turn it based on the orientation of the root part rather than the orientation of the active ("control from here") module, or the kOS module itself. This is problematic, as the root of this particular assembly is a rover that for various reasons is packed sideways under the fairings.

Edited August 28, 2013 by Gaius

[StainX]

Love kOS and im excited about future releases!

So, please keep it up!

[GavinZac]

New twist on the Apollo Challenge: Moon and back in 73,728kb!

[theSpeare]

How do you even program the transfer burn? kOS definitely needs more data that we can use

[StainX]

How do you even program the transfer burn? kOS definitely needs more data that we can use

yeah, signed!

[HoneyFox]

How do you even program the transfer burn? kOS definitely needs more data that we can use

At least we can approach to mun by using some special type of orbit: a circular orbit a litter lower than Mun's orbit. Then wait until body changed to Mun. Then do the de-orbit burn and land... Well, at least it's theoretically possible.

[theSpeare]

That's actually a pretty good method. I do the same for minmus when I fly manually. The problem is that it doesn't have timewarp yet, and so I'm very excited to see that appear.

Essentially it boils down to these three in order:

1. External editing capability (which is already coming, yay!)

2. More data, more data, more data! Distance from surface, max thrust, mass of ship etc.

3. Time warp function

[HoneyFox]

That's actually a pretty good method. I do the same for minmus when I fly manually. The problem is that it doesn't have timewarp yet, and so I'm very excited to see that appear.

Essentially it boils down to these three in order:

1. External editing capability (which is already coming, yay!)

2. More data, more data, more data! Distance from surface, max thrust, mass of ship etc.

3. Time warp function

I think it should be quite easy for the author to implement that.

Actually i really hope that the author can consider implementing some sort of interfaces so that other guys can implement more additional commands they want. Time warp for example...

But the script language is not so command-based so i guess it won't be that easy. So it's just my suggestion.

[GavinZac]

How do you even program the transfer burn? kOS definitely needs more data that we can use

The same way Apollo did: timing it right

[HoneyFox]

The same way Apollo did: timing it right

Oh that's gonna be very tricky...

[JewelShisen]

Oh that's gonna be very tricky...

Not really.

[GavinZac]

Oh that's gonna be very tricky...

Like rocket science or something!

[Payload]

Oh that's gonna be very tricky...

Not if you wait until the right time to launch. You just never circularize and head directly there. Like he said, if you time it right, it's not that hard. The timing isn't super critical either. We do need keyboard input. Even the Apollo guys had to enter in parameters for correction burns. The correction burn for free return is going to have unknown parameters.

from 100k orbit, it takes roughly 837m/s of dV to reach the moon. For free return it will take slightly more since you will want to leave slightly earlier than normal. I guess if we are hand setting the node it should have no problem doing the burn with the data we have available. We can lock steering to node and burn until we have the required orbital velocity. We do have access to time and mission time. I can see no real obstacle in the way of making it happen. May not have as much info as you would like, but you have enough.

WHEN <ElectricCharge> = 20 THEN PRINT "TEST".

This doesn't give an error, but it doesn't seem to trigger, either.

I have had problems getting things to trigger on = and I'll tell you why. Polling time. It just misses the 0 crossing. I have had much more success with "> target" expressions.

Edited August 28, 2013 by Payload

[HoneyFox]

Not if you wait until the right time to launch. You just never circularize and head directly there. Like he said, if you time it right, it's not that hard. The timing isn't super critical either. We do need keyboard input. Even the Apollo guys had to enter in parameters for correction burns. The correction burn for free return is going to have unknown parameters.

from 100k orbit, it takes roughly 837m/s of dV to reach the moon. For free return it will take slightly more since you will want to leave slightly earlier than normal. I guess if we are hand setting the node it should have no problem doing the burn with the data we have available. We can lock steering to node and burn until we have the required orbital velocity. We do have access to time and mission time. I can see no real obstacle in the way of making it happen. May not have as much info as you would like, but you have enough.

I have had problems getting things to trigger on = and I'll tell you why. Polling time. It just misses the 0 crossing. I have had much more success with "> target" expressions.

I mean the phase angle, which seems to be the biggest problem. If the entire procedures are splitted into two parts: 1) get into LKO, 2) execute the transfer maneuver. and if we players can decide when to start these scripts, everything will be a lot easier.

For me it's not easy to evaluate how much time / angle do i need to get into LKO... And i don't know if anyone knows how, or it's just some rough estimation.

[Payload]

You just clock the moon when it goes over KSP and wait until you see it again. Do some maths and now you have a phase angle. The mun is on the same inclination as Kerbin in the game. You have a window every single orbit. As I said, you have a clock. You have all of the info you need. Also I played this game long before any kind of flight computer so I got really good at eyeballing the lift off time anyway.

[razark]

I have had problems getting things to trigger on = and I'll tell you why. Polling time. It just misses the 0 crossing. I have had much more success with "> target" expressions.

Yeah, that occurred to me. I tried to turn off most of the power consumption so that it would drain slowly. I don't know how accurate the numbers on the resources display are. The display has two decimal point, but is that how accurate it is internally? Does it go from 20.01 to 20.00, or is it going in even smaller steps, making the polling window even smaller?

WHEN (<ElectricCharge> - 20) < .01 THEN PRINT "TEST".

I wonder if we can have an absolute value operation?

[HoneyFox]

Yeah, that occurred to me. I tried to turn off most of the power consumption so that it would drain slowly. I don't know how accurate the numbers on the resources display are. The display has two decimal point, but is that how accurate it is internally? Does it go from 20.01 to 20.00, or is it going in even smaller steps, making the polling window even smaller?

WHEN (<ElectricCharge> - 20) < .01 THEN PRINT "TEST".

I wonder if we can have an absolute value operation?

Reason simple, these electric charge changes in steps (i.e. if it changes from 20.01 to 19.99, this statement will not run because it never equals to 20.00). Also, it's never been wise to make equality or inequality check for floating point numbers due to its inaccuracy nature. You should always use something like: if ( a >= b - e and a <= b + e) where the e should not be smaller than the step of the value change.

EDIT: I don't know if the statement above works in this script language, but you can do that by nesting two if statements, though that will make the code look tedious...

[KevinLaity]

So, I could use a little help. I want to program an escape system sequence using action groups. The sequence is as follows:

AG 1 : Decouple from the main stack and fire the escape tower's SRB's

Wait 1 second.

AG2 : decouple the escape tower

Wait 1 second.

AG3 :Deploy the chute.

So, the following works great when entered as a command line entry :

on ag9 {toggle ag1. wait 1. toggle ag2. wait 1. toggle ag3.} .

As soon as I press '9' it triggers the sequence.

When I try to do this as a script the program just ends.

I tried using a loop as follows:

set x to 0.
until x>0 { 
on ag9 {toggle ag1. wait 1. toggle ag2. wait 1. toggle ag3.} . }.

Any pointers as to why this doesn't work would be greatly appreciated.

When a program ends, any temporal commands you've issued within the scope of that program are discarded, including ON.

I recommend putting a WAIT statement at the end of your program, and give it a criteria that matches when you want the program to end.

[Payload]

You know what I just realized? We need an alarm buzzer! How about a low fuel alarm or a low battery alarm? All it needs to be is a part that makes the sound of your choice when it's action group it toggled. Maybe even put a little flashing light on it. Hmm. I think I'll take the little B9 red light and do a little hacking...

[GavinZac]

You know what I just realized? We need an alarm buzzer! How about a low fuel alarm or a low battery alarm? All it needs to be is a part that makes the sound of your choice when it's action group it toggled. Maybe even put a little flashing light on it. Hmm. I think I'll take the little B9 red light and do a little hacking...

Oh god, if we had a sound function it would be fantastic. My first ever program was messing around with the computer beeps on Amstrad, setting the pitch and so on. Descending too quickly? WARMP, WARMP!