skips

@DiGriz The Makefile that is included with the source works if you have a Steam version of the program. Otherwise you will have to change the KSPDIR variable to point to the directory that contains the application. skips

@sarbian I think that you need the comparisons to be "!=" in the change to the optimization code. Also, could I ask a favor and have you add the following lines to the .gitignore file. I would make my compiles a bit cleaner. # Files for the Mac .DS_Store skips

@Sarbian The issue is in the routine SetGUIScale() in the file MechJeb2/GuiUtils.cs The optimization that you added to check if scale is equal to s is leaving the scaledScreenHeight and scaledScreenWidth set to their initialized values of 1 rather than Screen.height and Screen.width. Deleting the lines if (scale == s) return; will resolve the problem but also removes your optimization. skips

@Sarbian The 7274d38 "Fix 'Restore factory settings' doesn't seem to affect scaling." commit is breaking the MechJeb menu. Without it MechJeb appears to be working. skips

Patch 1.0.2 allows for Temperature and Atmospheric Pressure Scan in any situation.

I suggest that you read a book on orbital dynamics before criticizing MechJeb. Return from Moon will not work from an orbit that is normal to the orbit of the object that you are orbiting. It is not possible. You need change your orbital plane to match the orbital plane of the moon that you are orbiting. skips

My suggestion for the MJ unlocks is to move all of the information modules very early in the tech tree (i.e., second or third element of the tree). They are one of the truly missing components in KSP and are very useful to people learning how to construct and fly rockets. skips

Version 1.0.2 appears to have updated the drag coefficients for the aerodynamic model and the durability of parachutes. Don't bother opening them before you pass through the heating zone. MechJeb works if you can get around the compatibility checker. (Athough I have not gotten far enough along in the career mode to try to get to orbit.) skips

This problem of MechJeb aggressively attempting to reduce the shock of the parachute opening and reducing the velocity below 0.5 meters per second, which cuts the parachutes, occurs with the stock aerodynamics on occasion. skips

I believe that I have seen the issue with failure to control the attitude of the spacecraft on re-entry. In my case, it was from a vertical launch, which is normally very consistent. This time the predicted landing miss distance was 3 m and unchanging, and the time to landing was negative with the ship at approximately 40 km altitude. It looked like one of the pointers to the control or state array got badly scrambled. I have tried to reproduce the issue a half a dozen times without any success, which suggests that it is either a race or thread synchronization condition. skips

Since the cries of "its broken" have died down, here is a suggestion. I would like to recommend changing the launch guidance circularization step to match the requested semi-major axis (i.e., altitude plus body's radius) rather than altitude. This change would have two advantages: first, for those who are trying to match a period, this approach would attempt to achieve that goal, and second, if the requested altitude is needed, this approach would assure that the apoapsis and periapsis bracket the desired altitude, which makes the circularization at the desired altitude be one maneuver rather than two. The code change is one line: @@ -348,7 +348,8 @@ namespace MuMech //place circularization node vessel.RemoveAllManeuverNodes(); double UT = orbit.NextApoapsisTime(vesselState.time); - Vector3d dV = OrbitalManeuverCalculator.DeltaVToCircularize(orbit, UT); +// Vector3d dV = OrbitalManeuverCalculator.DeltaVToCircularize(orbit, UT);^M + Vector3d dV = OrbitalManeuverCalculator.DeltaVForSemiMajorAxis(orbit, UT, desiredOrbitAltitude + mainBody.Radius); vessel.PlaceManeuverNode(orbit, dV, UT); placedCircularizeNode = true; skips

This problem is likely due to the fact that public void ThrustForDV(double dV, double timeConstant) does not limit the minimum value of the throttle that it computes and it is computing a value below the flameout throttle for your engine. skips

@Halaberiel If you are playing in Career mode with KSP 0.90, there are some upgrade requirements on the KSC buildings that you must do before all of the MechJeb capabilities are available. This requirement is a Squad decision. If you do not like it, either play in sandbox mode or complain to them. skips

sarbian The change makes the routine meet the contract that is defined in its definition i.e., allow the atmosphere to slow the spacecraft. The original implementation of the returned a zero when the plan was to end and apparently the caller was supposed to recognize this flag. It appears that the autopilot code was rewritten without taking this requirement into account and the person who rewrote the autopilot decided to arbitrarily return the value 1, which corrupts the landing simulation. If the plan is intended to track the required maximum velocity all the way to the ground, then it will need substantially more information than the original design gave it. skips

FixedUpdateCoastToDeceleration() drops you from the coast state to the LandStep.DECELERATING if the ship's speed is greater than 0.9 times the speed returned by MaxAllowedSpeed(). To prevent changing state you need to return a speed that is 1.11111111 times larger than the ship's speed. For that reason, you must divide vel.magnitude by 0.90. I added the 1.0 just to make sure that the finite precision issues did not cause any problems. I can assure you that this code actually prevents the simulation from attempting to traverse the last 1000 meters at 1 meter per second speed. skips

See my last post. Most of the drift that I see occurs before the ship enters the atmosphere, which suggests that it is not a MechJeb simulation issue. Changing PWBCoastDescentSpeedPolicy in the manner that I listed in the last post makes the delta-v estimate zero and the time estimate good to a few seconds. skips

I just ran a couple of tests landing one of my small test vessels at KSC with Landing Guidance and build 393. After fixing the problem with class PWBCoastDescentSpeedPolicy : IDescentSpeedPolicy { public double MaxAllowedSpeed(Vector3d pos, Vector3d vel) }, KSP with only MechJeb installed was successful in landing within 180 meters of the landing pad from a 300 KM orbit. Since the deburn only gets within 150 meters, this means that the landing prediction only drifted by 25 to 30 meters. Before your change to the velocity vector the drift was anywhere from 150 to 300 meters. I need to try a couple of landings with a smaller initial precision. Please note that you cannot get this accuracy as long as the PWBCoastDescentSpeedPolicy returns erroneous values from the MaxAllowedSpeed function. The version that I am using is public double MaxAllowedSpeed(Vector3d pos, Vector3d vel) { return (vel.magnitude / 0.90) + 1.0; if (pos.magnitude > endCoastRadius) return double.MaxValue; else return 1; // It is a bit silly to set this at 0 because then the simulation times out as it never reaches the ground. } YMMV skips

I am getting an ArgumentException that appears to be coming from MechJeb. I am using KSP 0.90.0.705 (OSXPlayer) BETA and MechJeb Dev version MechJeb2-2.4.2.0-381. I can reproduce the error by moving a ship to the launchpad, opening the Maneuver Planner window and selecting Duna as the target. The log contains [EXC 13:29:24.629] ArgumentException: Getting control 6's position in a group with only 6 controls when doing Repaint Aborting UnityEngine.GUILayoutGroup.GetNext () UnityEngine.GUILayoutUtility.DoGetRect (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) UnityEngine.GUILayoutUtility.GetRect (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) UnityEngine.GUILayout.DoButton (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options) UnityEngine.GUILayout.Button (System.String text, UnityEngine.GUILayoutOption[] options) MuMech.MechJebModuleManeuverPlanner.WindowGUI (Int32 windowID) UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID) UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)

The described behavior is consistent with something issuing spacebar characters at random times. My experience with MechJeb 2.4.2 and KSP 9.90 has been no worse than the earlier releases. I have successfully completed the career mode through researching all of the tech tree and getting three kerbalnauts to level 5 (1 pilot, 1 engineer and 1 scientist). Admittedly I run a rather clean game with only ModuleManager and MechJeb mods installed (and a few customized parts). skips

All right already. You have "shamed" me into discussing this topic of "expectations." But first, you should understand a bit from whence I am coming. My job is maintaining software that is flying on an active NASA spacecraft. Further, I wrote my first operating system as an undergraduate and, as a graduate student, wrote the software that automated the control of the instrumentation, with which I collected the data for my thesis. As I see kOS, it is primarily a programming language and secondarily a mechanism for controlling vehicles in KSP. As such, it should meet the expectations of a programming language and hopefully provide an abstract model for vehicle control that is compatible with the model that is provided by KSP. Meeting these goals allows the users of kOS to concentrate on building the vehicle and providing "software" that makes the vehicle do "useful" things. So what does all of this "vision" mean? Well I have written three scripts that I use. mission() - describes a mission. Currently it supports missions of the type, "activate this part between altitude s0 and s1 and speeds v0 and v1." To use it for different missions of this type, the user must edit the script (i.e., "wire the rocket's controller"). This script uses two other scripts. ascent( min_altitude, min_speed, action, max_altitude, max_speed, ascent_policy ) - controls the rocket from liftoff to completion of the upward and downward goals. The goals relate to the vertical speed's sign and being within the max_ and min_ limits. landing( landing_height, landing_speed ) - attempts to land the rocket by arriving at the landing_height with a vertical speed no more negative than minus the value of the landing_speed. The script then maintains the vertical speed as minus the landing_speed value until the rocket is in the LANDED state. To achieve this goal the script must calculate the latest time at which it can burn and still arrive at the landing_height and meeting the landing_speed constraint. Which brings me back to my original comment about the information about engine thrust. To implement the landing() script it is necessary to answer the question "what thrust (both direction and magnitude) does the vehicle provide if the throttle is set at 1?" With this fundamental information, the script can make decisions about how to achieve its goal of arriving at the landing_height with the desired landing_speed. In the "real world" the software controller is given this information about the thrust magnitude and direction by the designer of the vehicle. The software does not iterate over the parts of the "real hardware" and assemble the information. I guess that I an expecting the abstract vehicle model within kOS to provide the same level of abstraction. As relates to the programming aspect, I believe that the kOS team should take a hard look at what the language currently provides and determine whether it meets all of the implied requirements of its current implementation. I, for one, believe that it does not. The discussion of "null type" is a primary example of a missing requirement. The language currently automatically assigns dynamic types (i.e., the type of a variable can change during the execution of the program). This characteristic generates an implicit requirement that the language provide a mechanism for testing the type of a variable. If such a capability is provided, the whole discussion of "null type" is mute. Well I have rambled more than I should have. If you wish to discuss these issues further, lets move the discussion to your developer thread. skips

If C# supports "closures," there are a couple of elegant approaches to handling dynamically created resource names that are consistent with my original proposal. skips

Thank you for your comments. It is clear to me that you and I have very different expectations for this mod. Given that it is your mod, I will back out of the discussion at this time. skips

@Steven Mading r.e.: Major sweeping changes like would be required to implement such things throughout the C# code require buy-in from everyone ... Here is my view of what the change would be: In public abstract class SpecialValue change GetSuffix() to public virtual object GetSuffix(String suffixName) { switch (suffixName) { case "INFO": return "Suffix INFO not implemented on this structure"; } return null; } For each class that is a subclass of SpecialValue and contains a GetSuffix() method add a case "INFO": clause. (I am using public class GeoCoordinates : SpecialValue as an example because it appears to be reasonably well documented and not overly long.) public override object GetSuffix(string suffixName) { switch (suffixName) { case "LAT": return Lat; case "LNG": return Lng; case "BODY": return new BodyTarget( Body, Shared ); case "TERRAINHEIGHT": return GetTerrainAltitude(); case "DISTANCE": return DistanceFrom(); case "HEADING": return GetHeadingFrom(); case "BEARING": return GetBearing(); case "INFO": return "GeoPosition.LAT - the latitude\n" + " .LNG - the longitude\n" + " .BODY - the body\n" + " .TERRAINHEIGHT - altitude above sea level\n" + " .DISTANCE - straight line distance from CPU vessel\n" + " .HEADING - compass heading from CPU vessel\n" + " .BEARING - angle between vessel's heading and .HEADING\n" + " .INFO - this information" } return base.GetSuffix(suffixName); } Implementing in this manner allows the code to continue to function while the changes are being made. In addition I believe that the changes are localized to the one method. Note that the returned string is only useful for the same purposes as the ToString() method (i.e., as the body of a PRINT, SET or LOG... TO statement). skips

Think VTOL craft. That said, I have a fundamental issue with assuming that the facing of the spacecraft, which is presumably determined by the orientation of the controlling part, is the same as the orientation of the engine, which is a different part. There is nothing in the construction of KSP that requires any specific relationship between these two directions. I think that it would be wise if the mod took the same stance. skips

Another way to look at this issue is that angular momentum is conserved. skips