kOS Autopilot

[erendrake]

This is a continuation of the Excellent work by Nivekk. Without it, this mod would certainly not exist.

Goal

Make an easy to use but powerful tool for mission scripting.

Main Repository:

https://github.com/KSP-KOS/KOS/

Development Roadmap:

https://github.com/KSP-KOS/KOS/milestones

Reference Documentation:

http://ksp-kos.github.io/KOS_DOC/

Edited September 17, 2014 by erendrake
updated links to github

[Agathorn]

So I have been working on my own fork of kOS to make it more compatible with the Realism Overhaul mod and associated mods.

Currently I have incorporated RemoteTech 2 into kOS, first by merging in Cilph's RT2 API, and then integrating RT2 checks into areas of kOS that used to use raw commrange. Right now that integration is pretty much mandatory, IE if you don't use RT2 then you will not get a connection regardless of whatever antennas you do have. I'm going to make that a bit more optional though, so once I finish that then it should be suitable for the main branch.

I have also incorporated FAR connections to kOS, by modifying FAR to register external functions in kOS. These changes are not in the released version of FAR yet, but i'm talking with Ferram about that right now. At the moment I have FAR functions for grabbing the following information from FAR's flight data:

Mach

EAS

DynamicPressure

AtmDensity

RelativeAtmDensity

TerminalVelocity

OxygenIntake

VesselLift

VesselDrag

My GitHub fork of kOS can be found here: https://github.com/jwvanderbeck/KOS

I don't know if I should maintain separate threads for my Realism version of kOS, or keep them all with your main release. I prefer keeping them with yours because people may want to go one way or the other, and we can better collaborate on shared issues.

[erendrake]

I don't know if I should maintain separate threads for my Realism version of kOS, or keep them all with your main release. I prefer keeping them with yours because people may want to go one way or the other, and we can better collaborate on shared issues.

I think that with a little bit of clever design we can make these changes optional and just include them with the base mod as modules. If you keep working on getting all of the feature in. Ill assign a few tickets to you can we can tackle the integration when you are happy with the results.

One of the requests i would make of addon data is that we Prefix data from the addon with some abbrev. (eg RT: for remotetech, FAR: for FAR, KETHANE: for Kethane)

Edited February 1, 2014 by erendrake

[Agathorn]

I'm working on trying to merge your develop branch over to mine now, though so many structural changes is making it tough.

[erendrake]

I'm working on trying to merge your develop branch over to mine now, though so many structural changes is making it tough.

Yeah im sorry about that. When i decided to take over i made a lot of changes at the start to try and keep the turmoil down later. It looks like you forked before then and that merge is going to be epic

I will try and not do that again without warning everyone.

[Agathorn]

Yeah im sorry about that. When i decided to take over i made a lot of changes at the start to try and keep the turmoil down later. It looks like you forked before then and that merge is going to be epic

I will try and not do that again without warning everyone.

No worries. I agree with the changes, but yeah epic merge

[Agathorn]

I *think* I got it all merged. I'll test after lunch.

I rewrote chunks by hand, so in my latest development branch, RT2 should be integrated in such as way as to fallback to standard kOS comms if RT2 is not installed.

[Agathorn]

@erendrake

I've merged over your latest develop branch to my development branch.

Refactored the RemoteTech2 API to accommodate the kOS refactoring you had done.

I've quickly tested it both with and without RT2 and seems everything is good.

[Agathorn]

Might need to look at the steering system. I'm still going through it, trying to wrap my brain around it, but it seems to really be designed under the assumption that craft have inertia wheels, and doesn't perform well on craft that don't.

[Agathorn]

Yeah it causes severe understeering in vessels without reaction wheels, or ones with small wheels like in most of Realism Overhaul.

By forcing a minimum detected torque the system steers a LOT better.

[masTerTorch]

Thanks guys for maintaining kOS.

@Agathorn:

I compiled your RT compatible version and encountered this strange bug:

While returning to the craft the parts of vessel beneath the kOS Unit vanished.

This kind of bug I encountered before see here.

Any ideas?

[Agathorn]

Thanks guys for maintaining kOS.

@Agathorn:

I compiled your RT compatible version and encountered this strange bug:

http://i1273.photobucket.com/albums/y418/mastertorch/kos%20bugs/140202_kOS_bug_zps3f8b05e6.jpg

While returning to the craft the parts of vessel beneath the kOS Unit vanished.

This kind of bug I encountered before see here.

Any ideas?

Thanks for the report. I haven't seen that happen personally, but then I tend to play with parts that have the kOS module built in rather than using the separate part. I'll see what I can find.

[erendrake]

Just FYI there is a new pre-release version up

https://github.com/erendrake/KOS/releases/tag/v0.11.0P2

[Agathorn]

Thanks guys for maintaining kOS.

@Agathorn:

I compiled your RT compatible version and encountered this strange bug:

http://i1273.photobucket.com/albums/y418/mastertorch/kos%20bugs/140202_kOS_bug_zps3f8b05e6.jpg

While returning to the craft the parts of vessel beneath the kOS Unit vanished.

This kind of bug I encountered before see here.

Any ideas?

I just reproduced this. Not a clue what causes it at the moment

[Agathorn]

@masTerTorch: You are using RT2 correct? I think i've narrowed the problem down to what happens in the on rails code with RT2 inside kOS.

[masTerTorch]

@masTerTorch: You are using RT2 correct? I think i've narrowed the problem down to what happens in the on rails code with RT2 inside kOS.

Yeah, I am using RT2. I modified the stock probes to use kOS and get the same bug. Removing kOS from stock probes will bring back the corrupted spacecrafts. I haven´t tried kOS without RT2 yet.

[Agathorn]

Yeah, I am using RT2. I modified the stock probes to use kOS and get the same bug. Removing kOS from stock probes will bring back the corrupted spacecrafts. I haven´t tried kOS without RT2 yet.

Yeah i'm confident the issue has to do with the RT2 integration, and I think it is in the on rails code, as it only seems to happen to me if I leave a ship then come back to it.

Interestingly enough the other pieces are still there, as I reloaded a game with a non-rt version of kOS and the parts magically came back

[rhoark]

The disappearing craft has something to do with kOS borking it up when reading a local (non-archive) program from the persistence file. Parsing of the craft's persistence then truncates at that point. (Extrapolating from when such things happened before. I haven't had the time to use kOS since 0.8)

[Agathorn]

The disappearing craft has something to do with kOS borking it up when reading a local (non-archive) program from the persistence file. Parsing of the craft's persistence then truncates at that point. (Extrapolating from when such things happened before. I haven't had the time to use kOS since 0.8)

Pretty sure this is something else, as it doesn't depend on any program execution. Just need to have the part installed.

It is definitely being caused by the on-rails code, as i've managed to fix the bug by disabling it.

[Camacha]

So I have been working on my own fork of kOS to make it more compatible with the Realism Overhaul mod and associated mods.

Did you consider the number of kOS varieties and how to handle that? Are you intending to just maintain a more interoperable kOS variant of Erendrake's fork or are you independently developing your own things/commands/ideas?

I am scared that all these (wonderful) initiatives are going to muddy the waters and cause quite a bit of confusion and irritation.

[Agathorn]

Did you consider the number of kOS varieties and how to handle that? Are you intending to just maintain a more interoperable kOS variant of Erendrake's fork or are you independently developing your own things/commands/ideas?

I am scared that all these (wonderful) initiatives are going to muddy the waters and cause quite a bit of confusion and irritation.

We are doing our best to harmonize and not cause too much fragmentation. Its a bt of a learning experience for both of us I think at this point, but the intention is to keep the two in sync as much as possible, except where it just isn't possible to do so.

[erendrake]

We are doing our best to harmonize and not cause too much fragmentation. Its a bt of a learning experience for both of us I think at this point, but the intention is to keep the two in sync as much as possible, except where it just isn't possible to do so.

I am also committed to keeping one release with all of the interested parties involved in its development. Even if we end up adding modular behavior to accomplish it. it is all just clever engineering.

[Agathorn]

I have pushed some changes to my GitHub that should for the time being fix the issue with RT2 removing chunks of your spacecraft. It appears that if you allow RT2 to take over the vessel on rails autopilot, then it mucks up the ship. So for now i've disabled that feature.

https://github.com/jwvanderbeck/KOS/releases/tag/v0.11p2

[Dunbaratu]

Pretty sure this is something else, as it doesn't depend on any program execution. Just need to have the part installed.

It is definitely being caused by the on-rails code, as i've managed to fix the bug by disabling it.

It is probably a very similar effect though as this is a common problem with KSP mods in general (not just kOS). It has more to do with the behavior of how KSP runs mods than anything else. KSP is not very forgiving of having mods that error out when parsing the persistence file. Whenever a mod throws an untrapped exception when trying to parse its portion of the persistence file what KSP does to try to get its parsing algorithm "synced" up again and back to a known normal state is to jump to the end of the vessel definition (skipping past the rest of the parts on the vessel). It's sort of like how when parsing C code, most parsers will skip to the next semicolon to get synced up again if the state of the parse is too confused. (Therefore if one line of code contains two errors sometimes the second one won't get noticed until the first one is fixed.) In the case of KSP, the sync point in the parse is the ending curly brace of the vessel section.

[Agathorn]

It is probably a very similar effect though as this is a common problem with KSP mods in general (not just kOS). It has more to do with the behavior of how KSP runs mods than anything else. KSP is not very forgiving of having mods that error out when parsing the persistence file. Whenever a mod throws an untrapped exception when trying to parse its portion of the persistence file what KSP does to try to get its parsing algorithm "synced" up again and back to a known normal state is to jump to the end of the vessel definition (skipping past the rest of the parts on the vessel). It's sort of like how when parsing C code, most parsers will skip to the next semicolon to get synced up again if the state of the parse is too confused. (Therefore if one line of code contains two errors sometimes the second one won't get noticed until the first one is fixed.) In the case of KSP, the sync point in the parse is the ending curly brace of the vessel section.

Interesting. Well since it is happening when returning to a vessel it could be like that. The code errors outs, I think in RT itself, and then KSP just bails.