BARCLONE

Sarbian, I keep having this oddball error show up when I use the "Surface Longitude At Apsis" module. It doesn't like being given certain D-M-S values, like 72 0 0 (above KSC). It will throw an error if the seconds are at 0, but if I change the seconds by 1, then it works. FWIW, I've tried a full three-digit combination (like 072 000 000) to make sure I didn't have any extraneous invalid characters in the blocks, but it still complains. Looking at the Player log, I could only find these entries: Uploading Crash Report ArgumentException: Brent's rootfinding method: guess does not bracket the root at MuMech.Brent.Root (MuMech.BrentFun f, System.Double a, System.Double b, System.Double rtol, System.Double& x, System.Double& y, System.Object o, System.Int32 maxiter, System.Int32 sign) [0x00057] in <426b00c02efb4181b92f09b7d33dfbfa>:0 at MuMech.OrbitalManeuverCalculator.DeltaVForSemiMajorAxis (Orbit o, System.Double UT, System.Double newSMA) [0x000a6] in <426b00c02efb4181b92f09b7d33dfbfa>:0 at MuMech.OrbitalManeuverCalculator.DeltaVToShiftNodeLongitude (Orbit o, System.Double UT, System.Double newNodeLong) [0x000df] in <426b00c02efb4181b92f09b7d33dfbfa>:0 at MuMech.OperationLongitude.MakeNodesImpl (Orbit o, System.Double universalTime, MuMech.MechJebModuleTargetController target) [0x0001c] in <426b00c02efb4181b92f09b7d33dfbfa>:0 at MuMech.Operation.MakeNodes (Orbit o, System.Double universalTime, MuMech.MechJebModuleTargetController target) [0x0000b] in <426b00c02efb4181b92f09b7d33dfbfa>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) MuMech.Operation:MakeNodes(Orbit, Double, MechJebModuleTargetController) MuMech.MechJebModuleManeuverPlanner:WindowGUI(Int32) MuMech.DisplayModule:ProfiledWindowGUI(Int32) UnityEngine.LayoutedWindow:DoWindow(Int32) UnityEngine.GUI:CallWindowDelegate(WindowFunction, Int32, Int32, GUISkin, Int32, Single, Single, GUIStyle) (Filename: <426b00c02efb4181b92f09b7d33dfbfa> Line: 0) ArgumentException: Brent's rootfinding method: guess does not bracket the root at MuMech.Brent.Root (MuMech.BrentFun f, System.Double a, System.Double b, System.Double rtol, System.Double& x, System.Double& y, System.Object o, System.Int32 maxiter, System.Int32 sign) [0x00057] in <426b00c02efb4181b92f09b7d33dfbfa>:0 at MuMech.OrbitalManeuverCalculator.DeltaVForSemiMajorAxis (Orbit o, System.Double UT, System.Double newSMA) [0x000a6] in <426b00c02efb4181b92f09b7d33dfbfa>:0 at MuMech.OrbitalManeuverCalculator.DeltaVToShiftNodeLongitude (Orbit o, System.Double UT, System.Double newNodeLong) [0x000df] in <426b00c02efb4181b92f09b7d33dfbfa>:0 at MuMech.OperationLongitude.MakeNodesImpl (Orbit o, System.Double universalTime, MuMech.MechJebModuleTargetController target) [0x0001c] in <426b00c02efb4181b92f09b7d33dfbfa>:0 at MuMech.Operation.MakeNodes (Orbit o, System.Double universalTime, MuMech.MechJebModuleTargetController target) [0x0000b] in <426b00c02efb4181b92f09b7d33dfbfa>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) MuMech.Operation:MakeNodes(Orbit, Double, MechJebModuleTargetController) MuMech.MechJebModuleManeuverPlanner:WindowGUI(Int32) MuMech.DisplayModule:ProfiledWindowGUI(Int32) UnityEngine.LayoutedWindow:DoWindow(Int32) UnityEngine.GUI:CallWindowDelegate(WindowFunction, Int32, Int32, GUISkin, Int32, Single, Single, GUIStyle) (Filename: <426b00c02efb4181b92f09b7d33dfbfa> Line: 0) ArgumentException: Brent's rootfinding method: guess does not bracket the root at MuMech.Brent.Root (MuMech.BrentFun f, System.Double a, System.Double b, System.Double rtol, System.Double& x, System.Double& y, System.Object o, System.Int32 maxiter, System.Int32 sign) [0x00057] in <426b00c02efb4181b92f09b7d33dfbfa>:0 at MuMech.OrbitalManeuverCalculator.DeltaVForSemiMajorAxis (Orbit o, System.Double UT, System.Double newSMA) [0x000a6] in <426b00c02efb4181b92f09b7d33dfbfa>:0 at MuMech.OrbitalManeuverCalculator.DeltaVToShiftNodeLongitude (Orbit o, System.Double UT, System.Double newNodeLong) [0x000df] in <426b00c02efb4181b92f09b7d33dfbfa>:0 at MuMech.OperationLongitude.MakeNodesImpl (Orbit o, System.Double universalTime, MuMech.MechJebModuleTargetController target) [0x0001c] in <426b00c02efb4181b92f09b7d33dfbfa>:0 at MuMech.Operation.MakeNodes (Orbit o, System.Double universalTime, MuMech.MechJebModuleTargetController target) [0x0000b] in <426b00c02efb4181b92f09b7d33dfbfa>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) MuMech.Operation:MakeNodes(Orbit, Double, MechJebModuleTargetController) MuMech.MechJebModuleManeuverPlanner:WindowGUI(Int32) MuMech.DisplayModule:ProfiledWindowGUI(Int32) UnityEngine.LayoutedWindow:DoWindow(Int32) UnityEngine.GUI:CallWindowDelegate(WindowFunction, Int32, Int32, GUISkin, Int32, Single, Single, GUIStyle) (Filename: <426b00c02efb4181b92f09b7d33dfbfa> Line: 0) KSP.log has nothing mentioning MJ or MuMech. It's not crashing the game, but it is annoying. Seems to be a bit random, too. The closer I am in the orbit to the target longitude, the more likely it is to trigger an error. I've noticed this condition for several Dev releases.

DL'd your 2.8.0 this morning, will try it out later... As for the LGAP issue, my working work-around is to set a (Waypoint Manager) waypoint first, then just use the Lat/Lon coordinates to set the landing target. That way I have something to aim for. Gets very close, about the same as picking the target through LGAP normally.

For Chrome users: Right-click the link to Sarbian's page, open in a new incognito window, click "advanced", then at the bottom of the paragraph click the link which starts "proceed to..."

Sarbian, See if these links get those files correctly. First time I've used this service (DataFileHost). KSP.log player.log Screenshot Screenshot

Sarbian, I just installed 794, and ran another simulation. Same results. I'm trying to get you a file upload with a couple of screenshots showing what I see on my screen, plus the KSP.log and player.log texts. Honestly, looking through those files isn't what it used to be. I don't see anything mentioning the flight events like I used to in either file. Both are spammed with hundreds (if not thousands) of messages about a missing "KSPParticleEmitter.pe" file. If there's anything related to MJ in that mess, I didn't see it.

Sarbian, Using 793 with 1.4.1, on Linux, seeing a minor cosmetic issue with the LGAP. The target indicator isn't showing up when you try to select a landing location on the map, nor is the basic trajectory path. LGAP functions correctly, as far as the landing itself is concerned. Just the indicators in map mode not showing up.

I'll confirm the fix worked on my Linux machine. The landing was, indeed, very close to the target. Closer than in previous builds. I use NavHud so I can see things, and the two indicators remained aligned one-over-the-other right up until the 500m horizontal-motion-kill point. Very nice! I had no issues with the warp this time. Even picking a landing target that forced one additional complete orbit performed without a hitch. Only hiccup I see, and I've seen it now for many builds, is the gear not extending correctly. Not a show stopper, though...

Sarbian posted: The new landing bug from 1.3.1 should be fixed in the dev build. Build #745. Well... yes and no... It's not twisting around looking for the correct vector like it was before. Now, it just pops into warp to get to the plane change location, and never pops out again. 'Round-n-round she goes, when she stops, nobody knows...'

Model Rocketry, CW. The smell of black powder and talc on the parachutes. Estes and Centuri were the #1 and #2 kit companies in the 1960's and '70s, and when I got back into MR around 2003 or so, I got serious about designing my own birds. Built quite a few of them, too. It's another reason I love KSP, and BDDB parts have that same "feel" to them as I had building real flying stuff.

These parts remind me of the differences between Estes tubes and Centuri tubes. While I loved Estes, I came to appreciate the additional sizes offered by "the other guy". These BDDB parts give me that same W&F feeling... Thanks, CobaltWolf!

Bullets #4 and #5 have been problems for a number of builds now. Bullet #1 has just started showing up for me in the last two builds, and #2 in the current build. Just started using KSP 1.3.1, also... I've seen another time-warp issue for several builds where the LGAP goes into warp, immediately pops out, does a calculation, pops into warp, immediately pops out, ad nauseum through almost the entire descent. This seems to be more pronounced when the entry angle is shallow, from a low altitude (like 30 km above the Mun or Minmus...). I run on a linux build, BTW (LM 18.2, Kernel 4.11, AMD A10-7700K).

Nightingale, That was beautiful! I just tried it out with a triple-lander contract and they all touched down within a few meters of their waypoints, even without RCS! I've been needing this conversion for a long time! Thanks so very much!

Nightingale, I've been using this mod for some time, love it for custom waypoints! I see that the issue of coordinate conversions and integration to MechJeb has been mentioned already... Perhaps an easier solution to the problem might be a drop-down format list where the user can choose which format to view the coordinates in. Have waypoint coordinates show up in both the main GUI and in the editing windows. I like to use WM to set up landing grids for off-planet bases, and I use MechJeb because I'm a lousy pilot... It is very frustrating to have to do manual conversions from the decimal format used by WM to the DegMinSec format used in MJ. Even with a spreadsheet running a conversion program, it doesn't always come out correctly. Would it be possible to incorporate such a built-in converter routine into WM?

Uhh, nope. The problem still exists in 1.0.2... Logfile Linky Don't know if this is a stock issue, or a MKS issue. The ship in question is a lander using a couple of MKS base modules and four MKS docking ports.

I had this problem as well, although I did not have this converter installed. I had ATM-Aggressive installed, and when I dropped it out of the list, the RC icon returned.

Same problem on my end. Had to drop back to 449, problem disappeared.

Sarbian, Running 449 now. That fix did the job! Thanks! I landed a Kerbalship about 10m from one of the MJ Pods after setting it as a target, then changing the landing coordinates by a few seconds each direction. The floating blue target in map mode worked correctly, too. Still experiencing the post-landing HDD craziness, but I'm beginning to think it's a Unity issue more than a game or mod issue now. The KSP.log file actually ended on a NRE from Unity. Annoying, to say the least.

Sarbian (or anyone familiar with this), Dev 447... Mun landing... LGAP using "Land At Target" over-burns the de-orbit to a near vertical "suicide" drop that is nowhere near the desired target. I used the MJ Pod for the test, trying to keep the parts count as low as possible. When the de-orbit burn is completed, the pod starts "orbiting" around its Z-axis, burning the engines in spurts but never aligning to the retrograde attitude. After disengaging the LGAP and correcting the trajectory manually, I engaged "Land Somewhere" and the pod correctly followed the path all the way to a safe landing. Did the test twice with the same results. On the positive side, the crazy HDD activity issue seems to have disappeared with 447. LOGFILES HERE

Sarbian, LGAP: I'm seeing a problem in build 444, where MJ is spamming the logs. The effect of spamming on my machine is to drag the whole machine down to a point where it cannot respond to other requests for CPU time. There is a long period of HDD access, sometimes lasting for many minutes. The point in the game where this occurs is when some ship/probe/lander touches down on the surface of any other planet or moon. I've seen similar behavior throughout the 0.90 lifetime as well, but could not immediately connect it to MJ. Here's a link to my most-recent log files. The "NoMJ" files are with the exact same mod list, but without MJ: FOLDER LINKY Linux Mint 17.1, 64-bit, using the 64-bit executable of KSP. As for the landing approach itself, the landing sequence appears nominal on non-atmosphere bodies like Mun and Minmus. Landings on Kerbin are routinely non-nominal...

Chris (or anyone), I may just be missing it, but isn't there a setting where the chutes can be ARMED in staging, rather than DEPLOYED? Or is this a capability of the stock chutes only? It's very handy to have the chutes go armed at pod separation from a service module (staging trigger of a decoupler...) rather than having to do it manually, or set up an action group...

That was it. I cleaned out the munged files, deleted the appcache, and DL'd it again. Everything shows up now. Lesson learned: Always clean out the old junk and kill the appcache before grabbing the freshest copy...

The download via Steam installed and loads, but none of the parts are showing up in the VAB or SPH. Logs are showing exceptions from the git-go. From the KSP log: From the PLAYER log:

Sarbian, Just installed #428. Minor issue -- on the Delta-V stats display, the Atmos dV and time values are the same as the Vac dV and time values.

Sarbian, Is there a possible way for the LGAP to grab the coordinates of a contract landing target? As in contracts that want surface measurements of temperature and seismic activity?

Claw, I'm running 0.90 on a 64-bit Linux Mint 17.1 machine... Installed your (latest) BugFixes, and I'm still getting the "sticky pad" problem. It does appear to involve a random combination of parts, for sure. The work-around of using a girder and stack separator/decoupler still works, though.