[1.3] kOS Scriptable Autopilot System v1.1.3.0

[raath]

I have a question about setting thrustlimit on an engine. I have a craft that has a very sepcific flight profile and as the altitude increases, one of the engines needs to increase it's thrust limit while the other engines remain at 100% as the COM shifts.

I'm trying to adjust it with this :

    list engines in eng.
    set eng[1]:thrustlimit to 100.00 .

but it sets the trustlimit at 1. The documentation is not clear on how this value should be set.

[Fell-x27]

Is it work with IR? Pleasy, say YES! Please!

[kcs123]

Is it work with IR? Pleasy, say YES! Please!

Just look at few pages back in this thread and you will find a lot of videos and pictures with kOS and IR parts. Hint: those mech a like crafts made with IR parts

[Fell-x27]

Just look at few pages back in this thread and you will find a lot of videos and pictures with kOS and IR parts. Hint: those mech a like crafts made with IR parts

YES YES YES! It happened! IR+KOS! Better news in this year!

[Kartoffelkuchen]

Hi, i've got another question: How do I calculate the actual g-force on my rocket?

@raath: Maybe try it with 1 instead of 100.0 ? Because when you want to throttle up the engine you also print 1. 1 is 100%, 0.75 = 75% etc. Try that.

[Dunbaratu]

I have a question about setting thrustlimit on an engine. I have a craft that has a very sepcific flight profile and as the altitude increases, one of the engines needs to increase it's thrust limit while the other engines remain at 100% as the COM shifts.

I'm trying to adjust it with this :

    list engines in eng.
    set eng[1]:thrustlimit to 100.00 .

but it sets the trustlimit at 1. The documentation is not clear on how this value should be set.

Like the normal thrust it goes from 0.0 to 1.0 on the same scale. i.e 75% is 0.75

[Parastie]

Hey I've got another question.

If i do print ship:position I will get v(0,0,0) and that's a vector right?

And when I print part:position, is that number relative to the ship, or is it relative to the universe, or am I just not understanding how the vector systems works?

Basically, I'm trying to get the side port to line up with a target. The side port's position shouldn't change relative to ship's position as it's fixed to the ship. I should be able to just be add the port's position to the ship's position, and then minus that from the target's position to get where they are relative to each other right?

My problem is, the port on the ship's position when i type, print port:position (and i'm certain it is the port on the ship) keeps changing, and i'm not certain how exactly i should fix it in order to zero out movement relative to target and get alignment for a docking.

I understand that we're suppose to figure this stuff out on our own, but any any help (including pointing me to some reading material so i can understand this better) would be a great!

Edited January 24, 2015 by Parastie

[thegreatgonz]

I'm looking for a way to access (or compute) the current vessel's torque, but I can't find anything. Am I missing something, or is that information not available? It would be really nice to have, because it would enable more sophisticated steering algorithms, e.g. a physics-based open loop as the primary control signal, with PDI only for error correction. This doesn't seem cheaty, since it would be exactly analogous to what kOS already gives us for thrust.

[erendrake]

I'm looking for a way to access (or compute) the current vessel's torque, but I can't find anything. Am I missing something, or is that information not available? It would be really nice to have, because it would enable more sophisticated steering algorithms, e.g. a physics-based open loop as the primary control signal, with PDI only for error correction. This doesn't seem cheaty, since it would be exactly analogous to what kOS already gives us for thrust.

I agree that this kind of information is not cheaty and is exactly the kind of information I would like to expose to you guys. right now the two big challenges to getting that done is time and building the algorithm (which is really just more time). Torque is a more involved calculation than thrust.

Edited January 25, 2015 by erendrake

[thegreatgonz]

I agree that this kind of information is not cheaty and is exactly the kind of information I would like to expose to you guys. right now the two big challenges to getting that done is time and building the algorithm (which is really just more time). Torque is a more involved calculation than thrust.

Would it be much easier to just expose the raw data (max torque numbers for SAS, max gimbal for engines, and enable/disable state for both)? A higher-level interface would obviously be preferable, but that'd at least be a start.

[soulsource]

I've just sent a pull request for a "fix" for issue 389 (LOCK STEERING broken for RCS-only (no torque) ships), which has to do with the calculation of torque applied by RCS.

Edit:

While LOCK STEERING is now working, the GetTorque function needs to be improved before the resulting torque values can be exposed to users. Previously the pitch/yaw torque applied by RCS was calculated by multiplying the (scalar) maximum thrust of the RCS thruster by the (scalar) distance to the COM, and the roll torque was treated as being zero. While this was only half the issue - the second half had to do with addressing the RCS modules - I now improved this by calculating torques using the distance to the roll axis for roll torque, and the distance along the roll axis for pitch/yaw torque. Obviously these formulas would only be correct if the RCS port nozzle could pivot to any direction.

For real torque values one would need to take into account the nozzle direction of the RCS ports, and be aware that each of the nozzles can only apply positive thrust...

I've been playing around, and I now think that the torque values returned by the GetTorque function should be correct for crafts with (reasonably symmetric - it's assumed that RCS torque is the same for both rotation directions) RCS as well. It does now calculate real torque pseudovectors and projects them on the steering axes. Also, the state of the RCS toggle and the fuel availability are now taken into account, and individual disabled thrusters are counted as well. The returned numbers match with the torque values displayed by MechJeb (what is good, as I didn't look at the source code of MechJeb).

Edited January 25, 2015 by soulsource

[Drew Kerman]

I'm not entirely sure what these messages are telling me here:

"No maneuver nodes present!" are messages from my program. The rest is kOS pointing to things in code but not telling me what, if anything, is wrong. The program seemed to execute okay - it activated RCS and thrusted as required.

This code was last tested working fine with no weird code callouts on 0.15.3

Edit: Did a second run to circularize my hohmann transfer and didn't get any code callouts. In the previous maneuver I noticed a second 0dv maneuver node had appeared later in my orbit and I removed it - that may have caused something to go screwy - no idea where that second node came from...

Edited January 26, 2015 by Gaiiden

[togfox]

Does this work for you?

// Assumes that at this point of your script,
// lat1, long1, and lat2, long2 are the latitude and longitude of the 2 points you're interested in.
//
SET geoPos1 to LATLNG(lat1,long1).
SET geoPos2 to LATLNG(lat2,long2).
print "Position vector of geoPos1 is " + geoPos1:POSITION.
print "Position vector of geoPos2 is " + geoPos2:POSITION.
print " --- ".
set vector1To2 to (geoPos2:POSITION - geoPos1:POSITION).
print "Straight line vector distance from pos1 to pos2, "
print "(ignoring terrain and surface curvature)"
print "is this: " + vector1To2:MAG.

Sorry for the late reply - vacation. Yes - this does work fantastically well thank you.

[Dunbaratu]

"No maneuver nodes present!" are messages from my program. The rest is kOS pointing to things in code but not telling me what, if anything, is wrong.

Well, you claim that "No maneuver nodes present!" is a message your own program put out, but if that's true then it's an incredibly unfortunate coincidence that you chose that exact phrasing because that happens to ALSO be the the exact phrasing used by the kOS code itself, here:

        if (vessel.patchedConicSolver.maneuverNodes.Count == 0)
        {
            throw new Exception("No maneuver nodes present!");
        }

So the complaint coming from kOS is the very condition you yourself also detected. You can't say nextNode:ETA when there isn't a nextNode. So when you see that there's no nextnode, you have to avoid calling nextNode:ETA.

[Drew Kerman]

lol I see. Haven't looked at the code in a while so I thought the "no maneuver node" was my own debug message I put in there since I remembered using someone else's code to test for the existence of a future node rather than relying on any built-in kOS routine.

Ok it was def that mysterious node I removed. Will have to keep my eyes open to see if it appears again.

[postalbyke]

Does anyone else have a problem with losing electricity while paused? I turned off the CX-4181 and the problem stopped...

[VentZer0]

Yep, I fixed it with a radioisotope generator in my craft, all it does now is that it will restart the terminal. Before it made the whole plane completely unresponsive once the juice ran out.

[Dunbaratu]

Does anyone else have a problem with losing electricity while paused? I turned off the CX-4181 and the problem stopped...

Whoa seriously??? I didn't even realize that was possible. Basically that would have to mean that KSP still calls the Update()'s even when the game is paused, AND that it's acting as if time has passed even when paused.

The mod calculates how much electricity was used each update by looking at how much time has passed in the physical world since the last update, using KSP's own reported value for it: Timewarp.fixedDeltaTime.

But if that is passing even when paused, something weird is happening.

Edited January 28, 2015 by Steven Mading

[undercoveryankee]

Whoa seriously??? I didn't even realize that was possible. Basically that would have to mean that KSP still calls the Update()'s even when the game is paused, AND that it's acting as if time has passed even when paused.

The mod calculates how much electricity was used each update by looking at how much time has passed in the physical world since the last update, using KSP's own reported value for it: Timewarp.fixedDeltaTime.

But if that is passing even when paused, something weird is happening.

I thought it was FixedUpdate() that got called every fixedDeltaTime, and Update() gets called every graphics frame. Most mods that produce or consume resources do it in FixedUpdate. Perhaps this is why.

[Dunbaratu]

I thought it was FixedUpdate() that got called every fixedDeltaTime, and Update() gets called every graphics frame. Most mods that produce or consume resources do it in FixedUpdate. Perhaps this is why.

The power drain code is very old code dating back to before we took things over, so it may just be a mistake that's always been in there. In general I've never been entirely happy with using Update() to run the CPU instructions in the first place, since that means that the same CONFIG:IPU setting means different things on different people's computers. I'm just a little afraid to move that code into FixedUpdate for fear of what might break.

At any rate, I've made an issue for it on the github here:

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

[Wercho]

I'm having trouble with the "controlfrom" suffix. Specifically, I get an error whenever I try to use it. Could someone look at my code and tell me what I did wrong, or if this is a bug.

This code makes sure the part controlling from is a dockingport.

LIST DOCKINGPORTS IN dport.
SET contfrom TO false.
FOR dp1 IN dport {
	IF dp1:controlfrom {SET contfrom TO true. SET contdp TO dp1.}
}
IF not contfrom { PRINT "Not controlling from a docking port.".}

Error:

Operation is not valid due to the current state of the object at [I]filename[/I] on archive, line 8
IF dp1:controlfrom ...

The ^ points to controlfrom

I've also gotten errors telling me that objects of type "PartValue" don't have a "CONTROLFROM" suffix, even when the part in question is a command pod.

[togfox]

Possible bug:

ship:surfacespeed is reporting very low values ( < 2 ) while mechjeb and the navball are showing values in the mid 20's (~25 m/s). I'm hoping ship:surfacespeed indicates horizontal travel across a surface. Should I write this up in github?

[Dunbaratu]

Possible bug:

ship:surfacespeed is reporting very low values ( < 2 ) while mechjeb and the navball are showing values in the mid 20's (~25 m/s). I'm hoping ship:surfacespeed indicates horizontal travel across a surface. Should I write this up in github?

Not a bug. The problem is that the base game (and mechjeb) use the term "surface speed" to mean a 3D speed in a way that in no way is an actual surface speed. It's the speed in a reference frame that subtracts the rotation of the planet below you from your orbital speed, but is still a speed in 3D space, not a speed along the surface. In other words, it counts your vertical motion into the speed too, which isn't *really* a surface speed. It's just a poor choice of words in the main game that mechjeb inherited and kept using. I'd have called it planetary versus orbital or something like that.

Anyway, if you actually do want the game's version of surface-reference-frame speed, then do this:

print ship:velocity:surface:mag.

Surfacespeed is the 2D projection of that, down into the horizontal plane.

[VentZer0]

I am having a really hard time understanding how one can get information about ship part modules, I am trying to get the different things I can do with a certain part on my craft namely: BDArmory's WeaponManager, the Ship:Part is called 'missileController' but I can't seem to get the actions I can do with this part through right click interactions. I've consulted the manual, but the examples didn't really help me. I get errors that I cant have this or that prefix/suffix for the part... etc. I am really at a loss here Listings are very confusing to say the least IMO.

[Dunbaratu]

I am having a really hard time understanding how one can get information about ship part modules, I am trying to get the different things I can do with a certain part on my craft namely: BDArmory's WeaponManager, the Ship:Part is called 'missileController' but I can't seem to get the actions I can do with this part through right click interactions. I've consulted the manual, but the examples didn't really help me. I get errors that I cant have this or that prefix/suffix for the part... etc. I am really at a loss here Listings are very confusing to say the least IMO.

I don't have BDarmory so I can't really test this out myself. But in general I could maybe give you live help by video conference if you want to arrange a time sometime today within the next 7 hours or so. I should be home today during that time. (remember to tell me your timezone too if you want this). I much prefer google hangouts for this, but I might be able to do it by skype, although I haven't fired up skype in over a year. Give me a PM with contact details if you want to do this.

The partmodules thing was my baby (although erendrake revamped the suffix infrastructure, allowing method suffixes (suffixes with arguments), which was needed for it to work .. anyway that's another topic for another time) The point is that I like the system a lot and it pains me to see it being so hard to get working for some people. I admit that it's messy and confusing. Partly that's because the underlying implementation of things in KSP itself is a bit messy and it was hard to abstract all the mess away without introducing cases where the abstraction breaks, so I had to expose *some* of the messiness to kerboscript.