The_Duck

Hah, this is my code. It took me a whlile to figure out what it's doing. I think this is the idea, if anyone's still interested: The tricky line is double effectiveDecel = 0.5 * (-2 * g * sine + Math.Sqrt((2 * g * sine) * (2 * g * sine) + 4 * (T * T - g * g))); where we defined double sine = Math.Sin(angleFromHorizontal * UtilMath.Deg2Rad); effectiveDecel could be rewritten more simply as double effectiveDecel = -g * sine + Math.Sqrt(T*T - (g*cosine)*(g*cosine)); where cosine = Math.cos(angleFromHorizontal * UtilMath.Deg2Rad) (I wonder why I didn't do that in the first place). In a suicide burn typically you point your thrust directly opposite your velocity. Then under the influence of gravity, your trajectory will become more vertical over time as you kill off more and more of your horizontal velocity. However this calculation is for a slightly modified suicide burn with easier math. In this modified burn we are going to angle our thrust so that the *net* force of thrust+gravity points directly opposite our current velocity. In that case as we declerate our velocity keeps pointing in the same direction as we slow down. Then all the angles and stuff stay constant during our descent, which makes things simple. We just need to calculate our deceleration, so we can tell how long it will take us to come to a stop. We decompose the gravity vector into two components: the component perpendicular to our velocity (whose magnitude is g*cosine) and the component parallel to our velocity (whose magnitude is g*sine). We are going to angle our thrust vector to point slightly upward of the direction opposite our velocity. There will be two components to our thrust, too: the component opposite our velocity and the component perpendicular to our velocity. We'll angle our thrust so that the component perpendicular to our velocity exactly cancels the component of gravity perpendicular to our velocity, (which is g*cosine). So the component of thrust parallel to our velocity will have magnitude sqrt(T^2 - (g*cosine)^2). Now our total deceleration will be the difference of two things: the component of our thrust opposite our velocity (which slows us down) and the component of gravity parallel to our velocity (which speeds us up). The component of gravity parallel to our velocity is g*sine. So we get the total deceleration sqrt(T^2 - (g*cosine)^2) - g*sine. Now this isn't quite how we do suicide burns in practice, but it's pretty close. And anyway there is a built-in safety margin because as you burn fuel your craft gets lighter so your TWR increases, but the calculation above makes the pessimistic assumption that you'll have the same TWR throughout the burn.

Sure, I added a license.

Hi guys-- sorry for abandoning the Github documentation project. I haven't spent time on KSP in quite a while. You're of course free to fork it. Let me know if you need explanations of how I built the XML and HTML docs from the .cs files.

The reason is the following. Corrective steering tries to control the direction of your velocity so that you fly along the given ascent path. But should it use orbital velocity or surface velocity? It ends up using a weighted average of the two that shifts over the course of the flight, so that it starts out controlling surface velocity and gradually switches over to using orbital velocity. But orbital velocity already starts somewhat "pitched over" so this can cause MJ to seem to delay the pitchover past the given "turn start" altitude, since it feels that it is already somewhat pitched over.

Probably you need to look for the ModuleCommand PartModule and check its minimumCrew field. Presumably the vessel is controllable if at least one part with a ModuleCommand module has a number of crew greater than or equal to its minimumCrew. See the part.cfg files for the existing command pods.

myFunction needs to take a ShipConstruct: private void myFunction(ShipConstruct sc) { } If an argument needs an EventData<T>.OnEvent, what it needs is a function that takes a T and returns void. See the declaration of the EventData<T>.OnEvent delegate type here. See here for some documentation on GameEvents.

Or, more simply, part.mass + part.GetResourceMass().

Look, what do you think the point of the EULA is? It's not to prevent modders from learning how to write plugins. The EULA clause you are referring to is to protect the private *implementation* of KSP itself. KSP is a game intended to be modded. It's not an accident that KSP loads any assembly you put in the GameData folder; it's a feature that was added so that people could write plugins. Squad originally had some intention of publishing some documentation for the KSP public interface, but never got around to doing so (understandably: it would be a big task and it would take a ton of time away from working on the actual game). In the meantime we are writing the documentation for ourselves.

You're probably making this too complicated. Why do you need the "thisPart" field at all? It's not doing anything for you that the "part" field doesn't already do.

This documentation is based on experience and trial and error using the public interfaces available in the KSP assemblies, not decompilation.

Probably this is off-base, but what if you try to place the maneuver node a bit in the future, instead of right at the present? E.g.: double ut = Planetarium.GetUniversalTime() + 10;

So there are other errors. Can you upload the whole log somewhere so we can see what they are?

Are there other error messages too? Perhaps you can upload the full log somewhere? I can fix this particular error message but it shouldn't be causing the problems you are reporting. I'm guessing this error message is the result of some other problem, which may or may not be caused by MechJeb.

Make sure your project targets .NET 3.5 (it's in the project options in VS). Does that method exist in .NET 3.5?

The forum post for the project was recently stickied: http://forum.kerbalspaceprogram.com/threads/30401-Documentation-for-the-KSP-API