kOS Scriptable Autopilot System 0.9

[Sma]

I'd rather take the approach of building a library of subroutines for people to pick and choose from rather than a single monolithic program. Now that the "Program ended" messages are going away for sub-program calls (once 0.8x gets fixed well enough to be usable) it's going to become more practical to use the "run progname(arg,arg,arg)" command as a subroutine call. It's got a lot of overhead behind doing the call, which makes it a bit slower than a native routine but for a thing like a scripting language it's about like a shell script running a lot of small programs to each do one little thing.

And while a forum thread might be an appropriate place to ask questions about such a hypothetical library of example routines, or make announcements about them, I don't think it's an appropriate place to store them for download, as only the thread starter would have the rights to edit the head post of the thread so it would end up meaning it would be a thread of scattered examples to search for. A thing like a wiki makes more sense for collaborative work on a shared library of example routines.

Agreed, about the library of subroutines instead of one program that does everything. For one, doing it that way it's basically just a MechJeb replacement. Also from a standpoint of saving space, not everything would need a landing program, or skycrane program etc, so a "one program does all" situation doesn't really work for everything. Though I guess thats really a personal choice in how you play the game.

As for codes/programs, in my opinion, for what its worth, the wiki is a much better option for this I think. Codes posted on the forum would quickly get buried by other stuff, well unless on a separate post, but at least with the wiki we have a chance of keeping it clean and organized.

Edited October 15, 2013 by Sma

[AbeS]

Does anyone else has trouble with the quickload or changing vessels? whenever I do any of those, and the vessel has the KOS part the vessel disappears!

Something else that I've noticed is that I can't lock variables to prograde or other variables like velocity, instead of locking it sets the variable to the current value, and stops updating.

An example if you couldn't understand me:

lock vel to velocity:surface.

print vel + " " + velocity:surface.

//prints 20 20

print vel + " " + velocity:surface.

//prints 20 21

print vel + " " + velocity:surface.

//prints 20 22

So I can't do stuff like lock steering to prograde without using loops.

Is it my game or is this happening to everyone? I only left my GameData folder with Squad and KOS and had the same results.

[Bizz Keryear]

Agreed, about the library of subroutines instead of one program that does everything. For one, doing it that way it's basically just a MechJeb replacement. Also from a standpoint of saving space, not everything would need a landing program, or skycrane program etc, so a "one program does all" situation doesn't really work for everything. Though I guess thats really a personal choice in how you play the game.

As for codes/programs, in my opinion, for what its worth, the wiki is a much better option for this I think. Codes posted on the forum would quickly get buried by other stuff, well unless on a separate post, but at least with the wiki we have a chance of keeping it clean and organized.

I really like to look at the code of other people, because they can come up with solution I might never thought of and I can adapt those to my own projects.

[willow]

I agree on the wiki, it's a much better place for reference, forum threads tend to get bogged up and don't have any indexing, so if you're looking for specific code you're much more likely to find it if looking on a wiki.

[Dexter9313]

There are good news for a kOS/RT compatibility ! As soons as .22 shows up, RT developers announced they would rebuild it from the ground up only with core functionalities, which are : antennas and dishes; and establishing a connection link. This means there will be no key-input blocks anymore as there will not be any flight computer or signal delay. When this version will come, I hope Kevin could do one thing : giving up his antenna principle which in my opinion makes no sense and add an RT-compatible option which would delay the command execution (or deny it if no connection is found). It seems very simple to do and it would replace his implementation of KSC connection with something serious.

See you up there !

[Dunbaratu]

There are good news for a kOS/RT compatibility ! As soons as .22 shows up, RT developers announced they would rebuild it from the ground up only with core functionalities, which are : antennas and dishes; and establishing a connection link. This means there will be no key-input blocks anymore as there will not be any flight computer or signal delay. When this version will come, I hope Kevin could do one thing : giving up his antenna principle which in my opinion makes no sense and add an RT-compatible option which would delay the command execution (or deny it if no connection is found). It seems very simple to do and it would replace his implementation of KSC connection with something serious.

See you up there !

That's a good idea provided that kOS doesn't become intertwined with RT in a way that makes RT a prerequisite for using kOS. KOS still needs to function correctly for players who don't use RemoteTech. If the answer to "why can't I access the archive away from Kerbin?" becomes "Install remotetech first" it's going to put off some who might otherwise use kOS.

Perhaps if RemoteTech is present KOS changes is behavior to use it, but if RemoteTech is not present it falls back to what it does now?

[Dexter9313]

That's a good idea provided that kOS doesn't become intertwined with RT in a way that makes RT a prerequisite for using kOS. KOS still needs to function correctly for players who don't use RemoteTech. If the answer to "why can't I access the archive away from Kerbin?" becomes "Install remotetech first" it's going to put off some who might otherwise use kOS.

Perhaps if RemoteTech is present KOS changes is behavior to use it, but if RemoteTech is not present it falls back to what it does now?

I said it could be optional. ^^ If RT is detected, then apply delay and command denial; and if RT is not detected, do as normal. Chatterer already does this, it detects the presence of RT and modifies the sounds timing consequently (and doesn't play the sounds if RT is detected and no connection to KSC is found).

[Camacha]

There are good news for a kOS/RT compatibility ! As soons as .22 shows up, RT developers announced they would rebuild it from the ground up only with core functionalities, which are : antennas and dishes; and establishing a connection link. This means there will be no key-input blocks anymore as there will not be any flight computer or signal delay. When this version will come, I hope Kevin could do one thing : giving up his antenna principle which in my opinion makes no sense and add an RT-compatible option which would delay the command execution (or deny it if no connection is found). It seems very simple to do and it would replace his implementation of KSC connection with something serious.

See you up there !

Yeah, I am pretty stoked about this. If I could use the Remote Tech line of sight and delay with stock looking dishes and the kOS scripting functionaly together I would be so happy. That really has to be an ideal combination. No need for kOS to do range requirements when something like Remote Tech does it really neatly and nicely and no need for Remote Tech to develop a flight computer when kOS is doing that job in a very comprehensive way.

There was even some talk of information maybe being relayed by orbiting probes that do not have a continuous line of sight. However, just the above would make KSP quite a different game. More realistic, a lot harder but more rewarding and entertaining.

That's a good idea provided that kOS doesn't become intertwined with RT in a way that makes RT a prerequisite for using kOS. KOS still needs to function correctly for players who don't use RemoteTech. If the answer to "why can't I access the archive away from Kerbin?" becomes "Install remotetech first" it's going to put off some who might otherwise use kOS.

I prefer two mods doing what they do best, instead of them both trying to do each other's part (with all due respect) half assed.

Edited October 17, 2013 by Camacha

[Bizz Keryear]

The antenna part in kOS is kept very simply. And it should stay that way, but it might be very simple to include a RT detection or a trigger which mods can flip and use their own antenna thing.

Actually really good news: Kevin has started to work again on kOS and fixed a few bugs already, even though he hasn't released a new version yet.

I would build my own ... if I know how.

Edited October 17, 2013 by Bizz Keryear

[Dexter9313]

The antenna part in kOS is kept very simply. And it should stay that way, but it might be very simple to include a RT detection or a trigger which mods can flip and use their own antenna thing.

Sure, that's actually better to keep both ways. As for RT, I suggested an optional flight computer would be possible. I don't mind if mods try to do what other mods do as long as it is optional.

[Dunbaratu]

That's a good idea provided that kOS doesn't become intertwined with RT in a way that makes RT a prerequisite for using kOS. KOS still needs to function correctly for players who don't use RemoteTech. If the answer to "why can't I access the archive away from Kerbin?" becomes "Install remotetech first" it's going to put off some who might otherwise use kOS.

I prefer two mods doing what they do best, instead of them both trying to do each other's part (with all due respect) half assed.

You seem to be implying that what you're saying there isn't compatible with what I said (when you said "prefer" it implies you can't have both and have to pick one or the other, but I can't figure out what it is about what you're saying that isn't exactly 100% in agreement with what I said. If you want antennae range to be a limitation, let remotetech do it instead of KOS doing it, but don't demand that all users of KOS must use remotetech. So what that would mean is that KOS code would do this:

If remotetech is present, then:

ask remotetech whether or not craft is in range.

else

always assume craft is in range, effectively making range checks irrelevant.

Rather than this this:

If remotetech is present:

then ask remotetech if craft is in range

else

sorry, out of luck, pal, you can't use KOS away from Kerbin.

[Dexter9313]

Steven, I think everyone talked about the first solution and there was a misunderstanding... ^^

[erbmur]

Just started to use this mod and must say I am really enjoying it.

I do have one question. could somebody please give me the code that I need to unluck the heading once a heading has been locked? so the spacecraft can freefall rather then trying to keep a heading?

[razark]

could somebody please give me the code that I need to unluck the heading once a heading has been locked?

"unlock steering."

Haven't tried yet, so any issues with the 0.22 update?

[Payload]

"unlock steering."

Haven't tried yet, so any issues with the 0.22 update?

So far...

Everything still works like it did with v 0.71. The only problem I have is that some the HUD elements disappear when you use it. So there is something going on with that.

I haven't tried V.84 yet since the other day. I know it wont work with my scripts as it is. It has some weird white space issues. I am really eager for the new stuff though. Those new round and floor functions where nice when I tested them.

The only outstanding issue that I know of that is a real issue is the fact that half of your space craft will get eaten by the Space Kraken if you leave it and come back to it with the com center. That was happening before .22 update so that isn't new.

[Kalista]

So far...

Everything still works like it did with v 0.71. The only problem I have is that some the HUD elements disappear when you use it. So there is something going on with that.

I haven't tried V.84 yet since the other day. I know it wont work with my scripts as it is. It has some weird white space issues. I am really eager for the new stuff though. Those new round and floor functions where nice when I tested them.

The only outstanding issue that I know of that is a real issue is the fact that half of your space craft will get eaten by the Space Kraken if you leave it and come back to it with the com center. That was happening before .22 update so that isn't new.

It will do it to if you change ships that aren't loaded from the map as well ( thats where I first noticed it then saw loading from KSC did it as well)

[Camacha]

but don't demand that all users of KOS must use remotetech.

I don't It would just be a waste to have two mods that complete each other perfectly without the option to use the best of both simultaniously. I think the current range implementation in kOS is a bit silly compared to the one in RT, and the other way around for the computer/automation part.

If you would ask me I would not bother with range finding at all in kOS, but that is just me.

[devanmedrow]

+1 for KOS using its antenna, but if RT is loaded it switches to use RT com settings. You could have 3 computer types.

1) Just get computer commands from KSP and executes them.

2) One that gets commands from KSP or can store X bytes of code and run on its own if out of contact. (X can be changed in the .CFG file)

3) A computer on the ship that runs like kerbales where aboard. (keeps running even if RT has no contact. You just cant type commands)

[erbmur]

"unlock steering."

Haven't tried yet, so any issues with the 0.22 update?

Thanks for the help!

[Dunbaratu]

Idea: with 0.22's tech tree, perhaps KOS should have several varieties of computer unit that get better as you climb the tech tree. The execution speed and disk capacity could vary depending on whether you use the primitive versions or more advanced versions of the part.

[rhoark]

If we get a way to specify speed or storage in the part.cfg, it can be strung along the existing probe core tech progression.

[PatriotBob]

If we get a way to specify speed or storage in the part.cfg, it can be strung along the existing probe core tech progression.

Also linking certain variables to sensors would be cool. Sensors could be distributed across the tree making tech progression via program complexity not just because the CPU goes faster.

[Camacha]

Also linking certain variables to sensors would be cool. Sensors could be distributed across the tree making tech progression via program complexity not just because the CPU goes faster.

That would not be program complexity, but just moar sensors

[Dunbaratu]

That would not be program complexity, but just moar sensors

Presumably what PatriotBob meant is that the programming is allowed to get more complex because it becomes capable of doing more things as it gets access to more information. A program will probably be simpler if it can't do much because there's not much information to go on.

[Camacha]

Presumably what PatriotBob meant is that the programming is allowed to get more complex because it becomes capable of doing more things as it gets access to more information. A program will probably be simpler if it can't do much because there's not much information to go on.

I understand that, but I do not feel that this would be any less artificial than basing progress on processor speed. On the contrary; computers becoming steadily faster are more natural than not having simple instruments that we have had for ages, even before computers.

With limited computer power you simply can not do what you might want to do with sensors, whichs seems pretty much spot on for me.