[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Dunbaratu]

Multiple windows is going to be fun:).

On the subject of identifying parts without writing a MM module to every part could this work;

Create a surface attachable part (preferably small and discreet) call it a KOM port:rolleyes:,

It can then identify the part it is attached to and right clicking on it brings up a text box that lets you input a variable name for that part?

Would also have the added "advantage" of making the player think in advance about what they wanted kos to have right-click access to.

That's not a bad idea. Hmm. Now I'm picturing a part that you can only use in the VAB, that doesn't stay attached, that looks like this:

[erendrake]

That's not a bad idea. Hmm. Now I'm picturing a part that you can only use in the VAB, that doesn't stay attached, that looks like this:

Genius!

What if we let you query the list of parts that are in any action group, add support for AGX and call it a day!?!?!?

[Dunbaratu]

Genius!

What if we let you query the list of parts that are in any action group, add support for AGX and call it a day!?!?!?

I like all these ideas, but not the "call it a day" part. They're alternate types of query to perform, but at the core of the entire system I'd still really like to see a WHERE clause for making sublists of larger lists be the low level engine underneath everything else.

LIST PARTS IN MYLIST WHERE some clause here

Where "some clause here" is any expression with a placeholder variable 'val' that does the work:

WHERE val:Name = "some label I gave the parts".

WHERE val:ACTIONGROUP = "action group I'm querying for".

// More complex example: find all the engines that are mounted upside down

// relative to the main root part:

LIST PARTS in allParts.

SET rootPart = allParts[0].

SET upsideDownEngines TO allParts WHERE val:TYPE = "engine" and VANG(val:ORIENTATION:VECTOR, firstCore:ORTIENTATION:VECTOR) > 170.

Basically regardless of how people identify "this is a part I'm interested in", whether it's with a label maker, or an action group, or something else, we'll need some sort of syntax in kerboscript to specify that such a filtering condition is being applied to the parts. And I figure it probably takes no more effort to make it generically apply to all lists (whether they're parts or something else) than it does to make it apply to just parts - so it may as well be done generically on all lists.

At least that's how I see it. You may have a different vision.

At any rate, I see the problem of "how to identify if this one part is the one I want" and the problem of "how to query all parts for the one(s) I want" as being solvable completely independently of each other.

I.e. in one update we might put out the label maker idea and add a suffix "LABEL" to all Parts. That alone would allow people to perform the part query manually anyway in a for loop.

Then in a later update, add the where clause idea to make the for loop into just one line of code.

[TDW]

Just thought of a (possible) issue with the label maker. Is it possible to override whether or not a part can have surface attachments for the label maker? If not it may be tricky to label some science parts, parachutes, radial engines, rcs etc.

Edit: I think editor extensions lets you toggle it on and off without using module manager.

[Camacha]

Although I understand the need and usefulness of a label maker, I worry that it makes fully using kOS a little contrived. I look at other mods that require specific combinations or procedures to follow and it always seems to complicate things and confuse people. These kinds of things tend to feel like a stopgap solution, rather than a properly designed one.

Don't get me wrong, I am aware that I do not bring a better solution to the table.

[erendrake]

I like all these ideas, but not the "call it a day" part.

Unfortunate turn of phrase. I still want to do the List query syntax as well.

[midnitemax]

Can I access the total delta-v or ISP of my ship anywhere?

[Entropius]

Can I access the total delta-v or ISP of my ship anywhere?

I'm not sure about the ∆v, but you can get your engines as a list, and loop through them to get ISPs. If all the engines are the same, your average-ISP is the same as an individual engine's ISP, but for engines that are different, you need to calculate that yourself. To see how to calculate your average ISP on paper, see this tutorial. For a kOS example of how to calculate average-ISP among different engines, try this:

set sum to 0.
LIST ENGINES in MyEngines.
for engine in MyEngines {
    if engine:ISP > 0 {
        set sum to sum + (engine:MAXTHRUST / engine:ISP).
    }
}
set ispavg to ( SHIP:MAXTHRUST / sum ).

I'm not sure if this works in-atmospheres, as I only tested this in orbit, but I can confirm it seems to work there, at last sufficiently enough to accurately calculate burn-times.

[Entropius]

Don't know yet. I know it was in the last release. I MM'd a kOSProcessor into all the command pods, and when I tried to return to a vessel in orbit, there was nothing else there. No parachute, no US science layer, no propulsion... Just a lonesome Mk-1 pod spinning slowly in orbit. It was supposed to be a "rescue" mission to get Jeb, who I had stranded in a polar orbit around Minmus by not properly managing my dV.

The last version of kOS that I know tolerated using MM to add kOS Processors to command modules was kOS 0.11. After kOS 0.12, that hasn't been an option. Parts of ships go missing, and bad things happen.

[midnitemax]

I'm not sure if this works in-atmospheres, as I only tested this in orbit, but I can confirm it seems to work there, at last sufficiently enough to accurately calculate burn-times.

Thanks, that should work. Up until now we used

declare parameter isp.

and basically just told the program what the Isp is which also worked fine for calculating burn time, but of course it's a lot more elegant to let the program figure it out :-)

[erendrake]

Thanks, that should work. Up until now we used

declare parameter isp.

and basically just told the program what the Isp is which also worked fine for calculating burn time, but of course it's a lot more elegant to let the program figure it out :-)

We have actually talked about this quite a bit and i am torn on this. Figuring out the data and including it as a constant as a little more of a real world feel to it. You being the designer derives the isp and inputs it before launch.

getting the data from kOS does have the benefit of being more reusable

[Entropius]

Thanks, that should work. Up until now we used

declare parameter isp.

and basically just told the program what the Isp is which also worked fine for calculating burn time, but of course it's a lot more elegant to let the program figure it out :-)

Oh, so you were doing a burn-time script. Well just in case you want a bit more to help toward that end, I have a script I use for automating all my maneuver-node burns: http://pastebin.com/8HhaHYfg

I've actually made some recent adjustments that would make it take thrust-limiters into account, but I haven't had a chance to test if that feature actually works yet, so I'm holding on to that version for now.

[Entropius]

We have actually talked about this quite a bit and i am torn on this. Figuring out the data and including it as a constant as a little more of a real world feel to it. You being the designer derives the isp and inputs it before launch.

getting the data from kOS does have the benefit of being more reusable

I can see both sides of this issue. While I'd like the convenience of kOS figuring out average ISP automatically, implementing it on one's own really isn't THAT many lines of code. And it typically doesn't need to be done more than once per script. Once I get my version to accommodate thrust-limiters, I think the code is going to be pretty darn reusable.

Also, it's worth noting some mods have funky engines, like the DT Vista Fusion engine in Interstellar, which has variable ISP depending on the throttle. A built-in SHIP:ISP property could lead to misplaced trust in bad values in those weird situations.

[midnitemax]

Oh, so you were doing a burn-time script. Well just in case you want a bit more to help toward that end, I have a script I use for automating all my maneuver-node burns: http://pastebin.com/8HhaHYfg

I've actually made some recent adjustments that would make it take thrust-limiters into account, but I haven't had a chance to test if that feature actually works yet, so I'm holding on to that version for now.

We've actually (after hours and hours of coding and actually not that many lines of code in the end) managed to make a automated launch and orbit script. Since both of us are fans of physics rather than pros there was a lot of trial and error involved (my favorite error: for mu (Standard gravitational parameter) instead of G*M we used g*r and even though this is complete nonsense the calculated burn time wasn't that far off :-) ). Not for the actual paramteres but for the calculations needed for the parameters, so for the most part the script is independent of the ship (for now staging occurs whenever 720 liquid fuel is used up). I actually think it's a quite nice piece of work, especially because it doesn't use maneuver nodes at all but rather it calculates delta-v at apoapsis needed for circularization, then burn time and then starts burning at burn time/2 before apoapsis. It also includes a thrust limiter (based on the TWR (or rahter the TMR, because I couldn't find the TWR :-) )) for the initial ascent limiting the velocity to 95% terminal velocity and a gravity turn based on a somewhat swashbuckling (what a nice word ) calculation BUT it works quite nice.

I'm at work right now, so I can't post the code (also it's not yet completely done, like I said, the staging needs to be modified and I worked on the gravity burn until 2 am last night so I did not yet implement the Isp calculation) but here's a screenshot of an achieved orbit (you can tell the script what you want your orbit to be, 100000m was the input in this case, it tends to overshoot because it stops bruning at apoapsis > input): https://www.dropbox.com/s/dpqfu69v29n1jg1/Screen%20Shot%202014-09-16%20at%201.59.45%20AM.png?dl=0

Note the burn time for orbital Insertion burn is shown in the terminal. This was the only burn and it was 100% throttle to up + r(0,-90,180). This was not my "cheapest" attempt, it took 4489m/s^2 to get into orbit. My best attempt so far was 4485m/s^2 (I'm not sure if I calculated that correctly: delta v in vacuum before launch - delta v in vacuum after orbital Insertion. Makes sense, right?). Also I'm not sure if the way the gravity turn is calculated works as good for other ships or higher (or lower) orbits.

One more question: we just started using kOS when my friend was visiting, now we're a couple of hundred miles apart again but still coding like crazy. Is it possible to set the archive to a dropbox-Folder? That would be great for sharing. EDIT: we found a way: http://www.dropboxwiki.com/tips-and-tricks/sync-other-folders just sync the Archive Folder with your dropbox using a third Party tool.

Edited September 16, 2014 by midnitemax

[midnitemax]

We have actually talked about this quite a bit and i am torn on this. Figuring out the data and including it as a constant as a little more of a real world feel to it. You being the designer derives the isp and inputs it before launch.

getting the data from kOS does have the benefit of being more reusable

I just love the fact, that I can actually code a script for launching any ship into orbit with this mod. I can see the real world feel but by calculating the Isp based on every engines single Isp feels real enough to me. After all the engine could comunicate it's own Isp with the ships Computer but the Computer can't calculate it on it's own and I have to write a script for that

What I'm trying to say is: I love this mod!!

(sorry if I capitalize words every once in a while, it's the German auto correct on my Computer at work and sometimes it just doesn't let me undo an auto correct. Also, if I have some spelling Errors, it's because it's telling me almost every word I write in English is wrong and I basically have red squiggly lines under all words. I also can't change this, because I'm forced to use some old version of IE, that totally sucks and if there is an Option to turn off auto correct I simply can't find it )

Edited September 16, 2014 by midnitemax

[erbmur]

I have had a look around but don't seem to be able to find anything so I was just wondering, is it possible to get KOS to take control of the RCS thrusters only? Leaving control of the throttle to me?

[madlemur]

I have had a look around but don't seem to be able to find anything so I was just wondering, is it possible to get KOS to take control of the RCS thrusters only? Leaving control of the throttle to me?

IIRC, RCS control is on the TODO list. So not quite yet. Right now, the only thing you can do is turn the stock RCS on or off.

[erendrake]

I have had a look around but don't seem to be able to find anything so I was just wondering, is it possible to get KOS to take control of the RCS thrusters only? Leaving control of the throttle to me?

I believe our recent change would let you do this. if you simply dont set the throttle in code or set it to 0. i believe it wont take control

IIRC, RCS control is on the TODO list. So not quite yet. Right now, the only thing you can do is turn the stock RCS on or off.

We have a pretty solid RCS control api, here are the docs.

http://ksp-kos.github.io/KOS_DOC/structure/control/index.html

http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/index.html

[Dunbaratu]

One more question: we just started using kOS when my friend was visiting, now we're a couple of hundred miles apart again but still coding like crazy. Is it possible to set the archive to a dropbox-Folder? That would be great for sharing. EDIT: we found a way: http://www.dropboxwiki.com/tips-and-tricks/sync-other-folders just sync the Archive Folder with your dropbox using a third Party tool.

How about if kOS just allowed you to choose your own archive folder as a setting property in config.xml? Choose any full path string you feel like, like "\users\myname\myscripts\" or "/home/myname/myscripts" for the unixy users, and make kOS just treat that as your archive location? Then you can put your dropbox folder wherever you feel like in your directory structure and just give kOS the full path to it.

[erendrake]

How about if kOS just allowed you to choose your own archive folder as a setting property in config.xml?

We discussed this in IRC a few days ago and rule 4a reared its head.

http://forum.kerbalspaceprogram.com/threads/87842-Add-on-Posting-Rules-Aug-21st-2014

In this circumstance i think it is a minor breach as the user would specify the location. That being said we should ask before we break it.

Edited September 16, 2014 by erendrake

[erbmur]

We have a pretty solid RCS control api, here are the docs.

http://ksp-kos.github.io/KOS_DOC/structure/control/index.html

http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/index.html

Legend! Exactly what I was looking for! Now I can have RCS keep me in the same spot during landings!

[midnitemax]

In this circumstance i think it is a minor breach as the user would specify the location. That being said we should ask before we break it.

Or just advise users to use our solution. It works exactly as it should (except if you have another shared folder called archive in your dropbox that you delete or rename but not unshare, then you might end up with an archive full of pictures :-) ).

[madlemur]

We have a pretty solid RCS control api, here are the docs.

http://ksp-kos.github.io/KOS_DOC/structure/control/index.html

http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/index.html

D'oh!

[midnitemax]

So, here's the current version of my launch and orbit script: https://www.dropbox.com/s/jmisjtukd62y3le/testr.txt?dl=0

The stuff that has been commented out is currently undergoing work or isn't needed. The apoapsis is hard coded to 100 km at the Moment due to the way the gravity turn works right now. With the thrust limiter and gravity turn based on the TWR (or rather the mass to thrust Ratio at Launch) the Delta v for getting into Orbit should be around 4500 for any ship.

I'd love to hear some comments on it

[Fell-x27]

Is there methods for access to part's properties\switchers? E.g. acces to max thrust of some engine, or toggle some ledder. But not via action groups. Or can i use more than 10 action groups? Action Groups Extended mod provide up to 50 Ags! Also, if you want to make something awesome with infernal robotics, 10ags is'nt enough