added some useful flight stats

[erendrake]

Many of the stats we already have access to (ie Ap, Pe) are calculated from others we didn't have (ie SMA and ECC). I added them.

Transition is interesting because it pulls the end state of the current orbit out of the simulation and as such is pretty accurate. some of the possible states are:

• FINAL //your orbit continues till the end of the simulation
• ENCOUNTER //your orbit encounters a body orbiting your current reference body
• ESCAPE //your orbit will escape the current reference body
• MANEUVER // your orbit encounters a maneuver node

Because the simulation continues for more than one orbit, I added the time to the transition in UT, this along with OBT:PEROID and our existing time tools should let you figure out how many orbits in the future the transition will take place in.

[fibonatic]

To make transferring between celestial bodies easier, you should also be able to request these values for each body. And if you would like to add these orbital elements than I would also add gravitational parameter, radius (so you do not need to add the radius at sea level to the altitude manually), true anomaly, inclination (with respect to the equatorial plane), argument of periapsis and possibly even longitude of the ascending node, however I would not be sure which reference direction you should choose, possibly the vector towards the body it is orbiting. So for the Mün this direction would rotate with it when it goes around Kerbin (makes it easier to determine when to burn to return to Kerbin). But I am not sure which direction you should choose for bodies orbiting the Sun, maybe in this case choose Kerbin, since this is the home-planet of Kerbalkind.

[erendrake]

@fibonatic Im sure you are right about the extra properties, I think that many of us are just nibbling around the edges until the main maintainer comes back and lets us know what he plans are.

[fibonatic]

@erendrake You are right, since my suggestions would affect significantly how much you would know about your (or any other) orbit. And I remember that Nivekk said that he wanted that this mod would reflect the way computers helped the early space race (around the '60s). So low computing power and simple UI. However currently it is, I think, impossible to calculate an interplanetary transfer. Maybe you would be able to find these orbital elements by observing, since I think you are always able to get your distance to a celestial body. But even if you would know these properties, it would still require lots of maths to derive how to transfer (possibly you would even have to do some numerical calculations to approximate it).

But we would just have to wait until he comes back.

[Dunbaratu]

Were SMA and ECC taken directly from the API are were they calculated by the code you added?

[erendrake]

Everything came directly from the API. There are quite a few properties in there that could be useful. Im thinking about tying some of this more advanced stuff into the tech tree like MechJeb does.

[Dunbaratu]

I like the idea of the tech tree not being boolean everything/nothing, but I thought it only allowed the locking and unlocking of parts. So how do you lock or unlock a bit of KOS programming API with the tech tree? Make several variants of the SCS module and have them unlock at different points on the tree, and then have the KOS code maintain a list of which parts "know" how to do which calls? Actually.. that sounds like it could work.

[erendrake]

@Dunbaratu Pretty much, Mechjeb has for some time had everything broken into modules that you could enable with a config file. So when the tech trees were added it was simple for him to query the tech tree on vessel change/launch and enable the correct modules.

We dont have the equavilant legacy in kOS so its going to be a long road to get there. It would likely have a bunch of creep like decreased sensor fidelity and/or available memory depending on where you are in the tree.

A lot of possibilities.

[Dunbaratu]

I don't use mechjeb so I have to ask: How does this feature look to the user on the tech tree screen? Does the user see which nodes enable which portions of mechjeb or do they have to look that up somewhere else? That's what I think the advantage of having different ship parts to do it would be. There could be "this part is a primitive KOS computer that can only do A,B,and C, and this other part is a slightly better one that can also do D,E, and F...." and so on. Because the parts that a node unlocks show up in the tech tree user interface the player can see on the screen which tech nodes unlock which KOS features.

[erendrake]

@Dunbaratu The mechjeb version is not visible in the techtree other than the two parts, and i dont believe the second one unlocks anything. There are a few named nodes such as "unmanned tech" that unlock more modules.

I have been thinking about this and i think if it was up to me i would add module manager to the project so that each of KSP's unmanned pods could become a kOS computer, all with different capabilities (memory, update speed, sensor accuracy) or maybe just based on size. I believe doing so would cleave closer to @Nivekk 's original goal for the project.

I hope he comes back or makes his intentions for the future of the project clear soon.