• Content count

  • Joined

  • Last visited

Community Reputation

5 Neutral


  • Rank
    Spacecraft Engineer
  1. 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...
  2. 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...'
  3. 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.
  4. 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!
  5. 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).
  6. [1.3.x] Waypoint Manager [v2.7.0] [2017-05-27]

    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!
  7. [1.3.x] Waypoint Manager [v2.7.0] [2017-05-27]

    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?
  8. Docking port error spam

    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.
  9. [1.3.1] RealChute Parachute Systems v1.4.5 | 30/11/17

    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.
  10. Same problem on my end. Had to drop back to 449, problem disappeared.
  11. 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.
  12. 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
  13. 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...
  14. [1.3.1] RealChute Parachute Systems v1.4.5 | 30/11/17

    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...
  15. 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...