Jump to content

kOS Scriptable Autopilot System 0.9


KevinLaity

Recommended Posts

The problem is that for all intents and purposes, "steering" appears to be a write-only variable. You can "LOCK steering to BLAH" but you can't "PRINT steering".

I can't test it now, but I'm able to print steering. Or at least it works for the different axes (like PRINT steering:pitch), although I'm not sure if this actually the correct value.

Fabian

Link to comment
Share on other sites

Hello, so I've been having a problem recently with a script, every time try to run it my KSP will crash and I have to use the task manager to end the process. Pretty much what I'm trying to do with the script is make something that will give me basic heading control for prograde, retrograde, normal +, normal -, radial +, and radial -.

This is a very common problem I've run into as well with kOS.

In your code I think the problem is here:


PRINT "RETROGRADE.

There's no close quote mark.

In general, whenever you edit your code, run it, and kOS causes KSP to freeze entirely, look through what you just edited for paired delimiters like (..) or {...} or "..." in which you are missing the closing part. I can pretty repeatably make kOS crash KSP by typing that.

An interpreter should react to mismatched parentheses and the like with a graceful syntax complaint rather than by crashing. I suspect that what's happening is that it's trying to read through the program file to find the closing thing, and getting all the way to the end without finding it, and then one of the following two things is happening:

1 - The interpreter didn't check for End of File while scanning for the closing thingy so when it gets to the end it just bumps against the EOF forever, continually trying to read the next character that isn't there.

or

2 - The interpreter is operating on some sort of processed "cooked" stream input that masks off the end of file so it never generates an EOF for the interpreter to detect even if it is trying to detect it.

Edited by Steven Mading
Link to comment
Share on other sites

I personally would say stuff like this should be reported there: https://github.com/Nivekk/KOS/issues As it seems it is KSP's failure but I don't see why kOS simply but it into a (-360;+360) or [0;+360) interval prior to giving it to your script.

Fabian

Thanks. I'll take my concerns there.

Edited by check
Link to comment
Share on other sites

This is a very common problem I've run into as well with kOS.

In your code I think the problem is here:

Code:

PRINT "RETROGRADE.

There's no close quote mark.

In general, whenever you edit your code, run it, and kOS causes KSP to freeze entirely, look through what you just edited for paired delimiters like (..) or {...} or "..." in which you are missing the closing part. I can pretty repeatably make kOS crash KSP by typing that.

An interpreter should react to mismatched parentheses and the like with a graceful syntax complaint rather than by crashing. I suspect that what's happening is that it's trying to read through the program file to find the closing thing, and getting all the way to the end without finding it, and then one of the following two things is happening:

1 - The interpreter didn't check for End of File while scanning for the closing thingy so when it gets to the end it just bumps against the EOF forever, continually trying to read the next character that isn't there.

or

2 - The interpreter is operating on some sort of processed "cooked" stream input that masks off the end of file so it never generates an EOF for the interpreter to detect even if it is trying to detect it.

Thank you so much, last night I was really tired so I can see how I easily missed that, especially with KSP taking 10 minutes to load every time I wanted to test it.

On another note, is there anywhere that people have been sharing scripts for kOS? Like a thread that was made specifically for sharing them? Because I have a really nice launch sequence script that I spent 10 hours last night working on.

Link to comment
Share on other sites

is there a possibility of signal lag? like it would take "n" amount of time for your signal to reach a probe orbiting duna? it would be similar to RemoteTech, but without all the hassle of a comm's network.

You could implement a "delay" of sorts in the program. Detect what body you're in the gravity sphere of and/or use the distance away from Kerbin and add a "wait" time for how ever long the delay would be. If I'm not mistaken, as it is if you're not in range of KSC and/or have a dish on you can't load a program, well not from archive anyway. My plan is when I start actually using KSP (when ever remotech 2 is offical), so long as KOS doesn't have any problems working with remotech2, im gonna build my comm network. I'd imagine, even with whatever part lag I'd have, kOS would help in that it'll still run the same, so that should be interesting ;) and fun. Now...of course if remotech2 isn't official before KSP 0.22 is released, then maybe partlag wont be so bad, depending on what this optimization is they're talking about.

Link to comment
Share on other sites

[edit: deleted my post. I thought I'd found a good solution to a problem but I hadn't.]

Lol, don't you hate when that happens? Wish I understood the math better (cos, tan, sin, etc) and what they'd be good for.

Link to comment
Share on other sites

Does anybody know how to use ON AGX without having the script end immediately afterwards? I'm trying to make a basic heading control script that waits for an actiongrounp to be triggered and when it is it's supposed to cycle through the 6 relative directions of prograde, retrograde, normal +, normal -, radial +, and radial -.

I've been trying to use an UNTIL loop to make sure that the script doesn't end and can continue to wait for the actiongrounp to be triggered, however it seems that no matter where I put ON AGX it automatically ends the script afterwards.

Link to comment
Share on other sites

Does anybody know how to use ON AGX without having the script end immediately afterwards? I'm trying to make a basic heading control script that waits for an actiongrounp to be triggered and when it is it's supposed to cycle through the 6 relative directions of prograde, retrograde, normal +, normal -, radial +, and radial -.

I've been trying to use an UNTIL loop to make sure that the script doesn't end and can continue to wait for the actiongrounp to be triggered, however if seems that no matter where I put ON AGX it automatically ends the script afterwards.

We would have to look. There is something obviously triggering your loop end condition. I have plenty of scripts that use action groups for user input. It's not a problem with the action groups that I know of.

Link to comment
Share on other sites

Lol, don't you hate when that happens? Wish I understood the math better (cos, tan, sin, etc) and what they'd be good for.

I do now have a solution of sorts but I need to work out how to explain it in as few words as possible so I don't do a giant wall of a post. I'll want to post code with it.

Link to comment
Share on other sites

is there a possibility of signal lag? like it would take "n" amount of time for your signal to reach a probe orbiting duna? it would be similar to RemoteTech, but without all the hassle of a comm's network.

I don't think I'll implement that. It may be realistic, but I would get bug reports from people saying "copying files to duna lags like 90 seconds!"

Link to comment
Share on other sites

We would have to look. There is something obviously triggering your loop end condition. I have plenty of scripts that use action groups for user input. It's not a problem with the action groups that I know of.

I think I've just figured out what might of been the problem, although I'll need to test it more it appears that the actiongrounps didn't work how I expected. Initially I thought it worked like a button, you press it and it automatically "un-presses" so to speak, however after a bit of testing I've found that it seems to actually work more like a switch, you can switch it on with the actiongroup button, but you then have to immediately use TOGGLE AGX to switch it back off or else it will remain "on".

I figured this out by writing this simple little script...

LOCK STEERING TO PROGRADE.
WAIT UNTIL AG1.

However when I ran this, it would only work the first time and any further attempts to run the script again would be greeted by it being immediately ended, since AG1 was technically still "on".

The solution was the following.

LOCK STEERING TO PROGRADE.
WAIT UNTIL AG1.
TOGGLE AG1.

And with that, it will work over and over again as intended.

Edited by CoriW
Link to comment
Share on other sites

I just got my launch program in a state I'm reasonably happy with. It controls pitch and throttle with a PID watching eta:apoapsis, and stages based on discontinuities in acceleration.

set targetapo to 90000.
set atmo_top to 68000.
set limitG to 1.5.

mode_pad on.
mode_stage off.
mode_launch off.
mode_limitG off.
mode_turn off.
mode_coast off.
mode_raise_ap off.
mode_raise_pe off.
mode_finish off.

set roll to 0-90.
set yaw to 0.
set pitch to 0.
set pitchmaxlimit to 0.1.

set tlimit to 1.
set Pthrottle to 0.01.
set Dthrottle to 0.
set errorT to 0.
set errorTD to 0.

set bstartalt to 1000.
set bendalt to 9000.
set bendpitch to (0-bendalt)/atmo_top.

set P to 0.01.
set I to 0.001.
set D to 0.1.

set error to 0.
set errorprev to 0.
set errorI to 0.
set errorD to 0.

set scalarvelocity to 0.
set prevV to 0.
set accel to 0.
set prevAccel to 0.
set jerk to 0.
set prev_throttle to 1.
set prev_epsilon to 0.

print "Liftoff".
set clock to 0.
lock steering to up.
sas on.
lock throttle to 1.
stage.
mode_pad off.
mode_launch on.
mode_limitG on.
wait until missiontime > 0.

until mode_finish {
set deltatime to missiontime - clock.
set clock to missiontime.
set prevV to scalarvelocity.
set prevAccel to accel.
set scalarvelocity to (surfacespeed^2 + verticalspeed^2)^(0.5).
set accel to (scalarvelocity - prevV) / deltatime.
set jerk to (accel - prevAccel) / deltatime.
set pitchlimit to (0-1) * (altitude/atmo_top).
if pitchlimit < (0-1) { set pitchlimit to (0-1). }.

if mode_launch {
mode_stage on.
if altitude > bstartalt {
print "Static turn".
mode_launch off.
mode_turn on.
sas off.
}.
}.

if mode_stage {
set accel_theoretical to ((maxthrust/mass)*throttle).
set epsilon to accel_theoretical - accel.
set throttlechange to accel * (throttle - prev_throttle).
if (missiontime > 10) and (throttle > 0) and (throttlechange > -3) and (epsilon - prev_epsilon > 2.5) {
print "Staging".
stage.
}.
set prev_epsilon to epsilon.
set prev_throttle to throttle.
}.

if mode_turn {
set pitch to bendpitch * ((altitude-bstartalt)/(bendalt-bstartalt)).
lock steering to up + r(yaw, 90*pitch, roll).
if altitude > bendalt {
print "Dynamic turn".
mode_turn off.
mode_coast on.
mode_raise_ap on.
mode_limitG off.
lock throttle to 1.
set startapo to apoapsis.
set starteta to eta:apoapsis.
}.
}.

if mode_limitG {
set errorTprev to errorT.
set errorT to (limitG*9.8) - (tlimit*accel).
set errorTD to (errorT - errorTprev) / deltatime.
set tlimit to tlimit + (Pthrottle*errorT) + (Dthrottle * errorTD).
if tlimit > 1 { set tlimit to 1. }.
lock throttle to tlimit.
}.

if mode_raise_ap {
set etamargin to 15.
set minthrust to 0.5.
set tfudge to 0.1.
if apoapsis > targetapo {
print "Circularizing".
mode_raise_ap off.
mode_raise_pe on.
}.
}.

if mode_raise_pe {
set etamargin to 10.
set minthrust to 0.
set pitchmaxlimit to -1.
set tfudge to 0.
set I to 0.
if periapsis > targetapo {
mode_raise_pe off.
mode_coast off.
mode_finish on.
}.
}.

if mode_coast {
set targeteta to ((targetapo-apoapsis)/(targetapo-startapo)) * starteta.
if targeteta < etamargin { set targeteta to etamargin. }.
set eta to eta:apoapsis.
if eta:periapsis < eta:apoapsis { set eta to 0. }.
set errorprev to error.
set error to targeteta - eta.
set errorD to (error - errorprev) / deltatime.
set errorI to errorI + (error * deltatime).
if errorI > error { set errorI to error. }.
set adjustment to (P*error) + (I*errorI) + (D*errorD).

if (adjustment < 0) or (tlimit = 1) {
set pitch to pitch + adjustment.
if pitch < pitchlimit { set pitch to pitchlimit. }.
if pitch > pitchmaxlimit { set pitch to pitchmaxlimit. }.
lock steering to up + r(yaw, 90*pitch, roll).
}.
if (pitch - pitchlimit < .03) or (adjustment > 0) {
set tlimit to tlimit + adjustment.
}.
if (pitchlimit > 0-1) { set tlimit to tlimit + tfudge. }.
if tlimit < minthrust { set tlimit to minthrust. }.
if tlimit > 1 { set tlimit to 1. }.
set tfinal to tlimit.
lock throttle to tfinal.
}.
}.

Link to comment
Share on other sites

I think I've just figured out what might of been the problem, although I'll need to test it more it appears that the actiongrounps didn't work how I expected. Initially I thought it worked like a button, you press it and it automatically "un-presses" so to speak, however after a bit of testing I've found that it seems to actually work more like a switch, you can switch it on with the actiongroup button, but you then have to immediately use TOGGLE AGX to switch it back off or else it will remain "on".

I figured this out by writing this simple little script...

LOCK STEERING TO PROGRADE.
WAIT UNTIL AG1.

However when I ran this, it would only work the first time and any further attempts to run the script again would be greeted by it being immediately ended, the solution was the following.

LOCK STEERING TO PROGRADE.
WAIT UNTIL AG1.
TOGGLE AG1.

And with that, it will work over and over again as intended.

I too noticed the lack of de-bouncing. It's not a real issue as you found, if you turn it back off manually. It takes some amount of loop control to use them correctly. I think I probably do too much from what I have seen in other scripts. Just be reminded that using halts as flow control is not the greatest practice. Your computer can't do anything while it's waiting. In simple scripts it seems like a non-issue and indeed usually is. It is just something to be mindful of.

Link to comment
Share on other sites

I too noticed the lack of de-bouncing. It's not a real issue as you found, if you turn it back off manually. It takes some amount of loop control to use them correctly. I think I probably do too much from what I have seen in other scripts. Just be reminded that using halts as flow control is not the greatest practice. Your computer can't do anything while it's waiting. In simple scripts it seems like a non-issue and indeed usually is. It is just something to be mindful of.

Hey I was wondering if maybe you or someone else can help me with this script I'm working on, it's supposed to be able to cycle through headings using AG5, but it doesn't seem to work. Originally I tried putting "ON AG5 {SET V TO V + 1. TOGGLE AG5.}." before the UNTIL loop, however using that method the script was ended immediately after I press "5", and then the version below that has the code inside the UNTIL loop it just doesn't register AG5 being pressed at all.

SET V TO 0.
SET X TO 0.

UNTIL X = 1
{
ON AG5 {SET V TO V + 1. TOGGLE AG5.}.

IF V = 0
{
UNLOCK ALL.
PRINT "NO VECTOR".
}.
IF V = 1
{
LOCK STEERING TO PROGRADE.
PRINT "PROGRADE".
}.
IF V = 2
{
LOCK STEERING TO RETROGRADE.
PRINT "RETROGRADE".
}.
IF V = 3
{
LOCK STEERING TO PROGRADE + R(-90,0,0)
PRINT "NORMAL +".
}.
IF V = 4
{
LOCK STEERING TO PROGRADE + R(90,0,0)
PRINT "NORMAL -".
}.
IF V = 5
{
LOCK STEERING TO PROGRADE + R(0,90,0)
PRINT "RADIAL +".
}.
IF V = 6
{
LOCK STEERING TO PROGRADE + R(0,-90,0)
PRINT "RADIAL -".
}.
IF V = 7 {SET V TO 0.}.
}.

Link to comment
Share on other sites

Your lock steering statements lack a terminator. There is an IDE out for this that could help with that. I haven't tried it but I'm pretty sure it will highlight those kinds of errors right off the bat. Also if you want to have fun. Leave a close parenthesis off the end of one of those statements and see what happens.

No really don't do that. It will lock the game up.

Edited by Payload
Link to comment
Share on other sites

Your lock steering statements lack a terminator. There is an IDE out for this that could help with that. I haven't tried it but I'm pretty sure it will highlight those kinds of errors right off the bat. Also if you want to have fun. Leave a close parenthesis off the end of one of those statements and see what happens.

No really don't do that. It will lock the game up.

Well this is strange... It will run without those terminators you mentioned but as soon as I add them the script won't run due to a "Syntax Error" that only occurs after I've added those 4 terminators.

EDIT: Not sure what I did but I got it to work with the terminators... However it still won't work, if I have "ON AG5 {SET V TO V + 1. TOGGLE AG5.}." inside the loop it can't be detected and if I have it before the loop it ends the script on AG5.

EDIT: Alright so after much trying and failure it seems that "ON AGX" isn't compatible with UNTIL loops.

Edited by CoriW
Link to comment
Share on other sites

I am working on a missile. It does raise up and takeoff from the vehicle but now the problem is how to lock the steering towards the target. I will have to refresh my brain a little on math and physics to figure this one out or maybe not?

f6jm.png

m30f.png

bcvy.png

I don't have much programming experience but here is my code so far.

 print "Altitude" at (20,0).
until 0
{
set target to "tank1".
print altitude at (20,1).
toggle AG4.
lock throttle to 1.
set t to 10.
until t < 1 {
print "Lift Off in: ".
print "T- " + t.
set t to t - 1.
wait 1.
if t = 3 {
lock throttle to 1.
print "Throttle Set".
}.
}.


if t = 0 {

lock steering to up + R(0,0,180).
stage.
print "Takeoff!".
}.



wait 10.
set x to target:distance.
wait until altitude > x.

print "Going to Target.".
lock steering to target.


}.




Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...