[1.3] kOS Scriptable Autopilot System v1.1.3.0

[stevehead]

kOS used to use its own complex parts walk algorithm to find all the fuel. Now it just relies on KSP's own API for it. Is there a discrepancy between the fuel shown in the indicators on the side and what kOS says? I.e. when it says there's 100 units left, are the green indicators all empty, or do they also show fuel left? If they also show fuel left then there's not much we can do - that means KSP itself thinks there's fuel for some of the active engines.

If it is showing zero fuel in the indicators when kOS says 100, can you show a screenshot of the game, showing where the 100 units of fuel are coming from (highlight the tank it is counting that it shouldn't be and show the popup for it if you can)? It's hard to diagnose from just the verbal description.

Sorry, I was rushing to dinner when I first posted. I've got two screenshots below. The first shows the fuel tank in the second stage that is causing the issue, while the second is showing that the first stage tanks are in fact empty. Also the first "print stage:liquidfuel" is right after launch (should be ~568, but it is adding the second stage tank) and the last is after the first stage fuel is depleted.

Screenshot 1:

https://www.dropbox.com/s/3hsp9bl4b1j5jvj/screenshot0.png?dl=0

Screenshot 2:

https://www.dropbox.com/s/setsobaimvg5xq9/screenshot1.png?dl=0

Also, my mistake. It wasn't the interstage fairing adapter between the two stages causing the issue. I have another interstage fairing adapter right above the highlighted tank in the first screenshot that is housing a probe core, reaction wheel, a battery and a remote tech antennae but no fuel tanks. When I remove that adapter with everything in it, STAGE:LIQUIDFUEL works just fine. I am aware that this could easily be an issue with procedural fairings, and I have no expectations of a fix if it is indeed that mod's problem; just wanted to point it out if it happens to be a bug in kOS. For now, I have switched to checking thrust instead of fuel for the auto-staging in my script.

[Dunbaratu]

Also, my mistake. It wasn't the interstage fairing adapter between the two stages causing the issue. I have another interstage fairing adapter right above the highlighted tank in the first screenshot that is housing a probe core, reaction wheel, a battery and a remote tech antennae but no fuel tanks. When I remove that adapter with everything in it, STAGE:LIQUIDFUEL works just fine. I am aware that this could easily be an issue with procedural fairings, and I have no expectations of a fix if it is indeed that mod's problem; just wanted to point it out if it happens to be a bug in kOS. For now, I have switched to checking thrust instead of fuel for the auto-staging in my script.

Well, looking at your screenshot it is definitely wrong, but I'm not sure what we can do about it. all we are doing is literally just asking KSP to tell us what resources are currently in the stage, with this call:

        var resource = shared.Vessel.GetActiveResources();

That GetActiveResources() is SQUAD's own call. It gives a list of all the resources that are (supposedly) currently "active" where "active" means you can currently "get to them". Resources that are on the ship but not reachable at the moment aren't supposed to appear in that API call. Obviously something about how the interstage adapter is working is allowing GetActiveResources() to count the fuel as active even though the part isn't allowing fuel flow to reach it. I have no clue how to fix this, save having to re-implement our own manual resource getter, which we deliberately took out because it was in danger of being forward-incompatible with whatever SQUAD changes next.

- - - Updated - - -

- - - Updated - - -

As a temporary workaround, what would happen if you inserted a stock decoupler just under the interstage fairing, and set them to decouple together in the same stage step? I think the stock decoupler might break the fake crossfeeding connection that the fairing is reporting?

[ManTrelk]

Since I didn't get a clear answer last time: if I use a command to to change compass heading like LOCK STEERING TO HEADING(90,pitch) should my vessel tilt off axis when changing its compass heading to 90? Or should it roll smoothly along its longitudinal axis? Right now in my game giving any basic direction commands using LOCK causes the vehicle to pretty much lose control a few meters above the launchpad, making kOS unusable. Is it a bug on my end, or with kOS?

[Ziw]

Since I didn't get a clear answer last time: if I use a command to to change compass heading like LOCK STEERING TO HEADING(90,pitch) should my vessel tilt off axis when changing its compass heading to 90? Or should it roll smoothly along its longitudinal axis? Right now in my game giving any basic direction commands using LOCK causes the vehicle to pretty much lose control a few meters above the launchpad, making kOS unusable. Is it a bug on my end, or with kOS?

Can you post a screenshot of your rocket and point to it's root part?

[Dunbaratu]

Then why do I remember over and over again seeing the engine nozzles tilting back and forth as kOS yanks the controls back and forth (in its overzealous way)? I know I've seen it do this a lot, but then again I don't play under RO. Is it a specific thing the RO mod does to change the API for gimbals?

I have to apologise to all the people I was being incredulous toward about this. I have just confirmed that engine gimbals are not being used by kOS even in Stock. I have absolutely NO idea why. They used to work just fine back when I was writing kOS scripts regularly over a year ago on the old Nivekk version of the mod. I know this for a fact because I saw engine exhaust being deflected back and forth as the controls were madly slammed back and forth by the overzealous steering algorithm. I don't know what disabled them. I know it was *some* sort of edit because it definitely used to work. But I'm not the one that usually touches that end of the mod so I have no clue what happened.

But you're right. Engine nozzles no longer get aimed by lock steering. They definitely DID at one point.

[avi]

Since I didn't get a clear answer last time: if I use a command to to change compass heading like LOCK STEERING TO HEADING(90,pitch) should my vessel tilt off axis when changing its compass heading to 90? Or should it roll smoothly along its longitudinal axis? Right now in my game giving any basic direction commands using LOCK causes the vehicle to pretty much lose control a few meters above the launchpad, making kOS unusable. Is it a bug on my end, or with kOS?

LOCK STEERING is kind of a mess right now, and it's especially bad while accelerating, so unless you're comfortable working with raw control, you my not want to use the mod until it's fixed.

Speaking of which, does anybody have experience steering using raw control? I'm having trouble thinking of a good way to do it.

[ManTrelk]

LOCK STEERING is kind of a mess right now

:| Oh? I wasn't expecting that answer. That does sound like my problem though. Why isn't this a bigger deal? I'd have thought pretty much everyone would be using that command.

Can you post a screenshot of your rocket and point to it's root part?

It happens with any design I make. A Mk1 command pod as root, kOS core, a 1m tank and an LV-909. Or one of my heavy lifters. Any craft that locks steering as it accelerates off the launchpad (or just above the launchpad, or on the launchpad) has this problem.

[celem]

When you use LOCK STEERING TO HEADING (x,y) then it only smoothly transfers from the current heading to the new one if its roll axis is correctly orientated.

You are launching off the pad, probably locked up or 90,90. You order lock heading (90,85) and the ship will make its way to that heading via a somewhat circular route, in FAR this will usually wreck the launch/ship. This is not a bug or anything to do with engine gimballing, which may indeed have issues, but this is not it.

If however on the pad you lock steering to R(0,0,0) + HEADING(90,90). The ship will roll 90 degrees on launch and you will find that a later call to HEADING (90,85) will tip over smoothly as you planned without wandering around. This is a sideeffect of the orientation of your root piece in the VAB. remember that KSP always puts your command pod 90 degrees off, its starting with the ship twisted 90 degrees off true...

This is why you see this issue with every vessel you build, they all have the same root piece orientation (its a default).

While I accept that some people are having issues with gimbaling right now (im not, kOS appears to gimbal my engines, its certainly vectoring the plumes and locking the gimbal removed a wide-range of stability issues i was having), lock steering is fine. Ordering a new heading locked and having the ship wander about the navball is not a bug with LOCK STEERING, its your failure to allow for roll.

For what its worth, launching with FAR i use:

LOCK STEERING TO HEADING(90,90).
    WAIT 2.
	STAGE.
	WAIT 1.
	LOCK STEERING TO R(0,0,0) + HEADING(90,90).

This clears the launchpad, then rolls. If you then call a pitch over heading lock then its smooth as silk. If you skip the roll order then calling (90,85) will make it circle around slightly (and in FAR tumble).

The mod is entirely usable, with cooked control. I can get a ship to launch in FAR, transfer to Mun and land without ever using anything but cooked control, which wouldnt be possible if it wasnt obeying the commands correctly..

If you want to be certain that every single LOCK TO HEADING will go via the shortest route then you need to query your SHIP:FACING first and include a roll into the lock heading command that equates to your current roll.

Steering with raw controls is a little complex. Ive used it in FAR launches for pitch over, but using raw means the extra step of checking to see when enough movement has happened and the new heading is the desired one. You can outright replace cooked controls with things like :

UNTIL HEADING = X 
{
SET SHIP:CONTROL:STARBOARD TO -0.1.
}
SET SHIP CONTROL:STARBOARD TO 0.

This will yaw until the ships heading is X. Its a powerful method of controling the ship since its the only way to get genuinely smooth inputs.

Edited April 2, 2015 by celem

[Dunbaratu]

Since I didn't get a clear answer last time: if I use a command to to change compass heading like LOCK STEERING TO HEADING(90,pitch) should my vessel tilt off axis when changing its compass heading to 90? Or should it roll smoothly along its longitudinal axis? Right now in my game giving any basic direction commands using LOCK causes the vehicle to pretty much lose control a few meters above the launchpad, making kOS unusable. Is it a bug on my end, or with kOS?

The actual problem is that the default orientation KSP puts your rocket into on the pad is (for some dumb reason I never understood) one in which the rocket is aimed north/south - so pitching down goes north, pitching up goes south, and you yaw right to go east. Given that most of the time you are launching to the east, this has NEVER made any sense to me. But that is how the game works.

But the orientation that HEADING(90,pitch) is trying to use is one that's a bit more sensible and "airplane" like - with your top aimed up to the sky, as expected. This means that to go from your starting launchpad orientation to the heading involves doing a 90 degree roll as well to aim your roof at the sky.

The problem is that LOCK STEERING is attempting to do both of these operations simultaneously, which is why you see it describe a weird arc as it pitches down. It's trying to roll into an orientation aligned with the horizon while at the same time trying to pitch down, and basically precessing.

The best fix, I think is when still aiming straight up, right off the launchpad, to first roll your rocket to an orientation in which your bottom aims east, your top aims west, and your "wings" are east/west, and then after doing that, then start using HEADING to pitch down.

What I usually do to make this work is to never LOCK STEERING TO UP in the first place. Instead of "UP", I do LOCK STEERING TO HEADING(90,89.5) when I first leave the launchpad. This will get me rolled into the same orientation as I'll be using once I start pitching down further.

(The reason for HEADING(90,89.5) instead of HEADING(90,90) is because I'm avoiding gimbal lock. I assume it has no idea which way to roll you to align with the horizon when you are aimed literally straight up - all rolls are aligned with the horizon in that configuration.)

[avi]

While I accept that some people are having issues with gimbaling right now (im not, kOS appears to gimbal my engines, its certainly vectoring the plumes and locking the gimbal removed a wide-range of stability issues i was having), lock steering is fine. Ordering a new heading locked and having the ship wander about the navball is not a bug with LOCK STEERING, its your failure to allow for roll.

It's not clear to me that this isn't a bug; one could argue that LOCK STEERING should roll while doing the transition smoothly. It exists on the border between bug and unrefined design.

You can outright replace cooked controls with things like :

UNTIL HEADING = X 
{
SET SHIP:CONTROL:STARBOARD TO -0.1.
}
SET SHIP CONTROL:STARBOARD TO 0.

This will yaw until the ships heading is X. Its a powerful method of controling the ship since its the only way to get genuinely smooth inputs.

That will cause the ship to enter an uncontrollable spin; you have no way of pushing the controls in the other direction once it's approaching the desired vector. Using raw controls is much more complicated, and you'll probably need to build a PID loop or something similar.

[stevehead]

As a temporary workaround, what would happen if you inserted a stock decoupler just under the interstage fairing, and set them to decouple together in the same stage step? I think the stock decoupler might break the fake crossfeeding connection that the fairing is reporting?

I'll give that a try this evening to see if it does anything; I'll let you know what I have found. For me, it's mostly no longer an issue since I have replaced the code with the following I have found in an earlier post that works fine for my auto-launch script:

SET stagemaxthrust TO ship:maxthrust.
WHEN (ship:maxthrust < stagemaxthrust OR ship:maxthrust < 1) THEN {
    STAGE.
}.

I do have some lifters with SRBs that I wish to manually stage that gets a little messed up with the script not checking specifically for liquid fuel, but I already have a fix worked up mentally I will put into place tonight.

Update:

Actually, I could probably just drop "ship:maxthrust < stagemaxthrust" in the when statement I just realized.

Edited April 2, 2015 by stevehead

[Sonny_Jim]

Quick question, how do I set my throttle so it stays there after my program finishes? Right now my autolaunch program switches back to half throttle after it's finished :\

EDIT: I came up with a hacky way to do it, which was to shutdown all engines.

Oh and for what it's worth, this is what I came up with for an autostager that'll work with SRB/asparagus staging. It's a little CPU intensive though

http://pastebin.com/gx0SpDSs

Edited April 2, 2015 by Sonny_Jim

[Ziw]

quick question, how do i set my throttle so it stays there after my program finishes? Right now my autolaunch program switches back to half throttle after it's finished :\

edit: I came up with a hacky way to do it, which was to shutdown all engines.

Oh and for what it's worth, this is what i came up with for an autostager that'll work with srb/asparagus staging. It's a little cpu intensive though

http://pastebin.com/gx0spdss

set ship:control:pilotmainthrottle to 0.

[Sonny_Jim]

Thanks, although I found an interesting bug, where if you use ENG:SHUTDOWN on an engine that's running, the visual effects still run even though the engine isn't putting out any thrust.

EDIT: Reworked my asparagus stager so it uses a lot less CPU so it'll work (with smallish ships) with 150 IPU

http://pastebin.com/6j3XTnH6

Edited April 3, 2015 by Sonny_Jim

[ManTrelk]

Small question, why does

WHEN STAGE:LIQUIDFUEL <0.01 THEN {

SET stagetime TO ROUND(TIME:SECONDS).

PRINT "Staging...".

UNLOCK THROTTLE.

SET twrset TO 1.1.

}

result in the error "Tried to push infinity to the stack?"

The problem line is SET stagetime TO ROUND(TIME:SECONDS).

[Dunbaratu]

Small question, why does

result in the error "Tried to push infinity to the stack?"

The problem line is SET stagetime TO ROUND(TIME:SECONDS).

ROUND requires two arguments: value to round, and decimal places to the right of the dot to round to. i.e. ROUND(100.11111 , 2) would return 100.11 while ROUND(100.11111, 0) would return 100.

In the current incarnation of kOS, built-in functions like ROUND() are not really able to count the number of values pushed onto the argument stack to ensure they are correct, so it can't tell you that there's a mismatch. Instead ROUND() tries to unconditionally read two values even when you didn't pass two values, leading to very confusing errors as it gets the stack misaligned.

By the way, that's fixed in the functions revamp that should be getting released "any day now". (We have the goal of wanting it released before KSP 1.0 drops. We're in the final stretch for release.) Now it will be able to bomb out with a proper error message when you didn't pass the number of arguments it was expecting.

In principle the ability to detect a count of the number of args also means we could start supporting built-in functions with multiple varying number of arguments (i.e. maybe we could make ROUND detect when you only passed it one arg, and have it presume you meant to round to the one's place when it sees that). (For now we haven't done that, but the infrastructure is in place so we could go through all the built-in functions and start doing that sort of thing with them in the future.)

Edited April 3, 2015 by Steven Mading

[ManTrelk]

Hmm, okay. Thanks for the advice. I don't think that's the issue though, because I put ROUND in there to try and fix it. The error was occurring before ROUND was in the code.

Will this update add support for user defined functions? Because I cannot WAIT for that.

Now that I've done a bit more testing. I'm not sure that the line I pointed to was actually the problem - it's hard to say. The error only occurs *most* of the time I run this script, so I'm not sure if it's just coincidence that it disappears when I remove that line.

There's also the fact that when the error *doesn't* appear, reverting my ship seems to break KSP. I get a screen with no ship visible, only the skybox, and no velocity. And I can't revert. I'm 90% sure it's related to kOS. Maybe it's a problem elsewhere in my script which is only manifesting itself when it gets to that trigger? I could post my whole script if someone wants to spend their time and hunt for the bug (It's my first script though, so I'd rather not embarrass myself ).

Edited April 3, 2015 by ManTrelk

[Dunbaratu]

There's also the fact that when the error *doesn't* appear, reverting my ship seems to break KSP. I get a screen with no ship visible, only the skybox, and no velocity. And I can't revert. .

That is a very common symptom of a lot of different bugs. Basically, KSP is doing a LOT of work when switching scenes, and often when data is set up wrong, that's where it manifests as a problem. It's also where running out of memory can manifest itself and cause that effect.

I get this a lot with different things and sometimesit's a very odd interaction between different mods that does it (each mod alone works fine, but install them together and it screws up).

More useful than your code would probably be the output_log of the game when that occurs (although seeing the code would be useful too). It will contain the verbose logs of all the exceptions thrown by all the different installed mods as the scene was changing. Often that will help us diagnose which mod is "at fault".

[ManTrelk]

Okay. Well, I won't waste your time with that. I might post in the mod support forum later. I'm guessing the problem involved kOS in some way though, because it's only started appearing since I've installed the mod.

Any advice on the "Tried to push infinity to stack" error? It doesn't seem to affect anything, it's just annoying.

[Dunbaratu]

User Functions Teaser vid:

Wherein I demonstrate user functions by making a generic PID controller function and using it to form a small hover example script.

Edited April 3, 2015 by Steven Mading

[Carsaxy]

How do I check if a string is inside another string?

[Ziw]

How do I check if a string is inside another string?

Unfortunately right now there is no way to do it in kOS. String manipulation is a planned feature after 0.17

[Sonny_Jim]

Is there a way for kOS to find out what biome the ship is in?

EDIT: Ah ok, it looks like there is a branch that has it, but it's been forgotten about:

https://github.com/erendrake/KOS/commit/b56c43ae6acb57d1e21460b4d73a953266dbbce5

EDIT2:

If anyone is struggling to find a list of parts and partmodules a ship has, I wrote a handy script here:

http://pastebin.com/qNpW8ryF

Edited April 3, 2015 by Sonny_Jim

[celem]

Hmm, bit confused here....

Im trying to knock together a transfer window calculator. Had moderate success using BODY:LONGITUDE to get the longitude of the planets over the sun, which lets me pretty simply pluck out the phase angle. I then decided to try a few other things, in particular I decided to try pulling orbital velocity vectors out for each body, which I then planned to put through VANG...

Problem is, Kerbin:Velocity:Orbit always returns (0,0,0). All the other planets seem to work fine, and kerbin:velocity:surface seems to also. Why is Kerbin:Velocity:Orbit coming up as an empty vector? Its not the reference point, Kerbol itself is...

While im talkin about body velocity... Sun:Velocity:Orbit returns a vector I didnt expect (this is where i expected 0,0,0). Sun:Velocity:Surface is back to triple zeros. What exactly is this suffix returning? I thought it was a vector relative the the SoI body, which for all the bodies i've tried is the Sun, (And for the Sun itself I have no clue what its non-zero orbital velocity vector is meant to mean) Does the Sun rotate at the exact same speed as Kerbin's orbital period or something? (though this would lead to a zero vector for kerbin:surface rather than kerbin:orbit.)

Edited April 3, 2015 by celem

[Dunbaratu]

Problem is, Kerbin:Velocity:Orbit always returns (0,0,0). All the other planets seem to work fine, and kerbin:velocity:surface seems to also. Why is Kerbin:Velocity:Orbit coming up as an empty vector? Its not the reference point, Kerbol itself is...

All velocities are coerced into the reference frame of the current SOI body. You're seeing the velocity of the sun *relative to kerbin*.

Which is why the velocity of kerbin is zero. It's showing how fast kerbin is moving relaive to.. itself.