skips

The documentation should be very explicit about this issue. All of the programs that are running are sharing the same name space (i.e., the name "myVariable" is common to all of the programs). This behavior can easily generate problems where a program runs another program that changes one of its variables. The following code demonstrates the behavior: // mission controller // edit this file to change the mission // print "Begin mission.". legs on. wait 2. set landedHeight to alt:radar. print "Landed height set to " + round( landedHeight, 3). declare myThrottle. set myThrottle to 0. lock throttle to myThrottle. print "Throttle is " + round( myThrottle, 2 ). set missionParams to list(). set missionParams:add to landedHeight. run test1. print "Landed height is now " + round( landedHeight, 3). print "Mission complete.". and // test1 - for experimenting // print "Mission parameters: ". for item in missionParams { print item. } print "Landed height is now " + round( landedHeight, 3). declare landedHeight. print "Landed height in tst " + round( landedHeight, 3). set landedHeight to 0. print "Landed height in tst " + round( landedHeight, 3). The output should be Begin mission. Landed height set to 4.604 Throttle is 0 Mission parameters: 4.60407543182373 Landed height is now 4.604 Landed height in test 0 Landed height in test 0 Landed height is now 0 Mission complete. Program ended. Concerning your documentation woes: you might consider implementing an info suffix for all of your structures that prints out the names of all of the properties and suffixes for that structure. Users can use this capability to determine what is in a structure from the interactive window rather than searching the documentation. Keeping that information up to date becomes part of the maintenance of the structure rather than a separate documentation task. Finally, it appears to me that the information that you can extract on the engines is woefully inadequate. It is difficult to build scripts that intelligently control the spacecraft when it is not possible to tell how much thrust a throttle setting will generate _and_ in which direction the thrust will be applied. I have tried several approaches and none of them have created usable results. So far the best that I can do is to throttle the engines on and then use the ship:maxthrust quantity with the assumption that it is applied in the ship:facing direction. This approach fails when there are multiple engines and one or more of them have been thrust limited or have no fuel. Otherwise the kOS has been a blast for writing mission controllers like those that are used for sounding rockets. skips

There is no MacOS X 64 bit version of KSP available and the patch function is definitely broken under MacOS X. skips

@_constantin You need to look at how this directory (Kerbal Space Program) is configured in the sharing tab of the System Preferences. If that configuration is limiting who can write into this directory and its subdirectories, you need to make sure that you (the player account) is part of the group with read/write privileges. skips

I have been using it without any problems with KSP 0.24.2, and MacOS X 10.9.4 and 10.10 Developer Release 5 without any problems. On the other hand, I do not have any particularly significant changes being made with MM. skips

No problem. I have been looking at the definition of the interface IDescentSpeedPolicy and have drawn the conclusion that class CoastDescentSpeedPolicy and class PWBCoastDescentSpeedPolicy should always return the value double.MaxValue. Both of these classes try to define the speed policy that should be used if the atmosphere is doing the braking and the ship's engines are not to be used. Presumably the reentry simulation switches to a different policy at the appropriate time. skips

"switch to 1." means that subsequent references to files will be using the files that are local to the ship. "switch to 0." means that subsequent references to files will be using the files that are in the archive. "load from/save to archive." copies files from the currently active volume from and to the archive volume. If preceded by a "switch to 1." command, the files will be copied from the archive volume to the ship's volume and from the ship's volume to the archive volume. skips

@Doctor Lag I have to agree with Starwaster. The Module Manager configuration files that I use have been constant for the last three builds of KSP. There is a greater chance that they might have to change due to MechJeb changes than KSP changes. If that happens, I can edit one file, the contents of which I am responsible, and affect all of the appropriate files in the GameData folder. My MechJeb changes affect 11 files (2 MechJeb parts and 9 Squad parts). Using Module Manager allows me to do one edit and affect all of them. skips

@sarbian, I have traced down a likely candidate for the cause of the TimeOuts that occur when using the Landing Guidance. It appears to be an unfortunate interaction between the value of maxSimulatedTime, which is set to 2000 seconds in class ReentrySimulation, and the IDescentSpeedPolicy PWBCoastDescentSpeedPolicy. The PWBCoastDescentSpeedPolicy sets the maximum velocity (MaxAllowedSpeed) when below the coast radius to be 1 m/sec. The coast radius is set to be twice the landingSiteDragLength. When parachutes are enabled, this length is quite short as the typical terminal velocity is 5 - 10 m/sec. Without parachutes the DragLength is significantly larger. As a result the duration of the reentry is extended by a time that is like the DragLength divided by 1 m/sec. Watching reentries indicates that the times without parachutes often reach 30 minutes (i.e., 1800 seconds). The jitter in the calculation results in the timeouts. My assessment is that there are two "quick fixes": up the time for maxSimulatedTime to something like 4000 seconds _or_ increase the speed in the else clause of PWBCoastDescentSpeedPolicy.MaxAllowedSpeed() to a larger value (e.g., 2 m/sec). The correct solution appears to be to set the velocity in the else case to be slightly larger than the terminal velocity, but this approach might require redoing a bunch of the reentry simulation code. skips

@Doctor Lag The files that Starwaster and I posted are specifications for Module Manager to modify the .cfg files that are being loaded by KSP. The actual files are not modified. The copy in memory that is being used by KSP is modified. That said, you can modify the .cfg files in the KSP/GameData/Squad/ subdirectories by adding the MODULE { name = MechJebCore MechJebLocalSettings { ... } } sections to parts that are to enable MechJeb. Editing the save files might be a bit more complex. The issue is that KSP gets confused if there is more than one PART { ... } specification with the same name property. When that occurs, KSP allows you to research the part, but does not allow you to construct ships with the part. There is an explanation of why in one of my earlier posts in this thread. skips

I use ModuleManager.2.2.0 and a custom made configuration file. ///////////////////// // change the technology requirements for MechJeb ///////////////////// @PART[*]:HAS[@MODULE[MechJebCore]] { // delete any existing MechJebCore modules // !MODULE[MechJebCore] { } // insert MechJeb module with revised tech tree assignments// MODULE { name = MechJebCore MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = basicRocketry } MechJebModuleSmartASS { unlockTechs = flightControl } MechJebModuleManeuverPlanner { unlockTechs = advRocketry } MechJebModuleNodeEditor { unlockTechs = advRocketry } MechJebModuleTranslatron { unlockTechs = fuelSystems } MechJebModuleWarpHelper { unlockTechs = generalRocketry } MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl } MechJebModuleThrustWindow { unlockTechs = basicRocketry } MechJebModuleRCSBalancerWindow { unlockTechs = fuelSystems } MechJebModuleRoverWindow { unlockTechs = fieldScience } MechJebModuleAscentGuidance { unlockTechs = generalRocketry } MechJebModuleLandingGuidance { unlockTechs = generalRocketry } MechJebModuleSpaceplaneGuidance { unlockTechs = aerodynamicSystems } MechJebModuleDockingGuidance { unlockTechs = specializedConstruction } MechJebModuleRendezvousAutopilotWindow { unlockTechs = specializedConstruction } MechJebModuleRendezvousGuidance { unlockTechs = specializedConstruction } } } } @PART[mumech_MJ2_AR202] { @TechRequired = basicRocketry } ///////////////////// // Add MechJeb to the probe cores ///////////////////// @PART[*]:HAS[#vesselType[Probe],#category[Pods],!MODULE[MechJebCore]] { // insert MechJeb module with revised tech tree assignments// MODULE { name = MechJebCore MechJebLocalSettings { MechJebModuleCustomWindowEditor { unlockTechs = basicRocketry } MechJebModuleSmartASS { unlockTechs = flightControl } MechJebModuleManeuverPlanner { unlockTechs = advRocketry } MechJebModuleNodeEditor { unlockTechs = advRocketry } MechJebModuleTranslatron { unlockTechs = fuelSystems } MechJebModuleWarpHelper { unlockTechs = generalRocketry } MechJebModuleAttitudeAdjustment { unlockTechs = advFlightControl } MechJebModuleThrustWindow { unlockTechs = basicRocketry } MechJebModuleRCSBalancerWindow { unlockTechs = fuelSystems } MechJebModuleRoverWindow { unlockTechs = fieldScience } MechJebModuleAscentGuidance { unlockTechs = generalRocketry } MechJebModuleLandingGuidance { unlockTechs = generalRocketry } MechJebModuleSpaceplaneGuidance { unlockTechs = aerodynamicSystems } MechJebModuleDockingGuidance { unlockTechs = specializedConstruction } MechJebModuleRendezvousAutopilotWindow { unlockTechs = specializedConstruction } MechJebModuleRendezvousGuidance { unlockTechs = specializedConstruction } } } } If you remove the section that is referred to as "Add MechJeb to the probe cores", it will move the features to more accessible nodes and the MJ2_AR202 part to the first researchable node. You can achieve your goal of making all of the MechJeb modules available by editing the unlockTechs to all equal basicRocketry. skips

I was unable to duplicate the problem under MacOS X 10.9.4. The png images opened without any reported errors in preview. skips

@MechJec maintainers I have been looking through the MechJeb code in a effort to understand why the "Delta-v needed:" and "Time to land:" fields in the landing guidance report unrealistic values when no parachutes are available or "Deploy Parachutes" is deselected. In MechJebModuleLandingPredictions.cs StartSimulation(), the code for determining dragMassExcludingUsedParachutes appears to fail to accommodate parts that contain more than one ModuleParachute. // Is this part a parachute? foreach (PartModule pm in p.Modules) { if (!pm.isEnabled) continue; if (pm is ModuleParachute) { ModuleParachute chute = (ModuleParachute)pm; partIsParachute = true; // This is a parachute, but is it one that will be used in the landing / rentry simulation? if (deployChutes && p.inverseStage >= limitChutesStage) { // This chute will be used in the simualtion. Add it to the list of useage parachutes. usableChutes.Add(new SimulatedParachute(chute, patch.StartUT)); } else { partDrag = p.maximum_drag; } } } if (false == partIsParachute) { // Part is not a parachute. Just use its drag value. partDrag = p.maximum_drag; } If the part contains more than one ModuleParachute and the part is not going to be used in the simulation, the else clause will be executed once for each ModuleParachute and add the part's drag to the accumulated total multiple times. It appears to me that the code would be more robust if the partIsParachute was used to identify parts that have been added to the usableChutes list and parachutes that are not added be treated as "not a parachute". i.e., // Is this part a parachute? foreach (PartModule pm in p.Modules) { if (!pm.isEnabled) continue; if (pm is ModuleParachute) { ModuleParachute chute = (ModuleParachute)pm; // This is a parachute, but is it one that will be used in the landing / rentry simulation? if (deployChutes && p.inverseStage >= limitChutesStage) { // This chute will be used in the simualtion. Add it to the list of useage parachutes. usableChutes.Add(new SimulatedParachute(chute, patch.StartUT)); partIsParachute = true; } } } if (false == partIsParachute) { // Part is not a used parachute. Just use its drag value. partDrag = p.maximum_drag; } skips

I would like to point out that this issue applies to the Mac OS installs as well. It is unwise to install the KSP folder in your global Applications directory as Mac OS normally locks folders in that directory and makes them read only. It is wiser to create an Applications or Games directory in our home directory and install KSP there. just my opinion, skip

@barclone I only see that problem when the attitude control does not have sufficient authority. Generally adding another RGA helps or solves the problem for me. (OTOH, my ships tend to be a lot smaller than those that I believe you are flying.) skips

I did some landing tests with dev157 using a small test ship that I have. It has no parachutes, a TWR of 4.67 and a little more than 5000 m/sec dv. I performed a half dozen launches with the ascent guidance to a 100 km orbit and landings at the KSC launch pad. All of the landings were consistent with each other. The predicted landing errors after the orbit correction burns were between -85 and +45 meters, where negative is short of the landing point. The predicted landing after entering the atmosphere appeared to decrease by approximately 250 meters. i.e., the predicted landing point moved closer to the spacecraft. After the aero-braking (at 13 km) the error had increased by approximately 50 meters. i.e., the spacecraft decelerated more slowly than the prediction. During the final decent, the error increased by an additional 125 meters and stabilized at the point at which the suicide burn began. For the case where the prediction in vacuum was 45 meters long (past the target), the ship landed within 1 meter of the target. For cases where the vacuum errors was 70 meters short of the target, the ship landed approximately 140 meters short of the target. I draw two tentative conclusions from these observations. the aero-braking code slightly over-estimates the amount of braking that the drag forces produce. there is a change of the reference frame at or about the time that the final killing of the horizontal velocity occurs, which has the effect of giving the ship the rotational velocity of the landing point whereas the simulation is expecting the landing point to rotate under the descending ship. On the other hand the dispersion in the landing points appears to be reasonable given that the simulation does not make additional corrections in decent path after the aero-braking. At orbital velocities, a 200 meter dispersion is only 0.1 seconds time dispersion. I would have thought that the simplest approach for handling the level of precision that is needed would be to plan to overshoot the landing point and at some point after the majority of the aero-braking was complete to further kill the horizontal velocity with the engines. I am guessing that this approach is the way codepoet is getting the parachute landings to be accurate by timing the opening of the parachutes (which effectively eliminate the horizontal velocity). skips

I have two observations using dev154. 1. there still appears to be some sort of thread synchronization issue. After landing, I observed that the target difference value jitters from the nominal 193 m to some value in the hundreds of km (the value flashes on the screen for one update so the visual latencies only allow me to see a composite of the value with 193 m). The window for the issue must be relatively small because the flashes only occur at about 3-5 second intervals. 2. the predicted delta-v value does not seem reasonable. On most of my landings, I see values like 10,000 m/sec at altitudes of 5-7 km. On the last landing at 5 km the vertical velocity was like 175 m/sec. To just make it to landing with zero velocity takes 12.87 m/sec2 deceleration for 57.14 seconds or 735 m/sec delta-v, which is like an order of magnitude less than the value that is being reported. Since I ignored air drag, the actual required delta-v from the engine is probably somewhat less than my estimate. skips

Just to add some wood to the fire, here are some of my recent observations with MJ. 1.) Launch a two stage rocket into Kerban orbit with MJ controllers on both stages. Separate the stages. The Detla-V Stats for stage 1 look normal. Switch to the decoupled stage 2 and the Delta-V Stats are not reasonable. The Mass is zero and the TWRs are all NaN. The vehicle statistics display has a reasonable mass and MJ can control the stage. (even to the point of successfully landing at KSC). The log at that point is a bit screwy but does not appear to be related. [LOG 17:48:31.747] activating stage 1 - current stage: 2 [LOG 17:48:31.747] [science.module]: Activated [LOG 17:48:31.748] Should have Jettisoned [LOG 17:48:31.748] [liquidEngine3]: Activated [ERR 17:48:31.780] MechJeb caught exception in core OnSave: System.NullReferenceException: Object reference not set to an instance of an object at MuMech.MechJebCore.OnSave (.ConfigNode sfsNode) [0x00000] in <filename unknown>:0 [LOG 17:48:31.786] [00:06:26]: Separation of stage 2 confirmed [LOG 17:48:31.786] [stackDecoupler]: Activated [LOG 17:48:31.786] [mumech.MJ2.AR202]: Activated [LOG 17:48:31.786] [batteryPack]: Activated [LOG 17:48:31.786] [batteryPack]: Activated [LOG 17:48:31.786] [batteryPack]: Activated [LOG 17:48:31.786] [GooExperiment]: Activated [LOG 17:48:31.786] [GooExperiment]: Activated [ERR 17:48:31.836] MechJeb module MechJebModuleThrustController threw an exception in Drive: System.NullReferenceException: Object reference not set to an instance of an object at MuMech.CelestialBodyExtensions.RealMaxAtmosphereAltitude (.CelestialBody body) [0x00000] in <filename unknown>:0 at MuMech.VesselState.TerminalVelocityStockKSP () [0x00000] in <filename unknown>:0 at MuMech.VesselState.TerminalVelocity () [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleThrustController.TerminalVelocityThrottle () [0x00000] in <filename unknown>:0 at MuMech.MechJebModuleThrustController.Drive (.FlightCtrlState s) [0x00000] in <filename unknown>:0 at MuMech.MechJebCore.Drive (.FlightCtrlState s) [0x00000] in <filename unknown>:0 [LOG 17:48:37.446] [FLIGHT GLOBALS]: Switching To Vessel Mun Surveyer 1 Probe ---------------------- [LOG 17:48:37.448] stage manager resuming... [LOG 17:48:37.501] Focus changed! Forcing Mun Surveyer 1 to save 2.) Using the Return from Moon option of the Maneuver Planner to return from Mun appears to generate erroneous maneuver nodes. Starting from a 100 km equatorial orbit around Mun and requesting a 100 km periapsis gives a maneuver that results in an orbit that intersects Kerban. Reduce the Prograde velocity change by about 6 m/sec and the orbit grazes the Kerban surface. Another 6 m/sec and the periapsis is approximately 100 km. If you request a 300 km periapsis, the maneuver planner gives you approximately a 100 km periapsis. Repeat the experiment from Minmus and a 100 km request yields an orbit with a 100 km periapsis and a 300 km request yields a 300 km periapsis. It appears that the initial conditions for the Mun computation must be incorrect. 3.) When making inclination changes with the maneuver planner, you can match the orbital plane of another object orbiting the same central object or at some angle to the equatorial plane. There does not appear to be an option to set an inclination with respect to the central object's orbital plane. This option is equivalent to the equatorial plane, if the rotational axis of the central object is normal to its orbital plane, but this situation is rather rare in the real world. (Earth's orbital plane i.e. the ecliptic is tipped 23 degrees from the equatorial plane.) Matching the inclination of the orbit of the central body is useful for making maneuvers that are designed to move you out of that object's sphere of influence. skips

@sarbian I have been watching the landings done by the Landing Guidance module. The landing prediction appears to change dramatically as the spacecraft is rotated as if the computation was using the control point of the spacecraft (which is normally at one end of the craft). Prior to entering the atmosphere, the landing prediction is generally within a couple of meters of the target. As the landing continues the predicted landing point gradually moves longer (i.e., Eastward if you are approaching from the West). At the point at which the spacecraft goes vertical for the final decent, the landing point appears to move approximately 100 meters (for a spacecraft that is approximately 2 meters long). All of these observations appear to be consistent with the landing simulation being computed from one end of the spacecraft rather than from the center of mass. The landing predictions might be significantly more stable (and accurate) if the simulation made the computations using the location of the center of mass of the spacecraft. skips

Can you provide some more details? I have had no problems using MechJeb on MacOS X 10.8 and 10.9 other than ones that have been posted to this forum. MacOS X 10.9 has issues with KSP that are independent of MechJeb. (the independent issues are 1.) KSP writes to directories in its directory. Since this activity is expressly forbidden for the /Applications directory, it is wisest to have KSP installed in your home directory or a subfolder of your home directory. 2.) MacOS X has issues with the manner in which the SM3 Terrain Shader handles memory management - or at least that is how I read the sampling - and so hangs when the shader is being used. The SM3 Terrain Shader in settings:Graphics should be disabled in MacOS X 10.9) skips

@sarbian I am pleased to say that the latest release of MechJeb fixes the problem with warping to the SOI transition point from an enclosed SOI to an outer SOI. (i.e., from orbiting Mun to a Kerban orbit) I am still having problems with the return from moon failing to generate an orbit that has a periapsis at the correct distance. It appears to be worse for orbits that are highly inclined from the equatorial orbit. skips

I would like to point out that the pointing specific directions in Smart ASS only constrains the pitch and yaw orientations of the vehicle. The roll is completely unconstrained by the pointing requirement. It is formally correct that forcing one of those pointings should have no affect on the roll orientation or stability. That said it might be useful if Smart ASS also implemented a set of roll constraints. (i.e., inerital, sun-pointing, main-body pointing, ...) real spacecraft often have constraints such as these implemented in the safe-hold programs. skips

@Galane I have to agree with sarbian. I have flown several missions to Eve with no problems landing. The ship had a TWR of approximately 1.6 at the surface of Eve. In the lower atmosphere the terminal velocity was approximately 80 m/sec. Thus it took approximately 8 seconds of full thrust to kill the descent velocity and a distance of approximately 320 meters. MJ started braking between 500 and 400 meters altitude and throttled back to less than full thrust before landing. I have only seen problems similar to the ones that you describe when landing on Kerban with a TWR less than or approximately equal to 1. skips (and yes I was cheating. the ship had essentially infinite fuel, but a reasonable reported delta-V.)

I apologize for being away for so long. My conclusion was the same as yours, but I am going to use your solution rather than mine. skips

I believe that the correct syntax is @PART[Mark2Cockpit] { !INTERNAL[GenericSpace1] }

The problem with assuming an instantaneous burn is that the normal to the orbit is not well defined. At the burn time, the orbit has two orientations. If one assumes that the average of the two normals is the appropriate normal, then the angle that the delta-V makes with the two velocities is equal. By definition, this situation is the definition of an isosceles triangle, which makes the two velocities equal. For the example that I gave earlier (magnitude of the velocity is 10 m/sec and the delta-V is 2 m/sec), the law of cosines gives the rotation as 11.48 degrees. skips