Some issues with landing...

[Assert1]

I am working on a landing system for space planes and rockets, please look at this videos:
http://www.4shared.com/video/BA6po3Tece/KSP_x64_2016-09-25_18-00-16-96.html
http://www.4shared.com/video/zMDxxP_Mce/VLand.html
You can dowload it for hi quality.

I have some problems there:

1. I can't compute exact vertical distance to surface. Everyting that i can get, is a distance between vessel's center of mass and surface. But for perfect landing, i need a distance between lowest point (gear or landing leg) of the vessel and the surface. In the current implementation, i am using distance from the lowest part origin + some manually entered value for each vessel (actually landing gear/leg length). Solution is to give me the bounding box for each part. Then i can compute exeact distance.
2. I can't detect "on ground" state cleanly, but it is required to cut off engines or make pitch down on the runway. Solution is to give me a compression state of gears and landing legs.
3. Brakes have only two discreet states, on and off, but i need to manage drag more carefully (you can see on\off brakes sequence on the video). It will be great if i can set breaks state as floating point value.
4. There is no way to get a list of available runways on the planet and it's coords.
5. body.surface_height precision is too low, if i am trying to use it as reference for landing, space plane ends up within runway thershold or well above it. So, i need a way to get runways height above sea level to make clean landing (currenly it is fixed manually).
6. Parachutes from 'realchutes' mod is not detected and can't fire they automatically.
7. Aerodynamic and atmospheric data is not accessible:( You have Expose GetPressure() and GetDensity() from KSP API. #350 for the atmosphere, but this is only a part of story. Aerodynamics is not so important for the launches, but very important for landings... i can't compute pure ballistic landings without it. I can't manage energy for aerodynamic descent (currently i need to carefully set a target altitude for deorbiting to land space plane without engines). But, we have a plugin named KSPTrajectories, that can compute this data. May be you can integrate it's flight model computations from there: https://github.com/neuoy/KSPTrajectories/tree/master/Plugin/AerodynamicModel and give some API to build this model on the client side. If i have this models, i can compute a realy nice landings in all cases for all vessels.

[djungelorm]

All sound like reasonable requests - will see what I can do!

[PeteWasEre]

For point 3 on brakes, what would be awesome to go with this is wheel speed! Or at least a wheel locked indication because then I could make anti-skid!
For point 4 this would go very well for my request for custom reference frames. If i could get a runway end point and place a reference frame there i can then easily draw variable approach guidance lines and even implement ILS.

[djungelorm]

Here are some thoughts and questions:

1. I plan to add Vessel.BoundingBox(referenceFrame) and Part.BoundingBox(referenceFrame) methods, which will return an axis aligned bounding box (aligned to the coordinate axes of the reference frame) of the vessel (i.e. all its parts combined) or an individual part. The bounding box will be returned as a pair of positions - the max and min corners of the box as position vectors. Sound good?
2. How were you trying to do this? Using the Vessel.Situation property? Or is that not accurate?
3. There are also lots of other wheel features that aren't exposed through kRPC that should be added. I last touched that bit of code back before the 1.1 update and its major wheel overhaul, so kRPC is missing a lot of things.
4. I plan to add a CelestialBody.Locations(referenceFrame) method that returns a dictionary, mapping the name of the location to its position in the given reference frame. I think that should suffice for your use case. If we want anything more complex then it might be worth returning a list of Location classes containing more than just the name and position. Fingers crossed a list of "locations" is available in the KSP API somewhere...

[Assert1]

1. Yep sounds good. I think this will be enought.
2. I need to detect touchdown time for space plane, when it hits the runway at first time. Real aircrafts uses proximity sensors on the gears that signals compressed state. Vessel.Situation can't help there, becuse it chages after evessel is stopped and engines are off.
3. I mean airbrakes.
4. I think this is enought for me if i can get runways endpoints in this way.

[djungelorm]

I've added the bounding box RPCs. It was a bit more tricky than I first thought: using part.collider.bounds doesn't provide a very tight bounding box (as the AABB was in world space), but I got it working nicely using the parts MeshColliders directly (where the AABB is in part space).

Getting the travel distance of the suspension is a bit tricky (there is no simple property to access it). However, there is a boolean ModuleWheelBase.IsGrounded field. So I've added LandingGear.IsGrounded and LandingLeg.IsGrounded which return this state. Should fix your use case. I can always revisit this in future If we need the actual travel distance.

[djungelorm]

I've also had a look into programmatically finding the runway locations. The only thing I could find is that each celestial body has a list of PQSCity objects attached to it. A PQSCity is a structure on the surface of a planet. For example, Kerbin has the following PQSCities (which include a position, relative to the center of the planet):

Monolith02       (159687.15, -291892.43, 506176.42)
IslandAirfield   (582025.46, -16137.60, 145341.02)
Monolith00       (480458.80, 349977.01, 92987.19)
Monolith01       (601746.65, -6751.02, 54382.53)
KSC2             (276098.99, 211086.20, -489612.58)
UFO              (61831.34, 594184.01, -56831.21)
KSC              (588347.36, -1014.91, 117888.32)
Pyramids         (336247.34, -68139.13, -493934.00)

Unfortunately there's just a single entry for the KSC and the position is roughly 100m east of the VAB. To get the ends of the runway, you'd need to apply a manual offset to this position which, as far as I can tell, can't be found through KSP's API :( I don't want to hardcode this offset into kRPC, as it wouldn't be correct when you use mods that add new launch sites and move the KSC around.

An alternative approach would be to place a flag at the ends of the runway and use the positions of them for guidance? I'll look into adding RPCs to get flag locations.

[Assert1]

Ok, i understand. May be in future we can improve this. I am simply add a txt file to my application with user defined runways and landing locations. And add location output in the interface, to get numbers for current position simply. If you can add the flags list, then i can append it to selection menu. So, issues 1, 2, 4 and 5 is resolved for now. Thank you. Waiting for other...

[djungelorm]

Getting back to this after a long time...

3. Looking at the airbrakes, they are just ordinary control surfaces and so have an "authority limiter" control (accessible via right click). I'll add access to this to the API. Then you'll be able to enable brakes, then adjust the authority limiter to move the airbrakes as desired.

[Gamrix]

For people still waiting for realchute support, you can fire chutes through the following code

for p in vessel.parts.all:
    if "parachute" in p.name:
        for m in p.modules:
            if m.has_event("Deploy Chute"):
                m.trigger_event("Deploy Chute")