[1.3] kOS Scriptable Autopilot System v1.1.3.0

[kaesekuchen]

hi,

try node (time:seconds+30,0,0,400) instead.

[togfox]

Can I just state here, because its not stated in the wiki, the readme or anywhere you'd expect, instructions for loading a script from 'disk'?

Create a text file with a .txt extension into Kerbal Space Program\Plugins\PluginData\Archive so that you have a file here:

Kerbal Space Program\Plugins\PluginData\Archive\vtol.txt

Create that folder path if you need to.

Open the terminal window in KSP (start a mission) and type this to run your script:

copy vtol from archive.
run vtol.

Credits to reddit and thought it should exist here somewhere for assistance/reference.

[erendrake]

Can I just state here, because its not stated in the wiki, the readme or anywhere you'd expect, instructions for loading a script from 'disk'?

For the upcoming v0.11 almost all of the work remaining is in documentation. If anyone wants to help with this I would be eager to accept pull requests or links to Tutorial videos people make.

[kaesekuchen]

I've got a quick question regarding the available suffixes in an orbit object.

I was wondering, if at this time it's already possible to access the Vector3d returning functions, for example

Vector3d getRelativePositionAtT(double T)

(Referencing from here : http://wiki.kerbalspaceprogram.com/wiki/API:Orbit)

If i overlooked this functionality shame on me and disregard this, otherwise consider it as a possible feature request

thanks for the info!

[odricar]

hi,

try node (time:seconds+30,0,0,400) instead.

! this worked ty!

[erendrake]

I've got a quick question regarding the available suffixes in an orbit object.

I was wondering, if at this time it's already possible to access the Vector3d returning functions, for example

Vector3d getRelativePositionAtT(double T)

(Referencing from here : http://wiki.kerbalspaceprogram.com/wiki/API:Orbit)

If i overlooked this functionality shame on me and disregard this, otherwise consider it as a possible feature request

thanks for the info!

I have no issue with exposing that method to kOS scripters but its going to take some work.

We have a bit of a grammar problem right now with kOS. Currently there is no Command for passing parameters to a preexisting structure and also get a value back. We can get values, and set values. Just not at the same time.

If you want to have this method available, feel free to add it to the GitHub backlog, there isnt a lot there other than addon integration.

[odricar]

Another quick question~ (Gee who let this guy in..)

is there a way to get the periapsis/apoapsis/eta of an encounter? all the data I can see to get from that variable is the name of the body it's encountering. or maybe there a different way of getting that info from the node command?

ty~

[Dunbaratu]

Has work been done getting rid of the old problem of deleting vessel parts when going on/off rails while a program is running? I had been working on a missile platform in space ages ago but put it aside because that problem made it untenable. (The idea was to use it as a means of playing with multiple computers on a vessel sending information back and forth to each other (i.e. the platform sends parameters to the missile's computer to tell it which thing to target and then fires it), but the design required that the missile platform's computer still be running active code up to the point where it got 2.5 km away from the missile, and that meant when I switched back it it it was half deleted.)

[Agathorn]

Doesn't KSP physically unload a craft that is that far away? Not sure how kOS would keep running, though I admit i'm learning this as I go, so i'm not that familiar with the KSP API or its capabilities yet.

I was going to try using the Never Unload mod or whatever it is called.

[weissel]

In a real world computer [...]

That's exactly the problem. Computers in the Kerbol system work in a different way from the ones in the mystical "Sol system". Just like, say, thrust is said to vary and fuel flow to be constant in an atmosphere in the "Sol system". People there aren't green most of the time. Their planet is very very lightweight, but much larger than our own Kerbin.

the computer has to be manufactured with a fixed number of CPUs and software running on it can't arbitrarily manufacture more of them on the fly.

Nobody is stopping you from renting a computing service where you can add and remove CPUs from your system on the fly --- you can simply have the program on that service change the number of CPUs (and RAM, and storage and cost) from a list of options as you need it. (I happen to have written code to do exactly that).

Nobody is stopping you from building a cluster of several units --- about any larger "webserver" is built that way, never mind popular email systems or search engines. Nobody is stopping you from ordering more such units from a cloud computing service and telling the units to boot from an image that makes them part of your cluster. People have been doing that for years.

It also can't execute any arbitrary expression in fixed time. You cannot execute an expression consisting of 10 math operators and one consisting of 2 math operators in the same fixed time as each other.

The counterexample is trivial --- just add NOPs. Or an interrupt starting a superloop and programs that yield after executing a single whole expression --- as long as the interrupt timing is slow enough ...

These differences make trying to use terminology humans developed for real world computers break when you try to apply them to kOS. The differences are large enough to warrant using new terms for them.

If you say so, feel free to come up with a few new terms. Personally, "thread", "multithreading" and "massive parallel" just work fine: they describe what would have the same effect on a theoretical machine on Earth, so we can reason about them. People have been reasoning about machines with unlimited storage and an infinitely long tape to understand 'real world computers' (Turing machine!)

And to get this on topic about the kOS mod, I suspect this is part of why kOS bogs down KSP and makes it stutter. kOS is pretending that its simulated computer executes things in constant time that on the underlying computer take vastly differing amounts of time. When the next batch of 5 operations that it wants to finish in the next timeslice actually take longer than the timeslice KSP expects a mod to finish its callback hook in, KSP has to pause simulation waiting for the mod to finish. So thus the simulation's clock will claim kOS is constant time when in reality it's not. If the algorithm was changed to not always execute the same number of fixed instructions per callback and instead watch how long they're taking, and stop when it's running out of time for this particular slice (thus executing a varying number of instructions per slice), that might help.

A single

until (x == rounds) { set x to x + 1.}.

cycles at ~100Hz, i.e. one round takes 0.01s in 0.10 (0.9 was 30-40% faster). With 2 "set"s it needs an additional 35-40% of time, with 3, 70-80%.

A single set statement therefore takes ~0.004s (1/250s). Computer clocks run between 2 and 4 GHz, i.e. 8-16 million cycles per 1/250s, or ~1.5-3 MILLION cycles per each operation of your "batch of 5 operations" OK, so you only offer 1% CPU to kOS, that's still 15,000-30,000 cycles. You can do LOTS with these ... and even 10% would be measurable, but not noticeable, and certainly not bogging KSP down.

I guess either kOS is spectacularly inefficient (Automated Guidance Computer runs multiple programs at the same time and completely, not just one statement a time, at 50Hz (0.02s)) or the problem is somewhere else.

[togfox]

Does anyone have a descent "throttle" control script they care to share? I have a very crude one but it is too jerky and I end up going too fast, too slow, or the throttle is bouncing around like a pogo during landing.

If anyone has one I can just 'plug in' that would save me writing a real throttle control that has far smoother control then my script can offer. Thx.

[kaesekuchen]

this is very far from perfect, but for throttle control during launch i use this "subroutine":

calculateTWR.txt

declare parameter desiredtwr.

set g to 9.81.
set t to ship:maxthrust.
set w to ship:mass.

set twr to  t / (w * g ).
//print "twr = " +twr.

set thrustLevel to desiredtwr / twr.

which currently gets called from here

launch.txt

declare parameter desiredAltitude,desiredtwr,desiredGravStart,desiredGravEnd,desiredAngle,interval.
declare thrustLevel.
declare desiredHeading.

until ship:apoapsis > desiredAltitude
{

if stage:liquidfuel = 0
{
stage.
}
run calculateTWR(desiredtwr).
run calculateHeading(desiredGravStart,desiredGravEnd,desiredAngle).
lock throttle to thrustLevel.
lock steering to desiredHeading.

if interval > 0
{
wait interval.
}

for completness:

calculateHeading.txt

declare parameter dStart,dEnd,dAngle.

if ship:altitude < dStart
{
set desiredHeading to Heading(90,90).
}

if ship:altitude > dStart AND ship:altitude < dEnd
{

set currentAltitude to ship:altitude.

set currentAltitude to currentAltitude - dStart.
set maximalAltitude to dEnd - dStart.

set currentAngle to (currentAltitude / maximalAltitude) * dAngle.



set desiredHeading to Heading(90 - currentAngle,90).
}

if ship:altitude > dEnd {
set desiredHeading to Heading(90 - dAngle,90).
}

As i said far from perfect since results are very dependent on the 5 parameters you put in, but for my test launches it resulted in a very smooth throttle control.

for example:

switch to archive.
//sets up a launch for an initial apoapsis above 100km, throttle control to always be at 1.5 TWR, grav turn starts at 7.5km and ends at 60km with a horizontal heading. recalculates course every ~2 seconds.
launch(100000,1.5,7500,60000,90,2).

hope this helps a bit

Edited February 5, 2014 by kaesekuchen
additional information

[kaesekuchen]

I have no issue with exposing that method to kOS scripters but its going to take some work.

We have a bit of a grammar problem right now with kOS. Currently there is no Command for passing parameters to a preexisting structure and also get a value back. We can get values, and set values. Just not at the same time.

If you want to have this method available, feel free to add it to the GitHub backlog, there isnt a lot there other than addon integration.

Thanks for the reply,

After posting my initial question, i realized as well that without changing/extending the language constructs, this would probably not be a simple addition.

I've got another question regarding this part of the code:

BindingsFlightStats.cs

            manager.AddGetter("ETA:APOAPSIS", cpu => cpu.Vessel.orbit.timeToAp);
            manager.AddGetter("ETA:PERIAPSIS", cpu => cpu.Vessel.orbit.timeToPe);

Is there a reason, that the orbit.timeToAp variables are bound in the BindingsFlightStats.cs and not directly in the Orbit.cs ?

when looking at the Orbit.cs GetSuffix function

               case "APOAPSIS":
                    return orbitRef.ApA;
                case "PERIAPSIS":
                    return orbitRef.PeA;
                case "BODY":
                    return orbitRef.referenceBody.name;
                case "PERIOD":
                    return orbitRef.period;

It seems that the period gets returned from the orbitReference, couldn't we have an addition here to get:

case "ETAAPOAPSIS":
return orbitRef.timeToAp;
case "ETAPERIAPSIS":
return orbitRef.timeToPe;

Maybe i've overlooked something, but since orbitRef.period is a simple double value returned, i don't see why this shouldn't be an simple addition to the GetSuffix function of Orbit.cs.

This would make these ETA values accessible in every targetVessel without it needing to be the active ship.

Before i add this to the github issues filed under enhancement requests, i wanted to check with you here first.

Thanks for looking at it

regards,

kaesekuchen

PS:

I'm not too firm in c# myself, but isn't there a way to access a field of an object by "string" ?

For example something like this:

dynamic d = new { value1 = "some", value2 = "random", value3 = "value" };
d.GetType().GetProperty("value2").GetValue(d, null);

(taken from here)

This way, we could have every field accessible in the object, without having to add it specifically to the GetSuffix function. This would lower code readability to an extent, but would shorten the required amount of code lines without having to add a GetSuffix case for every single field in an object.

Edited February 5, 2014 by kaesekuchen

[Dunbaratu]

Nobody is stopping you from renting a computing service where you can add and remove CPUs from your system on the fly --- you can simply have the program on that service change the number of CPUs (and RAM, and storage and cost) from a list of options as you need it. (I happen to have written code to do exactly that).

I wrote a long post here but there was no point. I realized it was just a repeat of what I already said that you've already decided isn't relevant, even though it is. I won't be trolled into arguing in circles like that.

Edited February 5, 2014 by Steven Mading

[Dunbaratu]

Doesn't KSP physically unload a craft that is that far away? Not sure how kOS would keep running, though I admit i'm learning this as I go, so i'm not that familiar with the KSP API or its capabilities yet.

I was going to try using the Never Unload mod or whatever it is called.

No but what kOS does do is have code that attempts to save the state of execution at the moment the craft goes on-rails, and then start it up from that exact moment and continue from where it left off when the craft comes back off-rails. But up until now that was never working right because it broke when trying to load the variable state in that well known bug. I never got as far as testing the execution continuation because the inability to keep the variable state made it irrelevant. (Yes, I know the problem could be avoided by only using small numbers and no strings, but the algorithm required remembering some strings and some big numbers so that wasn't practical.)

Edited February 5, 2014 by Steven Mading

[togfox]

Thanks Steven - I'll try to slot that into my scripts in the next few days and share the results soon after.

[Dunbaratu]

I'm looking for a brainstorming list: What sorts of mission goals for kOS do people think make sense as milestones for kOS users to try to "hit" in a missions-based career

using the mission control mod.?

One example is "make a successful hover script and run it on Kerbin". (For example, the mission goal could require remaining within a very narrow altitude tolerance window a hundred meters up from the launchpad for 1 minute.)

What I'm looking for is the sorts of mission goals that indicate important milestones in getting kosscript software to work, and (hopefully) things that would be hard to do if flown manually (like the hover example).

Other ideas I've had but I don't know if they're implementable using the Mission Control mod as-is:

- Successfully bomb an object on the ground from above.

- - (more advanced version) do it while moving horizontally at at least 50 m/s (so it's not just a straight line vertical drop and you have to calculate the arc of the shot).

- Land atop an existing base craft on the ground, merging with it using a docking ring mounted on its top.

Also, good "easier" missions for earlier in the "plot" would be good too.

[kaesekuchen]

from the top of my head:

default situations, for example:

1) customizable orbits

a) periapsis at X and apoapsis at Y.

inclination at Z.

c) periapsis/apoapsis at specific lon/lat

d) fuel efficiency requirements

...

2) rendevouz

a) achieving an intersect with a specific target.

matching inclination at specific intersect

c) maintaining specified relative velocity to the target for a certain period of time/proximity to the intersect

d) docking

3) geosynchronous orbits

a) reaching an exact geosync. orbit

constant alignment with a specified ground station

c) reaching an imperfect geosync. orbit and having automated correction burns to maintain the direct line of sight to the ground station during X orbits. (difficulty varies for example in minimum distance to geosync. orbit requested)

more experimental situation, for example look at what SpaceX is doing, which comes close to your scenario regarding docking with a ground vehicle.

a) launching, reaching specified alititude

hover at said altitude

c) land exactly on the launchpad or another specified location close to the launchpad

to expand on this:

d) launching, docking with ground vehicle close to launch site, ground vehicle driving back to the launch site and repeating the process. depending on difficulty minium repeat cycles requested and/or fuel limitations.

guess the sky is (not) the limit, when it comes to thinking up scenarios for this purpose

[erendrake]

This would make these ETA values accessible in every targetVessel without it needing to be the active ship.

There are so many of these properties that i have been mostly waiting for people to ask. If you think it could be useful, We can get it in for v0.12

This way, we could have every field accessible in the object, without having to add it specifically to the GetSuffix function. This would lower code readability to an extent, but would shorten the required amount of code lines without having to add a GetSuffix case for every single field in an object.

There are a few reasons I have for not making this change

* I am extremely leery of the Dynamic keyword. IMO it is only useful when you can't know ahead of time what properties you will have available. In this case, we can know this from the api.

* we would have to inherit the names of the fields and the class structure in the KSP api directly, many of these are unhelpful.

* when Squad changes any of these apis, I would rather it break my addon and i can fix it rather than making every scripter run into the same problem, get frustrated and have to search on the forums.

* Im guessing it would break almost 100% of scripts written in kOS

[erendrake]

guess the sky is (not) the limit, when it comes to thinking up scenarios for this purpose

ever since i saw the old buran concepts i have wanted KOS to be able to accomplish this mission profile.

https://plus.google.com/104283767066622569016/posts/62Si9EEy6gg

[kaesekuchen]

Hi,

point taken, regarding the dynamic keyword. Guess it's better to have the "chain of failure" to start when the plugin won't compile than it happening during runtime

When i asked about making those values available via GetSuffix, i was under the impression, that otherwise it wouldn't be possible to achieve things like rendevouz with other vessels in space.

But i proved myself wrong, since i just finished a script that just takes a vessel object as parameter on the launchpad and puts the launching ship about 15meter from the target vessel with a relative Velocity of 0m/s.

There is a lot of warping and semi-efficient guesswork involved, but it works

But still, having information like ETA to apoapsis of any targetable vessel available would be a nice feature.

On the aspect of actually docking via kOS, we probably need the functionality to have docking ports as targets and the ability to set the "Control From Here" option via script.

Though, i haven't looked closer at the API what extensions would be necessary to achieve that functionality.

At the current state, it's a lot of fun and outside the box thinking, to see what one can achieve with the given functionality

regards

kaesekuchen

[Camacha]

Does anyone have a descent "throttle" control script they care to share? I have a very crude one but it is too jerky and I end up going too fast, too slow, or the throttle is bouncing around like a pogo during landing.

What do you want exactly? I have been working on a suicide burn script that seems to be working pretty well below 1000 meter. Above that the variance is big enough to leave room for smacking into the ground in some cases, although it will usually work. The same causes it to be more accurate in vacuum than in atmosphere.

I wrote a long post here but there was no point. I realized it was just a repeat of what I already said that you've already decided isn't relevant, even though it is. I won't be trolled into arguing in circles like that.

Could we please keep these kinds of discussions out of this topic? There have been enough of those in the other thread.

[Dunbaratu]

On the aspect of actually docking via kOS, we probably need the functionality to have docking ports as targets and the ability to set the "Control From Here" option via script.

Though, i haven't looked closer at the API what extensions would be necessary to achieve that functionality.

Has lateral RCS control (i.e. the HNIJKL keys) been added to kOS yet? That's probably also needed. Without that it is *technically* possible to accomplish translations by giving the craft a very low TWR (technically TMR) main engine and having the craft spin to point in the direction of the desired translation and give a very small bit of throttle, but this is a bit of a pain and also probably requires a craft with overpowered torque so it can spin abusrdly quickly. (i.e. "I'm about half a meter off to the right, aim left, thrust at 0.001 for 0.1 seconds, spin 180 degrees and thrust again to stop, then spin back to face the docking port again and drift in.")

I'm holding off on trying to implement docking until there's some sort of HNJLKL equivalent, but I must admit that the temptation to try doing it the way I described above has been eating away at me. I just don't want to bother if it turns out that it becomes moot by the time I implement it because translation gets implemented.

[erendrake]

On the aspect of actually docking via kOS, we probably need the functionality to have docking ports as targets and the ability to set the "Control From Here" option via script.

Though, i haven't looked closer at the API what extensions would be necessary to achieve that functionality.

At the current state, it's a lot of fun and outside the box thinking, to see what one can achieve with the given functionality

regards

kaesekuchen

Ill bet that you could achieve docking if both ports where near the center of mass and you were careful with your alignment script. However, I dont want people designing their crafts around the capabilities of kOS, where possible.

Now that we have Lists and the LIST IN command it opens up the possibility for "control from here" part lists as well as a list of docking ports on the current vessel along with their status. I think we might need something better thought out to let you do the current vessel easily while also allowing for any target vessel to have the same access.

Feel free to add issues to the tracker on github, Ill get them into a milestone and we will keep plugging away, we are currently feature locked trying to get v0.11 documentation and bug fixes done.

[Luis]

Could you possibly add a keyboard shortcut to open and close the KOS terminal window? I would like to be able to send KOS commands as keyboard macros, but the KOS window traps all keypresses while it is open, so I need to manually click the close button before the keyboard can control anything else. Ideally, I'd like separate keybinds for opening and closing the window, but I'd settle for a toggle. Thanks!

Could you settle for the action group bindings we have now?

I think Luis's point is that once the Terminal window is open, you can't close it with a hotkey since all keys are trapped by the terminal. Though you could probably get around it due to the DEL bug

Yes, that's exactly the problem. I've had a look in the source and it seems as if this could be done by adding an extra check in the private void keydown() function of TermWindow.cs:

if (code == (KeyCode.X) && control && shift)

{ Toggle();

return; }

If I'm reading it right, this ought to toggle the terminal window open and shut when you hit CTRL + SHIFT + X. I'm loathe to add this in myself because I don't know my way around GitHub and I'm not sure how to extract all the files and test the change, nor how to create a new branch or whatever. If you were able to add this feature to the main branch, I would be super, super grateful.