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

Excellent, we need more people documenting stuff. Allow me to suggest contributing to my Github project instead of the wiki. There are instructions for contributing at that link; a number of people have contributed to the project so far. The web documentation you linked in your OP comes from my project. My project also results in XML documentation that can be read by your IDE. I tried documenting things on the wiki for a while but wikis are not designed for documenting source code. Proper tools like Doxygen (which generates the web docs you linked) are much easier to use and generate much nicer pages.

One difference: EditorLogic.fetch.ship.parts has the property that the parts are listed in the same order as they were attached to the vessel. EditorLogic.SortedShipList doesn't have this property.

DMagic just added some nice information on all the GameEvents callbacks; check it out! -- http://anatid.github.io/XML-Documentation-for-the-KSP-API/class_game_events.html

Please consider contributing to the community documentation here: https://github.com/Anatid/XML-Documentation-for-the-KSP-API

This documentation is more complete. But that's not saying very much. Often there is no documentation and you have to look through the Object Browser for likely-looking class names. In this case the relevant things are in fact documented and you can probably you can do something like int resourceID = PartResourceLibrary.GetDefinition("LiquidFuel").id; double freeSpace = 0; for(Part p in vessel.parts) { for(PartResource r in p.Resources) { if(r.info.id == resourceID) freeSpace += r.maxAmount - r.amount; } }

Yes, dV = (average acceleration due to thrust) * (burn time). This is an exact equation. However note that your vessel can accelerate for other reasons than thrust, for example gravity and drag. You have to factor these out before you compute the dV in this way. That is, the acceleration you need to use is the average acceleration in 0g with no air resistance.

Thanks very much for making this possible a.g.! I'm currently trying out profiling on Windows with your latest release and it seems to be working.

The Object Browser in Visual Studio, or whatever its equivalent is in MonoDevelop, can list all of the available classes, methods, etc. Look for the TimeWarp class inside Assembly-CSharp.dll. For documentation, see here and specifically here.

Almost certainly BaseField stores a reference to the FieldInfo for the field in question, and BaseField.GetValue() just calls FieldInfo.GetValue(). Presumably the list of BaseFields is created at startup by walking through the member variables looking for the [KSPField] attribute, and as each BaseField is created it is given the reference to the FieldInfo.

I'm guessing that when you see this your orbit is very close to circular. For circular orbits the position of periapsis is not well defined, and for near-circular orbits the position of periapsis will be very sensitive to small perturbations to the orbit. So probably what you're seeing is physics integration errors + near-circularity. KSP uses a fixed but arbitrary direction as the reference direction. I don't think there's anything special about it. It seems to point roughly opposite the center of the galaxy in the stock skybox. You can determine the reference direction for yourself by setting up an orbit with LAN=0. Then the ray from the center of the planet to the ascending node will point along the reference direction.