kOS Autopilot

[CaptainKipard]

As an absolute noob to KOS (and DOS ) is there a way to point towards manoeuvre node without coding a massive amount?

lock steering to nextnode.

I usually disable SAS and re-enable it after the relevant code has run, like this:

sas off.
lock steering to nextnode.
...stuff
unlock steering.
sas on.

Edited March 1, 2014 by Cpt. Kipard

[Boamere]

lock steering to nextnode.

I usually disable SAS and re-enable it after the relevant code has run, like this:

sas off.
lock steering to nextnode.
...stuff
unlock steering.
sas on.

Thanks! (I'm finding the whole thing a bit confusing, but I guess I have to start somewhere )

[Dunbaratu]

That is what i was afraid of. I am actually just waiting for one of you to tell me that it is a huge pain and show me all of the crazy code it takes first if it turns out to be not a big deal i might just leave it as is.

Having Matrix and trig primitives that we can invoke allows for imagined hardware acceleration. Even in the Apollo days they already had a hardware instruction on the Apollo Guidance Computer to do matrix algebra electronically in one step. So it's pretty realistic to have them as low-level primitives. The thing that should be left in userland is the knowledge of how you need to use those primitives to perform the rotations you're trying to do. It's still just one simple instruction to execute, but you need to know how to set it up, and it's the knowing of that in which the user's intelligence is involved.

I'm almost done with converting my Duna mission to kOS 0.11 so you have it as a testbed like you asked. After that I'll tackle docking and see if what's there already is enough to make it work. I suspect it now is if the issues of translation are fixed now.

[Dunbaratu]

I have also encountered the save/load bug again where it crashes partway through loading the vessel from the persistence file and therefore truncates the ship at the spot where the kOS SCS part is located in the file. It's one of the reasons it's taken me longer than expected to update my Duna mission. I thought it was fixed but it's still happening, and I have narrowed it down to this:

If your variable context contains a vector, the bug triggers. If your variable context does not contain a vector, it doesn't seem to trigger.

Vectors are being saved in the persistence file like this:

V ( 1 0 0 , & # 3 2 ; 5 0 , & # 3 2 ; 0 )

(I spaced out all the characters because after about 10 attempts to try different ways to get the forum software to let me literal-protect the ampersands codes so it wouldn't interpret them I gave up. It kept mangling what I wrote even in [ code ] blocks.)

32 is the decimal ASCII code for a space character. So I suspect it's trying to print it out to the file as:

somevariable = V(100, 50, 0)

and the spaces are being encoded with HTML-style protection, but then it doesn't know how to read those back in when loading the vessel.

At least that's my guess.

Edited March 2, 2014 by Steven Mading
Had to protect my examples inside CODE blocks because the &# was being eaten by HTML formatting.

[Camacha]

If your variable context contains a vector, the bug triggers. If your variable context does not contain a vector, it doesn't seem to trigger.

That would definitly explain why you seem to be bothered more by this problem than others, as you have already stated that you do most navigational math with vectors.

Although I do think I have seen the bug without using vectors, but that is very rare indeed. Barely ever happened, never could reproduce it.

Edited March 2, 2014 by Camacha

[Dunbaratu]

That would definitly explain why you seem to be bothered more by this problem than others, as you have already stated that you do most navigational math with vectors.

Although I do think I have seen the bug without using vectors, but that is very rare indeed. Barely ever happened, never could reproduce it.

I'm in the middle of performing tests trying to trigger the problem, using the simplest little vessel I can build, launching it a mere kilometer or so away from KSC, landing it there, and then opening up its SCS terminal and fiddling with setting variables and quitting and reloading the game to see if I can make it break.

In so doing I've encountered several cases where even though I had a vector saved, it didn't break and loaded fine, so I'm not sure that's the problem anymore.

But I have now noticed two new problems in doing this test:

Problem 1: Some variables being changed to zero when re-loading from persistence:

In the terminal I do this:

set varA to 12.1.

set varB to 1230000000000000000.

set varC to "string with spaces".

set varD to V(1,2,3).

Then quit the game. The persistence file now contains this, which seems correct to me:

context
{
	variables
	{
		vara = 12.1
		varb = 1.23E+18
		varc = string(*)with(*)spaces
		vard = V(1,(*)2,(*)3)
	}
	context
	{
		context-type = kOS.Interpreter.ImmediateMode
	}
}

(NOTE: Everywhere you see (*) above that's *ACTUALLY* this:

& # 3 2 ;

But I haven't been successful at forcing the forum software to stop processing the ampersand directive when want to literally type it out like that.)

After reloading that game, the vessel now does this:

print varA.

12.1

print varB.

0

print varC.

0

print varD.

V(1, 2, 3)

So it does seem to be able to parse in the vector correctly after all. I was wrong about that being the cause of it.

But, notice what happened to varB and varC. They got overwritten with zero values instead of what they are in the persistence file. Not the same error, but still something is wrong there.

Problem 2: UNSET ALL bug

Furthermore, a tertiary bug I discovered in doing this was with the UNSET command. After printing the above, I then tried to prep for my next test by clearing everything out, as follows:

unset all.

print varA.

Unrecognized term: 'varA', Type:FINAL.

print varB.

Unrecognized term: 'varB', Type:FINAL.

print varC.

Unrecognized term: 'varC', Type:FINAL.

print varD.

V(1, 2, 3)

"unset all" cleared varA, varB, and varC, but not varD.

Then I proceeded to re-set varD to the same value as it already had,

and then run unset all again:

set varD to V(1,2,3).

unset all.

print varD.

Unrecognized term: 'varD', Type:FINAL.

That time it worked. I have no idea what's going on there. It failed to UNSET varD after it had been populated by loading it from the persistence, but was able to do so after I populated it by the SET command in that particular run. But that can't be all there is to the problem because if that was it then it should have affected varA, varB, and varC just as much as varD.

Edited March 2, 2014 by Steven Mading

[erendrake]

Im really glad i didnt push 11.1 to the spaceport now I have my dad visiting from out of town so i have been mostly incognito the last few days and for the next few days as well. Ill have to see if i can figure out these problems and get a new version out soon.

Thanks for your patience.

[Xty]

If I might make a request, could either the RUN command be changed, or a new command almost the same as run be added, where it would not remove things like when commands or throttle and steering locks when the script ends. It would be useful for modularizing scripts, for example a small script to stage automatically when fuel runs out with a when command. You could do this by either changing the run command to not remove throttle locks and stuff when the run command has been used inside a script, or just add a new command.

Edited March 6, 2014 by Xty

[Camacha]

If I might make a request, could either the RUN command be changed, or a new command almost the same as run be added, where it would not remove things like when commands or throttle and steering locks when the script ends. It would be useful for modularizing scripts, for example a small script to stage automatically when fuel runs out with a when command. You could do this by either changing the run command to not remove throttle locks and stuff when the run command has been used inside a script, or just add a new command.

What about solving it on your end? If you put the lock command in the central script with a variable, and update that variable in a child script that is run from the main script like a function call, you have what you want and the locks are only released when the main script ends. I think changing the final unlock will cause some trouble This is probably a matter of creative coding.

Pseudocode of main script:

lock steering to variable.
until value < 10 {
  run variableupdatescript.
}.

Child script:

set variable to (altitude/10).

Edited March 6, 2014 by Camacha

[Dunbaratu]

What about solving it on your end? If you put the lock command in the central script with a variable, and update that variable in a child script that is run from the main script like a function call, you have what you want and the locks are only released when the main script ends. I think changing the final unlock will cause some trouble This is probably a matter of creative coding.

Of course that works but it defeats the point of having the logic in a child script, which is to make modules that "just work" when used in the main program with just one call instead of having to putting half their logic in the main program.

What's being asked for is the ability to something like this:

Main program:

run emptyStager.
// go on to do other stuff.

emptyStager program:

when stage:liquidfuel = 0 then {
  until stage:liquidfuel > 0 { stage. wait 0.5. }. // keep staging until there's some fuel.
  run emptyStager.  // re-run myself to make another "when" hook for the next stage.
}.

I tried doing this myself like that and ran into the same problem, that hook triggers you set up, like WHEN, are removed when the subprogram ends so you can't isolate any hook logic in subprograms, nor can you use subprograms with recursion to create a recurring hook like I show above.

I can understand the logic with removing the ON and WHEN hooks when done with a program, for the same reason you don't want to leave throttle or steering locked when the program ends - because when the program ends you should go back to 100% manual control. BUT, throttle and steering locks go away only when the outermost program ends and you go back to immediate mode, NOT when a subprogram ends. I think ON and WHEN should work the same way, that they only go away on the final outermost program, not with a subprogram (*).

(*) But that does mean that we'd also need a way to explicitly end ONs and WHENs so that we can make them go away when we want to. Right now the only way to make them go away is to either trigger them, or end the subprogram. So if that explicit ending feature wasn't also added then we'd run into a problem when running a very long term program (like my Duna mission) that hooks from previous steps can trigger way later after that step is done. I think doing that would require the ability to name the hooks so you could mention which one you meant when you want to remove it later.

Edited March 7, 2014 by Steven Mading

[Camacha]

Although I do not feel that it means putting half the logic in the main program (as in reality the variable setting part would be much larger and the initial code is just one or two lines - which is pretty much the same in your proposal), I agree that selfsetting prerequisites would be a nice thing to have. I have fumbled around with that, but was disappointed by the lack of results.

My main fright is that we get all sorts of rogue bits staying in memory (or wherever) when programs do not throw everything out when ending. If we are going to keep the seperate script type functions - it seems that just happened by accident - we should have a good think how we want to solve that and whether that is going to be consistent with other behaviour.

Maybe the capability of explicitly carrying such commands over to the main script is an option - although I have to ponder that a bit Developing discrete functions could be another option.

Edited March 7, 2014 by Camacha

[erendrake]

I think for now my inclination would be to spend more time adding features to make impossible tasks available (docking, science, integration with other mods). rather than spend a lot of time on more complicated scope/grammar.

I like this discussion and I am hoping we can find the right solution.

[kaesekuchen]

I've got a question related to the current state of the direct flight control and flight "orientation".

Don't worry, i'm not asking "when the heck is it going to be released"

I couldn't help myself and again played around with orientation,steering and so on.

With the current implementation it is possible to directly command the vessel on the 3 rotation and 3 translation axes (Good job on this btw )

While testing around with this it occured to me, that we can apply these commands, but we are pretty much lost to reading out the actual results we achieve by this. Now, this might be something i missed, if so, disregard my inquiry.

Let's look at this example:

We want to align our vessel to a certain rotation, let's say the "target approach" indicator. With the automated steering we would simply "lock steering to direction", direction in this case being "(Target.GetWorldPos3D() - context.Vessel.GetWorldPos3D())".

Now, if we would like to implement this with the direct steering controls, we need some orientation, since there are multiple ways of achieving the aforementioned direction.

This brings me to my question: Do we have a way to readout our current difference on a certain axis towards the target direction?

What i'm asking for, is something, that could be done on c# side like this:

            Quaternion q1;
            Quaternion q2;

            //our vessel's current rotation/orientation
             q1 = Target.transform.rotation;
            //our desired target rotation
             q2 = Quaternion.LookRotation((Target.GetWorldPos3D() - FlightGlobals.fetch.VesselTarget.GetVessel().GetWorldPos3D()) * -1) * Quaternion.Euler(90, 0, 0);

                float angleYawPitch = Vector3.Angle(q1 * Vector3.up, q2 * Vector3.up);
                float angleYaw = Vector3.Angle(Vector3.Exclude(Target.transform.forward, q1 * Vector3.up), Vector3.Exclude(Target.transform.forward, q2 * Vector3.up));
                float anglePitch = Vector3.Angle(Vector3.Exclude(Target.transform.right, q1 * Vector3.up), Vector3.Exclude(Target.transform.right, q2 * Vector3.up));
                float angleRoll = Vector3.Angle(Vector3.Exclude(Target.transform.up, q1 * Vector3.right), Vector3.Exclude(Target.transform.up, q2 * Vector3.right));

angleYawPitch is the angle between our current orientation and the target on the yaw and pitch axes combined, while the other 3 angles (angleYaw,anglePitch,angleRoll) give us the angle on the according single axis.

So, to iterate on my question: at the current state, is it possible to achieve this in kOS?

thanks for reading

Edited March 7, 2014 by kaesekuchen

[erendrake]

Alright everyone, Buckle up. We have a pre-release of the new parser!

https://github.com/KSP-KOS/KOS/releases/tag/v12.0P1

Please let us know if there are any troubles, as with any major rewrite there are bound to be some old bugs that are resolved and some new fun ones to discover, if you find a bug please speak up either here or in the new github tracker for the KOS organization

https://github.com/KSP-KOS/KOS/issues

A BIG shoutout to marianoapp on all of his excellent work over the last few weeks, he deserves all of your cookies.

I have been incognito the last week with a bunch of life stuff but i have been reading everything and i know about the challenges people have been having with v11.1 and I hope we can get all of that ironed out soon

Edited March 11, 2014 by erendrake

[Camacha]

Yay, free bugs for everyone! I am loving and hating you people right now, as my daily duties are going to suffer.

[kaesekuchen]

Thanks to erendrake and marianoapp for the parser overhaul!

After a "preliminary review" i have to say, that i like the changes. The threaded execution of scripts is a nice feature, so is the change to ship:facing actually returning useable values for all 3 axes of the vessel.

Hopefully i'll have some time later on to give it a more indepth spin.

Good work.

[Dunbaratu]

I probably won't have a chance to give it a good test until Friday, but I'm looking forward to giving it a go.

[Dunbaratu]

Alright everyone, Buckle up. We have a pre-release of the new parser!

https://github.com/KSP-KOS/KOS/releases/tag/v12.0P1

Please let us know if there are any troubles, as with any major rewrite there are bound to be some old bugs that are resolved and some new fun ones to discover, if you find a bug please speak up either here or in the new github tracker for the KOS organization

https://github.com/KSP-KOS/KOS/issues

I notice that this is not the same github page as you were using before. Have you and marianoapp moved to this new fork and all future development should happen there?

At any rate I added several issues about the new version to that page for a problems in the parser.

But the following problem is not related to the new parser and was there in the old version. Since I don't know if the old fork is being abandoned and everything is moving to the new one or not I'll report it here in the forum instead of on github:

The value of SHIP:SOLIDFUEL doesn't return zero when there's no solid fuel. Instead it says "suffix SOLIDFUEL not found on object" and bombs out.

Edited March 13, 2014 by Steven Mading
(changed "STAGE:" to "SHIP:")

[erendrake]

I notice that this is not the same github page as you were using before. Have you and marianoapp moved to this new fork and all future development should happen there?

At any rate I added several issues about the new version to that page for a problems in the parser.

But the following problem is not related to the new parser and was there in the old version. Since I don't know if the old fork is being abandoned and everything is moving to the new one or not I'll report it here in the forum instead of on github:

The value of SHIP:SOLIDFUEL doesn't return zero when there's no solid fuel. Instead it says "suffix SOLIDFUEL not found on object" and bombs out.

Sorry im slow right now, All development is moving to the new Github organization, this weekend i have a big job of moving all of the links and such to the new one

ill take a look at the SolidFuel problem, if you want to add it to the new tracker that would help.

[CaptainKipard]

Will this release still make my ships and planets disappear?

[Camacha]

Will this release still make my ships and planets disappear?

Can you elaborate? Because I have never heard of ships and planets disappearing through kOS's fault - not counting the half-ship bug.

[Jordansinn]

I previously had my command probes set up to have k-OS features, when I downloaded and installed the new version I encountered the problem of crafts and bodies diapering.

[ElasticRaven]

The new version massacres my framerate But only when I add the module to pods and probes. The standalone 1 m part seems to be fine.

Has anyone else noticed this?

Edited March 15, 2014 by ElasticRaven

[marianoapp]

The new version massacres my framerate But only when I add the module to pods and probes. The standalone 1 m part seems to be fine.

Has anyone else noticed this?

I found an issue using ModuleManager that spammed the log with exceptions but I thought it was an isolated case. I'll look into it.

[Jordansinn]

Lock to prograde and lock throttle to 1 commands do not work while out of remote tech 2 range. The whole reason I downloaded this mod was to be able to do things while out of communications range.