[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Dunbaratu]

Based on the description of the "garble", maybe what you're seeing is Z-fighting?

Yes but the point is there should BE no overlapping polygons in which to even HAVE Z-fighting. I suspect that the coordinates of the attachment points are slightly INSIDE the mesh model, causing the two parts to overlap a bit.

I personally doubt the model is the problem since I'd like to think that if old part models were causing new problems,

Except it's not a new problem.

we'd see it happening among more part-mods. And more importantly, why didn't the part simply explode? (rather than causing NullReferenceExceptions and non-working GUI buttons?) I'm fearful that the structural failure may be a symptom of something deeper.

There are two entirely different problems being reported:

1 - part just vanishes with no explosion, causing things to become detached.

2 - there is an explosion

When I mentioned the possibility of intermingled parts clipped into each other, that was for trying to find an explanation for problem 2, not problem 1.

The exceptions in the log correspond to problem 1 - they are causing the part to fail to be finished being created so KSP skips creating the part. KSP is not very fault-tolerant of exceptions thrown by PartModules. They tend to abort the creation of the part itself that they're attached to.

[Camacha]

There are two entirely different problems being reported:

1 - part just vanishes with no explosion, causing things to become detached.

2 - there is an explosion

In my experience the vanishing has to do with any program running on a kOS unit while being saved, though I have not tested this through. Is there any method or procedure known that reproduces the problem? If there is, I can test swapping out the kOS model for a probe core.

[Dunbaratu]

In my experience the vanishing has to do with any program running on a kOS unit while being saved, though I have not tested this through. Is there any method or procedure known that reproduces the problem? If there is, I can test swapping out the kOS model for a probe core.

Absolutely true that this is *one* cause of it, but I've heard reports of it happening in other cases too.

There's code in kOS that *attempts* to save the value of all variables in memory when the craft goes on rails, and then restores it when the craft gets fully loaded again. But this has never really worked ever since complex structures were added ages ago (it works on integers, floats, strings, and booleans, but nothing more complex than that), and it can throw uncaught exceptions. In its current state I'd rather see it disabled entirely since it doesn't really work anyway and at least disabling it would make it stop throwing exceptions. It's supposedly getting trapped now so the exceptions don't percolate upward but I'm still seeing complaints about the problem from time to time.

Edited January 2, 2015 by Steven Mading

[VentZer0]

Yes that.

If program 1 does "SET X TO 5." and then runs program 2, and program 2 does a "SET X TO 10" then, there was only ever 1 "X", and Program 2 just changed Program 1's X from 5 to 10. I mean global in that sense.

However, is there is ALSO a variable X on a completely different SCS part, then it shouldn't be affected.

Very good, that's what I need. Now I can actually code my atmospheric drone autopilot.

My attitude detection system works nicely, eventhough its so simple ...

 SET counter TO 0.
UNTIL counter > 1000 {
    SET counter TO counter + 1.
    SET a1 TO VANG(SHIP:FACING:STARVECTOR,SHIP:UP:VECTOR).
    SET a2 TO VANG(-1*SHIP:FACING:STARVECTOR,SHIP:UP:VECTOR).
    SET b1 TO VANG(SHIP:FACING:STARVECTOR,SHIP:BODY:POSITION).
    SET b2 TO VANG(-1*SHIP:FACING:STARVECTOR,SHIP:BODY:POSITION).
    SET c1 TO VANG(VCRS(SHIP:FACING:FOREVECTOR,SHIP:FACING:STARVECTOR),SHIP:UP:VECTOR).
    SET d1 TO VANG(SHIP:FACING:FOREVECTOR,SHIP:UP:VECTOR).

    IF ROUND(d1) = 90 {
        CLEARSCREEN.
        PRINT "pitch attitude level".
    } ELSE {
        IF ROUND(d1) = 0 {
            CLEARSCREEN.
            PRINT "pitch attitude : straight up".
        } ELSE {
            IF d1 < 90 {
                CLEARSCREEN.
                PRINT "pitch attitude : nose up".
            }.
        }.
        IF ROUND(d1) = 180 {
            CLEARSCREEN.
            PRINT "pitch attitude : straight down".
        } ELSE {
            IF d1 > 90 {
                CLEARSCREEN.
                PRINT "pitch attitude : nose down".
            }.
        }.
    }.

    IF ROUND(a1) = 90 AND ROUND(a2) = 90 {
        PRINT "wing attitude level".
    } ELSE {
        IF a1 < a2 AND b1 > b2 {
            IF ROUND(c1) < 90 {
                PRINT "wing attitude : rolled left".
            } ELSE {
                PRINT "wing attitude : overrolled left".
            }.    
        } ELSE {
            IF a1 > a2 AND b1 < b2 {
                IF ROUND(c1) < 90 {
                    PRINT "wing attitude : rolled right".
                } ELSE {
                    PRINT "wing attitude : overrolled right".
                }.
            }.
        }.
    }.
    wait 0.01.
}.

[Camacha]

It may be the case that solving it will require just ditching the current part model entirely and making new ones from scratch. My problem is that this gets into an area I know very little about. My training is on the programming end of things, not the graphic design end of things.

I might be able to help. I have a design background and know my way around graphics programs. Though more of a CAD modeler, a night of fiddling with Unity convinced me I can produce something functional. I have been wanting to expand my skill set into the more traditional 3D graphics type and I cannot think of a better way to do this than to make something useful. The biggest caveat might be that I am pretty busy for the unforeseeable future, so my time to work on this is fairly limited.

Please note that about all of it is a placeholder, I just wanted to check out the workflow and it should really be considered a proof of concept. There are some obvious problems that need to be solved, like proper scaling and texture work. Important bits already work though, like a properly centred origin and attachment rules that seem to work out okay.

Edited January 2, 2015 by Camacha

[Dr_Goddard]

I wrote a routine to convey a simple two variable command through a "run" command.

It seemed easier than programming all the routines each time.

Maybe a bit more intuitive as well for robotics.

Each device(or set of devices) is now called by a number and an angle.

I'm trying to figure out the best method now for coordinated movements, which are probably going to be proportional.

run seek(0,0).

run seek(-45,4).

run seek(45,5).

run seek(30,1).

run seek (30,2).

run seek (180,3).

run corners.

Edited January 2, 2015 by Dr_Goddard

[erendrake]

I wrote a routine to convey a simple two variable command through a "run" command.

It seemed easier than programming all the routines each time.

Maybe a bit more intuitive as well for robotics.

Each device(or set of devices) is now called by a number and an angle.

I'm trying to figure out the best method now for coordinated movements, which are probably going to be proportional.

run seek(0,0).

run seek(-45,4).

run seek(45,5).

run seek(30,1).

run seek (30,2).

run seek (180,3).

run corners.

http://youtu.be/91o8jmf-OxY?list=UUI...fQ9Dt23NzNyOTg

Very cool, Do you mind sharing the script with us?

[Dr_Goddard]

Not at all.

I will put up the machine and the code in the AM

[Dr_Goddard]

Craft http://pastebin.com/SsWnDeq6

Installed Mods http://pastebin.com/rh5R3kA6

Deploy Script example http://pastebin.com/ywWtqN1L

Seek Script Routine http://pastebin.com/t7jx94k9

Most of what you need to know is in comments in the seek.ks script.

- There was an error on line 21 in the seek code. Just comment it out or delete the line if you have that version

it was added at one point for debugging and has been driving me crazy until I just noticed it now.

Edited January 3, 2015 by Dr_Goddard

[erendrake]

The KSP 0.90 compatibility release.

(The full thematic following of KSP 0.90's new way of

thinking will come in a future version. This is just

to make sure everything works.)

On Github

On KerbalStuff

On Curseforge

[h=3]BREAKING CHANGES[/h]

• Now respects the limitations of 0.90 career mode upgrades, which may make a few features not work anymore in career mode until you get further progressed along in your building upgrades.
  

[h=3]New Stuff[/h]

• Thanks to a new dev team contributer Johann Goetz (@theodoregoetz on github), we have a new, much better and cleaner looking documentation site
  
• Better flight input handling to detect the pilot controls and keep them isolated.
  
• "plays nice" with other autopilots a bit better, using KSP 0.90's new autopiloting hooks.
  
• New suffixes to handle directions better as mentioned in
  
  
• Separate Dry Mass, Wet Mass, and Current Mass readings for parts and for the vessel as a whole (TODO: Link here, but the public gh-pages hasn't be regenned yet so I don't know the link yet)
  
• Added new WAYPOINT object to help with locations of some contracts.
  
• Added new :POSITION and :ALTITUDEPOSITION suffixes to Geocoordinates to obtain 3D vectors of their positions in ship-raw coordinate space.
  
• ADDED muliple new ways to deal with resources.
  
  • STAGE:RESOURCES, SHIP:RESOURCES and TARGET:RESOURCES will let you get a list of the resources for the craft, the difference being that SHIP: and TARGET: includes all resources and STAGE: includes only the resoures that are for "this stage". All three of these will let you get a list of :PARTS that can contain that resource.
    
  • Part resources now gives you access to the resource's tweakable :ENABLE and :TOGGLEABLE can let you remove add a resource to the normal resource flow.
    

[h=3]Bug Fixes[/h]

• Better handling of range checking and loading the boot file when remotetech is installed (thanks to hvacengi for this contribution)
  
• Boot file overwrite fix (thanks to pakrym)
  
• (For developers) fixed compile error on UNIX platforms that was due to filename case-sensitivity differences.
  
• LOG command to the Archive now appends to the file properly instead of rewriting the entire contents each time just to tack on one line. It is now possible to read its output from outside KSP using a tool like the UNIX "tail -f" program.
  
• Better calculations of stage resource values, using SQUAD'S provided API for it instead of trying to walk the tree ourselves (which broke in 0.90).
  
• Fixed lonstanding bug with geocoordinates:TERRAINHEIGHT
  

[h=3]Small maintenence issues[/h]

• Bundling a newer version of ModuleManager
  
• Better use of the "skin" system for the app panel. Should see no obvious effect on the surface.
  

Edited January 4, 2015 by erendrake

[Xgkkp]

Has anyone had any luck with a hovering script for jet engines? I've got as far as realising that they spin up/down exponentially, and measuring the e^(-t/K) constants as K=8.38ish when increasing, and K=4.80ish when decreasing (at KSC level, at least - no idea if this is dependent on height but want to hover low anyway).

I'm just not sure how to take this response time into account in a hovering script?

[Xenro66]

Right, last time I used this, the game got updated the next few days after.. So I'm gonna jumping into this blind. I don't even know any commands for this mod at ALL This is going to be so hard to learn...

Edit: I just realised there's a reference document... I'm going to be ALL over that lol.

Edited January 4, 2015 by Xenro66

[Camacha]

Right, last time I used this, the game got updated the next few days after.. So I'm gonna jumping into this blind. I don't even know any commands for this mod at ALL This is going to be so hard to learn...

I am not going to say it is easy, but I am going to say it is not that hard. With just a few basic commands you can do some pretty cool stuff, and every command after that is just expanding the possibilities. Meanwhile you will learn some basic programming skills. How awesome can a game be?

Oh, and yes, you are going to get stuck on something small and simple and curse kOS, KSP and all of mankind for it, but that is just part of dealing with code and computers Do not let that discourage you, it only means you are playing for real now.

Edited January 4, 2015 by Camacha

[Rybec]

Has anyone had any luck with a hovering script for jet engines? I've got as far as realising <MATH>.

I'm just not sure how to take this response time into account in a hovering script?

With a sufficiently tuned PID controller, I don't think you need to worry about it. Let me see how mine responds to jets and get back to you.

EDIT: Yup, I was able to adapt my existing hover script to work well with jet engines just by altering the gains. If you don't know how to make a PID controller, there's a tutorial in the Kos documentation (which is pretty much all my script is, just some minor boilerplate added to let me control the setpoint with action groups, switch between radar and ASL altitudes, etc.)

You'll want your Derivative gain to be the highest to counteract the spinup times. Through experimentation I was able to find acceptable gain values in three tries. There was some minor undershooting and some overshooting which could be reduced with more tweaking. Exact values, as always, will be unique to your craft and due to the nature of jet engines a little overshoot will be unavoidable, but I got mine to settle into it's setpoint after a single oscilation and it was easy to land as long as you're gentle.

Basically any time you have a value you need to control and an output to control it with, PID will solve your problems and you can ignore any other math entirely. If only making them self-tuning were straightforward...

Oh, and yes, you are going to get stuck on something small and simple and curse kOS, KSP and all of mankind for it, but that is just part of dealing with code and computers Do not let that discourage you, it only means you are playing for real now.

Like the time it took me two weeks to realize that bad things happen when you define parameters and then don't pass them in.

Feature request: Optional parameters.

Edited January 4, 2015 by Rybec

[Entropius]

Thanks to a new dev team contributer Johann Goetz (@theodoregoetz on github), we have a new, much better and cleaner looking documentation site

Oh, that's nice. Good job.

[Dunbaratu]

Just to let people know: Several of the links in the release announcement lead to either 404 not found pages, or to pages that are out of date by just a day or two before the release and fail to mention the new feature being talked about.

This will be fixed, probably Sunday. The documentation source file changes are written, but the pages hosted on the site weren't regenerated from the source yet when the announcement was made.

[Camacha]

Basically any time you have a value you need to control and an output to control it with, PID will solve your problems and you can ignore any other math entirely. If only making them self-tuning were straightforward...

PID can be... temperamental with sluggish feedback like that. The beauty is that it does not have to know anything about the technicalities of the system it is controlling. The downside is that it does not know anything about the technicalities of the system it is controlling It will happily drive your craft into the ground, PID does not care. The peculiarities of tuning do not make that any better, as the popular rule-of-thumb-methods generally tend to result in somewhat nervously tuned systems.

It is a great tool to have though, building full models of everything you are trying to do is really not something you want to do. People not familiar with PID should also note that you generally do not need all three terms, often a PI or PD controller can be as good or even better. It certainly makes for easier tuning

[Dr_Goddard]

Nice job on the DOCS site, very professional.

- - - Updated - - -

15.5 and 15.5-2 versions seem to have broken my kOS IR integration script.

list:GETMODULE() returns an error saying ...get suffix 'GETMODULE' not found on object list...

I'll attach a screenshot of the error.

- - - Updated - - -

Here's the log file.

http://pastebin.com/yUbBgCMu

[Dunbaratu]

Here's the log file.

http://pastebin.com/yUbBgCMu

I was trying to diagnose this by eyeball and I suspect there's a mismatch between the code you posted upthread for seek.ks and what you were actually running here. My reason for suspecting that is that the posted error implies extgroup1 is a list of only 1 item, but in the code I saw posted it would have to have 6 items in it or else it would have had to throw an exception earlier when trying to do all the extgoup1:add(blah) lines.

Are you saying this worked prior to v0.15.5 ? Like on v0.15.4 ? Because this looks like a parser error but.... NOTHING between v0.15.4 and v0.15.5 had anything to do with the parser... that's weird.

As a test, can you break up the expression into more than statement, like so:

FOR L IN extgroup1 {
  SET theMod TO L:GETMODULE("MUMECHTOGGLE").
  EXTMODS1:ADD( theMod ).
}.

I'm trying to diagnose whether it has something to do with parsing the complex expression with it all embedded together in one statement. But like I said, I'm baffled by the idea that this is somehow a new problem that just showed up because of the 0.15.5 update, given that 0.15.4 and 0.15.4 had zero parsing changes. In fact I think the last parser change was back between 0.15.1 and 0.15.2.

[Dr_Goddard]

Here's what happened in sequence.

code was working on 15.4

code broke on 15.5 with an error "cannot index..."

SET FLext TO SHIP:PARTSTAGGED("FL Extendatron")[0].

^

so I thought, there is only one instance of the "FL Extendatron" and maybe it doesn't need to know the list is just one item.

resulted in line:

SET FLext TO SHIP:PARTSTAGGED("FL Extendatron").

Which produces the error I posted, so I think you are correct.

Now the problem is why won't it process this line?

SET FLext TO SHIP:PARTSTAGGED("FL Extendatron")[0].

I'll put the code back and get a new log file with the previous error.

- - - Updated - - -

Oh krap. I re-installed kOS and pulled up a backup script and everything works now.

Herp-derp.

Thanks.

[Dunbaratu]

The missing doc changes are now present, namely these:

new methods for making Direction rotations

A means of accessing waypoint information for locations that pop up in contracts

New :POSITION and :ALTITUDEPOSITION suffixes of a LATLNG (geocoordinates) allow you to convert the latitude/longitude of a location into XYZ 3-D space positions of that location.

Note, the intended way of getting the 3-D data about a waypoint is to first get the Waypoint's :GEOPOSITION suffix, which is a GeoCoordiantes structure, and then use the GeoCoordiantes' :POSITION or :ALTITUDEPOSITION suffix on that to get the 3D position.

Example:

    // You were given a contract for temperature surveys from the surface
    // at "Herman's Lookout Beta", whatever the heck THAT is.  So you 
    // run code like this to get its 3D position:
    SET wpName to "Herman's Lookout Beta". // Or whatever it was called in your game
    SET wp TO WAYPOINT(wpName).
    LOCK contractPos TO wp:GEOPOSITION:POSITION.
    // Now contractPos is always the vector pointing to the position of the surface at the contract's waypoint.
    // and it continually updates as you move and as the planet rotates.
    // Note how contractPos is a LOCK while the others are just SETs.  The waypoint is the same
    // but the 3D position can move if the planet is rotating or you are moving (the position is always
    // relative to the CPU vessel as the origin).

These were in the original 0.15.5 announcement but at the time the links to their doc pages didn't work right yet.

Edited January 5, 2015 by Steven Mading
The idiotic auto-smilies of the forum software Must Die

[Snoman314]

I realise that this is probably an incredibly stupid question, but I've spent my last two days off work googling around, trying to get kOS to pitch down 90 degrees relative to a vector. I don't know what the hell I'm doing wrong, but every variation I try gives me a brand new completely (seemingly) unpredictable outcome.

I'm trying to get the top axis of my probe oriented towards the sun, so that the solar panels will get maximum sunlight. I've been trying variations on this:

LOCK STEERING TO R(-90,0,0) * SUN:POSITION.

I've tried R(90,0,0), and R(0,90,0) etc etc. All of which give me random headings, none of which are in any way perpendicular to the vector pointing to the sun.

I've checked that SUN:POSITION returns a vector, and that R() returns a direction, and that the * operator expects a direction on the left and a vector on the right, and is supposed to rotate the vector by the given direction. Either this is buggy as hell, or the documentation has lead me massively astray.

I hope someone can give me a simple explanation, as I've only got to this point after spending a day and a half diagnosing/rediscovering a long standing known bug around the LOCK STEERING not disengaging when the kOS modules shuts down, that was screwing things up even more. Hence why my frustration may be coming across in this post. Thanks in advance.

Edited January 5, 2015 by Snoman314
Same as Steven Mading

[Camacha]

I hope someone can give me a simple explanation, as I've only got to this point after spending a day and a half diagnosing/rediscovering a long standing known bug around the LOCK STEERING not disengaging when the kOS modules shuts down, that was screwing things up even more. Hence why my frustration may be coming across in this post. Thanks in advance.

Rotations are a bit messed up in KSP, as it uses the internal frame of reference that is tricky to understand. However, as Steven posted in the previous post, there are some new features that help you deal with this kind of stuff which you can find here

[Snoman314]

Rotations are a bit messed up in KSP, as it uses the internal frame of reference that is tricky to understand. However, as Steven posted in the previous post, there are some new features that help you deal with this kind of stuff which you can find here

Yeah... I've read that page about 5 times now. It has lead me to this point.

Edit: I should clarify. I can see that there are some other functions I could try, and I can see other ways of doing this, but why the F*** Doesn't it work like it's supposed to in the first place? I create a rotation vector (slash direction) that's supposed to rotate another vector by 90 degrees. And then it doesn't. ...?

Edited January 5, 2015 by Snoman314
Lol. Apparently certain acronyms are also blocked. ...?

[Camacha]

For as far as I can tell you are trying to do something with a rotation and a vector and that means getting messed up by the rotational system. I think you are expecting something that it is just not going to do. Look at the new ANGLEAXIS command instead, which is designed to deal with things properly. You also might want to take a look at Steven's video about this stuff. If I remember correctly your question is answered almost literally, in this case with the Mun.

Edited January 5, 2015 by Camacha