Feature Request/Unexpected Behaviour: Redo Suicide Burn Readouts

[harryyoung]

Right now the Suicide Readouts are a bit misleading. Without stating it it assumes that the horizontal velocity is nonsignificant and all available thrust can be used to kill the vertical velocity. Therefore, doing suicide approaches with significant horizontal velocity, I often Crash.

For my kind of suicide Burns I prefer the following Readouts:

• Suicide Burntime: Time Required to kill all velocity
• Time to Suicide Burn: time until the Suicide Burn needs to start
• Suicide Burn DeltaV: DeltaV used in the Burn

This basically behaves like a maneuver node where prograde dV is Surface Speed + Acceleration due to gravity. All that I think is missing is the timing.

[harryyoung]

I have tried this myself and basically canibalized the Concept of the Maneuver Node Calculator, but with a given velocity in Horizontal and vertical + Acceleration due to gravity. harryyoung@299fc08
I am not seinding a Pull request As I am unable to compille this in Xamarin.
When I open the Project i get: Could not load project 'KerbalEngineer.CSharp.Editor.csproj' with unknown item type '{E097FAD1-6243-4DAD-9C02-E9B9EFC3FFC1}'
When I try to Build I get: C:\Users\hendr\Documents\GitHub\KerbalEngineer\KerbalEngineer.Unity\KerbalEngineer.Unity.csproj: Error MSB4132: The tools version "14.0" is unrecognized. Available tools versions are "2.0", "3.5", "4.0". (MSB4132) (KerbalEngineer.Unity)

[Gerry1135]

It looks reasonable to me, should certainly be more accurate than the current code though it still uses the terrain altitude immediately below the craft which could be considerably different than at the landing point. Perhaps worth integrating as new readouts so people can test it. If it does turn out much better then the old ones can be removed.

The Xamarim problem looks like it doesn't cope with VS2015 projects correctly, both of the C# plugin projects are definitely set to .NET 3.5. I would also doubt that it would manage to compile certain newer bits of C# that are now used in the source (e.g. the "?." operator).

[harryyoung]

I don't like VS... but it worked. Actually helped me find some Bugs i created. Might have to go back :D

I'm not sure using the altitude at the predicted landing site will make a difference. Will do some Reasearch into that. For now I will test this out.

[Gerry1135]

I'm talking about a situation such as coming in at quite a shallow angle to land on a Minmus flat (or at the bottom of a deep crater elsewhere) but you currently being over the (rather high) hills surrounding the flat. The code will underestimate the amount of vertical speed you gain before landing, possibly resulting in you starting the burn late...

[harryyoung]

Video Demonstration: https://youtu.be/6Rb1LDvKdok

[harryyoung]

I think I have found a way to reintregrate that in a second step.
I cannot intregrate in the First step as I do not know my landing position with high enough precision (the impact Point will move over the burn) and I need to konw either that or my burn time. However If I calculate my burn based on the current Radar Altitude I can get the horizontal (and vertical) Distance covered over the burn (0.5 horizontal Velocity / time) and from that get the Landing point, Altitude and Slope - research pending. From that I can get an Altitude at landing Point = Ship Altitude - Landing Terrain Altitude - Vertical Distance. If that falls below 0 you Crash. If not all you have to watch out for is a mountain blocking your trajectory (I can't save you from that) and to manage your final Trim at landing. If anything you start your burn early and may want to do a heavy trim Burn. The DeltaV readout will actually adapt for that.

[harryyoung]

I have Built the Framework in harryyoung@bae35e6 but it's throwing NaN's like Crazy and I don't get the impact point Calculation right, probably because I have not tought about it propperly. I know my Position and the distance covered over the Landing burn, I have no Idea how to handle Lat and Long toh, So how do I predict the Point?