Jump to content

kOS Scriptable Autopilot System 0.9


KevinLaity

Recommended Posts

Yes, all user-defined variables are global unless declared with DECLARE. Rebooting a kOS module does not clear locks or global variables.

I've seen that DECLARE PARAMETER makes things local, but I didn't think DECLARE (not parameter) did.

Link to comment
Share on other sites

I've seen that DECLARE PARAMETER makes things local, but I didn't think DECLARE (not parameter) did.

That's weird. I am currently using a declared parameter to set height in one of my scripts, but it get used and modified in another script. Only in the very end the original script uses it, but that is after everything has been run.

Link to comment
Share on other sites

So I found this. Am I right to assume that all scripts executed without restarting kOS share the same set of (user-defined!) variables? This would mean that one could use files pretty much like functions with all variables being "global".

Also, lock will be useful for shortcut stuff like surface_retrograde, thank you.

This works. Although it would still be quite useful to have return values from programs instead of having to use globals for it, as return values allow you to put function calls inside expressions rather than having to do it as two different steps. Right now you have to have two different steps like so:

Run a thing.

Use the result in an expression.

But with return values you could do things like this:

set x to (run prog1 + run prog2) / (run prog3).

Or this:

lock steering to run calculateMySteering.

Although for that last one to work right without bogging the system down to a halt, the way "run" works would have to be smartened-up to not go through the effort of re-parsing and re-loading a program file from disk each time it's run. (it would have to do something like "IF file timestamp is newer than last time I was executed THEN re-parse, else use old pre-parsed version.")

Link to comment
Share on other sites

Although for that last one to work right without bogging the system down to a halt, the way "run" works would have to be smartened-up to not go through the effort of re-parsing and re-loading a program file from disk each time it's run. (it would have to do something like "IF file timestamp is newer than last time I was executed THEN re-parse, else use old pre-parsed version.")

Maybe in addition to run have a import...as... which loads+parses a file to be used as a function?

This way we would still have the run statement load+parse (e.g. for repeated testing) and could propably get a nice syntax for user-defined functions inside expressions.

Link to comment
Share on other sites

Yeah, I am back more or less. After a while away with no time to play I try to catch up.

My next step is, when I am not accidentally logging out of github... cause I lost my password and my saved emails are not working..., to look up the source code again and update the wiki (which is completely outdated right now).

Well some jester changed the text of the wiki starting page to 123 apple ... what people do when they are bored...

Anyway since I still haven't much time it takes some time to read through the old posts. So this text might be some days old before I post it.

What I really hate is that you have to know your math if you want to program something for a spacecraft.

Man I hadn't to deal with any harder than the rule of proportion since I left school (decades ago).

[snip]

Your post made into http://kos.wikia.com/wiki/FAQ. Congrats!

If you get the common ship-comes-off-rails-and-half-of-it-is-gone bug and want to rescue your save file and still be able to use the broken vessel, there is a workaround you can do that will ressurrect it and bring it back alive fully formed without having to revert to an earlier save to do it.

FIRST: If you get the bug and see the ship half missing, do NOT ALLOW KSP to write to the persistence file. It will write out its broken idea of what's in the vessel and then it's stuck that way. Instead force KSP to quit without saving to the persistence file You do this by NOT using the menus to exit. Don't quit nicely or it might save as you back out to the space center and then to the main menu. Instead do a forced hard quit externally (i.e. using the Task Manager in Windows or a "kill -9" in Linux or Mac.)

SECOND: Just get rid of the entire memory context of the vessel in the save file.\

This will have the effect of making the vessel "forget" all its variables, although it will still have all the files on its hard drive. But in so doing it will also avoid the bug that's been preventing the ship from loading properly.

Here's how: In your persistence save file there is a section for the vessel that has the KOS part on it. It will look like this:


[snip]

This means that SCS part will have forgotten all its variables in memory, but will now load properly.

Obviously, don't edit the persistence file while the game is running a campaign. Make sure you've gotten out of KSP first, as explained above.

  • I wanted to write a little program that removes that from the sfs files (both quick and persistent). Problem is I am slow it would be in in python and I haven't convert it into exe since ages. Obvious exe wont work on MAC or Linux.
    So is there someone here who can do it in java?
    It should run everywhere and would be a great help to everyone which don't like or is unable to touch the sfs files manually.
  • I also have read in the forum that saving a corrupted ship can also reverted if you use this method.
    Can someone confirm this?
    I can't say if I am time for that. (Making this post including reading everything has roughly taken 4 days in my short spare time)

Session time is mission time, or time from vehicle load. Do you mean a clock format like universal time? There does not seem to be a function that does that, but converting the seconds to a clock is not hard:

//kOS code by Camacha. Released under the BSD license. Only for non-commerial use and free of charge distribution.
[snip]
//(C) 2013.

Feel free to use the code, as long as you leave the comments in.

You sure you hold the copyright for that? Isn't this a solution (beside of the name of the variables) 1 million programmers came up with already (in other languages as well)

so its another useless mod without ability "move to nearest ship"

in multiplayer (kmp) itll be great

Not useless, only just not finished. Most people would be glad if the existing features where just bug free now.

But I agree we need arrays and we need them fast.

P.S.: kOS is currently incompatible with kmp (as long as kmp doesn't fix that)

missed "." (dot) in line 10

}.

I thought they arn't needed anymore (since 0.7 I guess)

Is anyone else getting the this problem to frequently recur like I am?

... If the terminal window was ever opened once, and a program had ever been run on the craft, even if it no longer is still running, and the craft goes "on rails" because I went to the tracking center, then ANYTHING that brings the craft back "off rails", ..., will make the entire game suddenly BOG down to a standstill, going down to about a 1 FPS frame rate, and furthermore it usually triggers the parts disappearing bug...

Can other people confirm or deny whether they get the same thing happening or is it just me?

Oh, this needs to be tested and if confirmed fixed. I have a hard time cause I barely play lately. Can I suggest to test a workaround: Shut down the power of module before leaving. This should get rid of the processor task.

Prepost edit: So it seems confirmed. And also it might that my workaround idea might not work. (since it is a variable which causes that)

Umm. It seems sometimes a flush() could be useful (which empties out all variables)

Anyway I added it to the wiki.

That would be a good idea except that you can't read radar altitude above about 10,000 m or so. so you can't do it on a world with atmosphere. You'd just get captured on the first pass for being too low.

What really good would be something like isa mapsat ... or SCANsat does.

An integration of those mods would solve everything. You could get height data from a previous flight over as well as collecting height data on way down (since it captures an area which is as bigger as higher you are).

PrePost edit: I just requested it in SCANsat.

Liking this mod. Thought I would post here my K-prize qualifying run, done completely under kOS control.

It's on SkyDrive - clicky pic below to play.

[snip]

Really cool, besides that I can't see a ****. Honestly Skydrive? Youtube is too mainstream,eh?

No really the output of kOS would have been really interesting. And Youtube would have allowed HD. (skydrive, too. But I guess that it if your space is limited)

Anyway it is really cool, feel free to publish it somewhere. Our wiki maybe?

Ok done some tests.

TL/DR: variables ar global across all programs, so you can "simulate functions" with "run" command.

...

Its a bug not a feature... Kevin stated that. It will be removed in later versions, but then you have a possibility to return something.

Edit (did forget that one): Before I doing a GitHub

[request] Transmitting data should deploy antennas.

The new science system has the neat way of deploying and retracting antennas.

I think that also should be used for transmitting data ... or do we leave that it to RT2?

Edited by Bizz Keryear
Spelling ... (don't laugh since there is probably more to fix)
Link to comment
Share on other sites

You sure you hold the copyright for that? Isn't this a solution (beside of the name of the variables) 1 million programmers came up with already (in other languages as well)

Any original work is automatically protected by copyright in most countries. Whether this is original could be argued, but as it was my first integrally functional code bit I posted, I wanted to start off good and take the proper precautions. More code will follow and that will undoubtedly be more unique - even though that too it will contain a lot of common solutions. We are creating content and it is not that different from C# code or art assets.

To be honest, I think copyright would be granted in most jurisdictions, as it is written in a certain way and is long enough to have an unique fingerprint. It really does not matter that the method to convert seconds to clock time is well understood. Whether I plan to defend that copyright is another story, but at least I retain the right to do so.

The main goals of the licensing my code bits are 1) Making sure it is free and stays free (both monetarily and ideologically) 2) Preventing shady people doing shady stuff with it. 3) Being credited for my work when someone uses it somewhere. Note that anyone can use it and copy it, as long as they follow the conditions mentioned. That's all I ask. I am just being careful.

This post does not change the license conditions in any way. No rights can be derived from this post, I am simply making observations.

Edited by Camacha
Link to comment
Share on other sites

Its a bug not a feature... Kevin stated that. It will be removed in later versions, but then you have a possibility to return something.

To be honest, I do not feel it would make such a big difference. Sure, you have to pay a little attention to what variables you used, but that is not really a hard task. There are other potential features that have a lot more impact on the usage of kOS.

I"ll chime in and add that you can't claim the BSD license and limit usage. Depending on the version the requirements are to keep the copyright notice and that you can't use the authors name for advertisement(3-clause). https://en.wikipedia.org/wiki/BSD_licenses

I do not think this is the right topic for discussion about licenses, to be honest. I responded in this topic.

Link to comment
Share on other sites

Thank you baloan for your explanation. I have follow-up questions please as I am still not able to identify which formula on the Elliptic orbit page you used as basis for your velocity calculations, namely those two lines

I started with specific orbital energy 46a373000fb96a224ff6d425b2c68a59.png which is a constant. While coasting in an elliptical orbit -mu/2a is invariant but v and r change. So for current altitude r and velocity:orbit:mag v and altitude ra and velocity:orbit:mag va at apoapsis we get this equation:

velocity-at-periapsis.jpg

which gets you

set va to sqrt( vom^2 + 2*mu*(1/ra - 1/r) ). // velocity in periapsis

For the second derivation we again look at 46a373000fb96a224ff6d425b2c68a59.png. We assume mu/r is constant immediately before and after the burn. We should burn prograde in periapsis (to come close to the impulse burn assumption, otherwise you waste deltav) so that r does change as little as possible while transiting periapsis (caveat: works only for impulse burns, for ion engines and burn times long compared to the orbital period you need to come up with something else). This is why it is important to distribute the burn duration equally before and after periapsis. Then we have v^2/2+mu/2a which is equal before and after burn:

apoapsis-velocity.jpg

which gets you

set v2 to sqrt( vom^2 + (mu * (2/r2 - 2/r + 1/a - 1/a2 ) ) ).

The benefit of thinking this through are precision orbits - and fuel savings.

Edited by baloan
Link to comment
Share on other sites

After a bit of googling I've come to the conclusion that there isn't a good webpage out there that tells me the answer to this math problem:

I want to perform a transfer from my orbit to intercept another orbit. Both orbits are ellipses (obviously) but you are NOT safe to make the assumption that they are circular. Your starting orbit can be any arbitrary ellipse, and the target can be any arbitrary ellipse. The intercept has to be timed so me and the target are there at the same time.

Your problem is known as Lambert's problem. Basically it is about fitting an elliptical orbit that touches your starting point and the endpoint of your transfer AND optimize the transfer for least fuel used. When searching I found a number of tools (freely available). NASA's site has a pretty exhaustive listing of available software packages somewhere.

1. General Mission Analysis Tool (by NASA): http://gmat.gsfc.nasa.gov/

2. PyKEP (by ESA): http://sourceforge.net/projects/keptoolbox/

3. for getting ephemeris data of real planets: http://ssd.jpl.nasa.gov/?horizons (not much use in the KSP universe but tells you about the full parameter set for an orbit - the stuff for grown-ups)

The first two should actually be usable for mission planning in the KSP universe once you feed the ephemeris data for all bodies. Maybe we can create a kOS PyKEP plugin, so that Kerbin mission control can calculate transfer orbits and send them to vessels in orbit with RemoteTech...

Edited by baloan
Link to comment
Share on other sites

Your problem is known as Lambert's problem. Basically it is about fitting an elliptical orbit that touches your starting point and the endpoint of your transfer AND optimize the transfer for least fuel used. When searching I found a number of tools (freely available). NASA's site has a pretty exhaustive listing of available software packages somewhere.

1. General Mission Analysis Tool (by NASA): http://gmat.gsfc.nasa.gov/

2. PyKEP (by ESA): http://sourceforge.net/projects/keptoolbox/

3. for getting ephemeris data of real planets: http://ssd.jpl.nasa.gov/?horizons (not much use in the KSP universe but tells you about the full parameter set for an orbit - the stuff for grown-ups)

The first two should actually be usable for mission planning in the KSP universe once you feed the ephemeris data for all bodies. Maybe we can create a kOS PyKEP plugin, so that Kerbin mission control can calculate transfer orbits and send them to vessels in orbit with RemoteTech...

The brute force solution I'm settling on for the time being is to work out what the position and delta-V *would be* if both orbits were circular, by taking their semi-major axes as if those were the radii of circular orbits, and using that to arrive at a *starting guess* for the place to put a maneuver node, and then running a seeking algorithm to keep trying manuever nodes at times above and below that spot, at varying delta-V's until a "hit" is found (an encounter, no matter how poor of one). Once a "hit" is found, then I can use the encounter periapsis to fine tune it to a closer hit.

The idea is to use the Hohmann transfer as the center guess of an iterative guessing algorithm.

It's not pretty but it will work to satisfy the needs of thrfoot's challenge, to get a first interplanetary mission to work.

It occurs to me that this would be a lot faster of an algorithm if I could obtain some information about how close I am when I'm not close enough for an encounter. Right now the information is sort of boolean. You either have an encounter or you don't. If you have an encounter, you can find out how good of one it is (how small is the periapsis) but if don't have an encounter, you can't find out if you're missing by a little or by a lot. That "closest approach" data you get from KSP when you target a body does not seem to be available to a KOS script at the moment.

If it was available, then my seek algorithm could be a lot faster because it could operate based on a "that's too high/that's too low" binary search technique instead of having to iterate sequentially until a hit is found.

Link to comment
Share on other sites

I haven't been following in extreme detail, but I haven't seen a new release or any update from the author in a while. Does anyone know if kOS is still being actively worked on?

There seems to be a lot of activity from volunteers branching the code, making fixes, and then making pull requests for getting those fixes back into the main code, but none of that is making it into the main branch.

I don't know what happened. Kevin hasn't posted anything in the last month or so.

Luckily the nice thing about putting the code on github is that in a worst case scenario it would be possible for someone else to make a copy of the code and continue it as a new project from scratch if the original author cannot be reached (and the code is licensed in such a way that this would be legal). But I don't think Kevin has been absent for quite long enough to warrant that yet. It's his baby, give him a chance to retain control of it, I figure.

Link to comment
Share on other sites

There seems to be a lot of activity from volunteers branching the code, making fixes, and then making pull requests for getting those fixes back into the main code, but none of that is making it into the main branch.

I don't know what happened. Kevin hasn't posted anything in the last month or so.

Luckily the nice thing about putting the code on github is that in a worst case scenario it would be possible for someone else to make a copy of the code and continue it as a new project from scratch if the original author cannot be reached (and the code is licensed in such a way that this would be legal). But I don't think Kevin has been absent for quite long enough to warrant that yet. It's his baby, give him a chance to retain control of it, I figure.

He is absent from the Github 13 days (last update) 16 days since his last comment. He really is not one who writes that much I guess. (The reason why the doku is such a mess).

Anyway he didn't said to be absent. And I begin to worry. But maybe it is the same what has happened to me. I simply couldn't effort time for KSP.

But I try to fetch/catch him.

-----------------------

Wiki News:

Once again I walked through the source code and through every not included pull, grabbed the raw data threw them into the wiki http://kos.wikia.com/wiki/List_of_all_Commands . Until I have time to include this correctly it probably stay so.

Anyway funny that there are a lot of functions which no one ever has used (maybe cause they never heard of).

Link to comment
Share on other sites

But I don't think Kevin has been absent for quite long enough to warrant that yet.

Before his break he updated like at an incredible rate. I can imagine that this is not a desirable situation in the long run. The project stops being fun or Lifeâ„¢ interferes. I see too many mod makers burn themselves out for whatever reason and that should never happen. I feel that the community, in its enthousiasm, can sometimes add undesired pressures to something that should be fun and is done voluntarily.

I hope Kevin is okay and takes his time. If he feels like it he should run the project, instead of the project running him.

Link to comment
Share on other sites

But I don't think Kevin has been absent for quite long enough to warrant that yet. It's his baby, give him a chance to retain control of it, I figure.
I see too many mod makers burn themselves out for whatever reason and that should never happen. I feel that the community, in its enthousiasm, can sometimes add undesired pressures to something that should be fun and is done voluntarily.

I hope Kevin is okay and takes his time. If he feels like it he should run the project, instead of the project running him.

I completely understand and agree with y'all. I was just curious as to the status and wondering if I had missed something that had been posted on some other channel that explained the silence.

Link to comment
Share on other sites

Before his break he updated like at an incredible rate. I can imagine that this is not a desirable situation in the long run. The project stops being fun or Lifeâ„¢ interferes. I see too many mod makers burn themselves out for whatever reason and that should never happen. I feel that the community, in its enthousiasm, can sometimes add undesired pressures to something that should be fun and is done voluntarily.

I hope Kevin is okay and takes his time. If he feels like it he should run the project, instead of the project running him.

Agreed, I've seen a few other mods that were put on hold because of this (in part or in full). Though they eventually came back. I can imagine how frustrating it is to have people demand features and ways to fix something like you're being paid to write the programming for the mod.

Link to comment
Share on other sites

Agreed, I've seen a few other mods that were put on hold because of this (in part or in full). Though they eventually came back. I can imagine how frustrating it is to have people demand features and ways to fix something like you're being paid to write the programming for the mod.

A large part of it is whether you want a project to be owned by yourself or if you want it to be owned by a group. One thing that can help the stress is to be willing to let loose control over it and accept that others may make edits in your absence. But you do sort of lose the pride of "this is my baby" if you do that.

One concern I have is that the longer people continue to make edits that don't get rolled back into the main trunk, the more daunting the task of rolling them back in later becomes - until eventually it suffers from its own popularity - the task of picking it back up again becomes too much of a chore because there's too much to merge.

Link to comment
Share on other sites

One concern I have is that the longer people continue to make edits that don't get rolled back into the main trunk, the more daunting the task of rolling them back in later becomes - until eventually it suffers from its own popularity - the task of picking it back up again becomes too much of a chore because there's too much to merge.

I can imagine that being one of those pressures; possibly feeling pressured to choose between undesired work now or more undesired work later does not seem like a lot of fun to me. Someone always has, and should have, the freedom to say now I take 1/3/5 months off because I want to do other stuff/don't feel like it/it is not fun anymore.

In the neighbouring topic I would like Sirkut to finish kOS support for Infernal Robotics more than ever. Yet I asked once, because I feel a modmaker is responsible enough to indicate what he wants and does. Me asking every week about it is not going to make any part of the process better.

Link to comment
Share on other sites

Does anyone know how to unset a target?

If I do this:

set target to "Duna".

Then I can't figure out how to de-select Duna after that (from in the script, I mean).

set target to 0.

set target to "None".

set target to "".

None of the above work. Maybe I'm missing something really obvious.

Link to comment
Share on other sites

Does anyone know how to unset a target?

If I do this:

set target to "Duna".

Then I can't figure out how to de-select Duna after that (from in the script, I mean).

set target to 0.

set target to "None".

set target to "".

None of the above work. Maybe I'm missing something really obvious.

unset target. would be what I think should do the trick...but no clue if it does as I haven't gotten that far yet. Haven't spent any time with KSP/kOS in over a week now I guess. Though I am jones'n to get back to it lol

Link to comment
Share on other sites

Does anyone know how to unset a target?

If I do this:

set target to "Duna".

Then I can't figure out how to de-select Duna after that (from in the script, I mean).

set target to 0.

set target to "None".

set target to "".

None of the above work. Maybe I'm missing something really obvious.

Apparently UNSET was forgotten. However rejoice a1270 has done a pull request to that... Let me just quick ask if that's including nodes

edit: https://github.com/Nivekk/KOS/pull/263

Link to comment
Share on other sites

Regarding your discussion on the Github page: I have been thinking about a way of maybe automatically running a certain script on boot. Preloading, as it were. That seems a lot nicer when playing (I can not count the times I typed copy prog from 0. ... run prog.) and it is also realistic. A craft that shuts down due to an error or some other unforeseen circumstance should really try to run its software, possible extend antennas and phone home. Now, when you reboot, you are just dead in the water.

If the craft is able to phone home, it could even automatically access a script containing new programs/scripts to run. Pretty much like the real thing. I am just not really sure about how you can preload anything on startup, because that is where the repeatedly typing in your program names starts to count after a while.

It would of course be really nice if scripts could run while unloaded. I think of geostationary stationkeeping or long, long journeys. Having the craft look after itself would be ideal, as babysitting the geosync of my satellites is not my favorite hobby and warp adds to the problem quickly. That is at the same time a big hurdle. How is kOS ever going to run different ships at the same time, with physics (on rails it's hard for kOS to do anything) and without player supervision? I suspect that KSP is going to throw a royal fit.

Of course, if the workload could be properly offloaded to seperate cores the problem would be pretty much solved - unless you run many more ships. That would, however, probably mean that physics also have to be offloaded and I am not sure that is even possible.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...