BARCLONE

Galane, I just tried a third lander and the LGAP went nuts again. All three of the landings I've talked about while using dev193 were from a starting orbit of 200 Km. I did notice the following on the third attempt: When the "Pick Target On Map" / "Land At Target" options are chosen, the AP has no problem starting the burn. When the burn gets down to the last 0.4 m/s, the trouble begins. The problem now manifests itself as a rapid swinging back-and-forth of the yaw and pitch controls. This condition locks up the AP to the exclusion of everything else, unless you abort. On the last attempt, I aborted early, and clicked the "Land Somewhere" option. The lander this time smoothed out and started a more controlled decent. When I spotted my second attempt passing under my path, I clicked on it and made it the new landing target. The AP dutifully put the lander into an attitude to slow the horizontal movement to nearly nothing, then began a vertical decent. I let the lander drop for a while, then aborted and went back to "Land Anywhere". The AP maintained a controlled decent all the way to touchdown, with no jitters. I only had 233 m/s out of over 1700 m/s of Dv left, though. This lander has no RCS; it's all torque. At Moho, the TWR is 9.28 at the surface. The torque is only 4.0 in all three axis (axes? axi? What's the plural of "axis"?). Here's a screenshot of the lander I'm using.

A second attempt with a modified lander to Moho has produced an even more bizzare control input condition. The lander is swinging back-and-forth in both pitch and yaw, while the roll is vibrating rapidly. It looks like the lander is being suspended in a rubber band. The Landing AP has completely gone bonkers. I've tried various values of Tf, with no improvement. If anything, changing the Tf only makes it worse. The interesting bit in all of this is, the de-orbit burn starts out OK, but craps out in the last few m/s of the burn. This also occurred with every maneuver node activity from Kerbin to Moho. I've had to kill the maneuver manually and engage Smart A.S.S. with some direction to stop the resulting spin. As an experiment, I aborted the AP and engaged Smart A.S.S in RETR GRADE attitude, and the lander just went into a spasm. The needles on the lower-left of the screen are now all three vibrating rapidly, and the navball is quivering with various data targets flashing on and off. Killing SA and hitting "Land Somewhere" just puts the lander back into another quiver mode. The only positive note in all of this is, it's flying retro-grade. ADDENDUM: The Landing AP must have woke up from its nightmare, because in "Land Somewhere" mode, it actually landed safely. It was quivering all the way down, and I wasn't sure if it was going to recover. The final "heads up" maneuver was just a few meters above the surface (which appeared to be coming up very rapidly). Here's the logfile for this event. I don't know if there's anything valuable in it. I couldn't find any error calls.

Sarbian, Installed dev193, testing the Landing Guidance AP with a little Pathfinder on Moho... Let me try to describe what happened to two landers in a row: Picked the landing location on the map, engaged the AP. The lander goes into the initial de-orbit burn OK, brings the predictor over the target site. During the decent, the AP rotates the lander -NML, and continually fires the engine at a very low throttle notch. This appears to be bringing the final landing position to match the selected position, but the AP is jerking the thrust vector around erratically and this never stabilizes. Lander is otherwise free-falling and is accelerating from gravity. As the targets line up to within a few meters of each other, MechJeb turns the lander PRO-GRADE and shoves the throttle to full until the altitude is less than 3 Km. At Moho, this means the lander is now screaming toward the surface at over 800 m/s. Near the 1 Km altitude, the lander lowers the gear, and flips into a heads-up attitude, but there is no possibility to slow down and the lander hits the ground at better than 600 m/s. Not exactly what I expected... ADDENDUM: Looking now at the KSP.log file... I'm not finding anything in the way of an exception being thrown prior to impact, but exceptions-a-plenty afterward. In fact, about 4/5 of the log file is nothing but a list of error exceptions. However, most of the errors deal with "MechJebModuleThrustController" and "MechJebModuleAttitudeController". Here's a link to the KSP.log file... 2nd ADDENDUM: Just re-installed dev192, and I'm getting the same weird behavior. Looking at the direction "needles" on the bottom-left, it gives the appearance that the yaw and pitch controls are fighting each other. It's a constant back-and-forth action on both directional axis. Could this be some sort of "infinite loop" in the code? One change in my observation earlier. The bad burn is very close to being -RAD instead of PRO-GRADE. The outcome, however, remains the same. SPLAT.

As I mentioned in my post, "there may be other factors" besides MJ. I do think there is a problem within KSP that's at the root of this issue, but I also think there is something within MJ that is (big 50-cent word here) exacerbating the problem. Shutting down the autopilot and re-engaging it quickly seems to clear the problem, so MJ is at least contributing to the error. Locating why it's doing this is probably bigger than trying to explain it. I tried increasing the tolerance setting, and found the problem started showing itself earlier in the tail-off. The problem also shows up during the ascent, when the sustainer gets into the circularization phase. I had a large (5m) launcher start chasing its tail at between 4 and 5 m/s of remaining thrust after changing that tolerance setting to 0.3. I'll give it this, it wasn't as jittery as it normally is, but MJ still tried to dutifully chase the vector around the navball. One interesting thing about all this chasing -- if you watch the apoapsis and periapsis numbers, you'll see MJ is trying to get a near-perfect circle in the orbit. Mine typically come out with about 200-300 meters difference after the chase, so as far as having an odd-shaped orbit, it's not doing that to mine. The orbit is usually very good; it's just annoying to watch every ship chase its tail at the end of (virtually) every burn. I can certainly live with it for now, but visually it's disturbing.

Installed dev192. First observations: Testing a docking with a small one-seat lander in Kerbin orbit, carried under the shroud (ProcFar adapter with conical aeroshroud) just behind the command-service module (Apollo S-IV-B style). At stage separation (shroud flies away in four pieces), I engaged thrusters to put some distance between the two (but less than 10 m). Then I set the "control from here" to the CSM's docking port and the "set as target" to the LM's port. When I engaged the DockingAP, MJ promptly rotated 180, then fired forward thrusters and rammed the two ships together, sending the LM and the still-attached stage tumbling out of control. Will try another mission tomorrow, and put additional distance between the two before engaging the AP.

Just installed dev191. Initial observations: Docking AP seems to be working better now, as far as the approach is concerned. Alignment is good when using stock Clamp-O-Trons. Positioning and approaching is rapid in normal time, and seems to hold a better target lock even in time warp. Nasty issue when docking is complete. MJ wants to burn the RCS for no reason after completing the docking, and after showing the autopilot should already be shut down. When I manually close out the dialog, the RCS shuts off. Rendezvous AP still seems to have an issue (target vector drifts) during the last phases of an engine burn. If I disengage the RendAP quickly when the drift starts, then re-engage it, the drift goes away and the next step in the sequence begins normally. Something is not properly closing out at the end of each phase of a rendezvous, and MJ is getting "vapor lock", or "gimbal lock". There may be other issues at work here, but the clearing of the issue by shutting down the AP, then quickly re-engaging it, points to at least one issue within MJ. The drifting issue also occurs in the Ascent AP, during the last burn-to-apoapsis and during the circularization burn. Probably the same issue as with the RendAP.

FWIW, I don't use any aerodynamic parts on my rockets, like fins or winglets. It's all torque and thrust vectoring.

Sarbian, Something I noticed on the last few tilt-over launch mishaps I've had was a tendency for MJ to hold the turn input a little too long, then try to do a reverse too late to matter. I'm wondering if an adjustment could be made to the slope of the inputs (their aggressiveness). Maybe be a little less aggressive on the start of the turn, but very aggressive in nullifying that input once the turn has started? Perhaps even anticipating the point of nullifying out the input and cutting back before the rocket reaches the turn attitude. I'm guessing this is what MJ should already be doing, but the aggressiveness (or sluggishness) of the inputs might need some tweaking. Also, one suggestion for a new user input control could be a "Start turn at xxx m/s" input box.

Sarbian, just installed dev185, and I'm having a blast landing on Duna as I type this. The landing autopilot is working well, getting the lander to a near-perfect touchdown. The actual target is only a few meters off at most from that selected. My third landing this morning is in the canyon, near the equator. I thought it might create some interesting postcards... Whatever you did to the Tf calculation in the "Attitude Adjustment" is working well. Nearly every launch has been successful. As for those that weren't successful, well, this is Kerbal Space Program, afterall. Nothing more power and more spinning wheel thingies couldn't handle...

The landing gear deploy function works quite well. It triggers the gear at 1 Km above the terrain. I haven't tried the parachute function yet because my crew ships need to punch off the service module before the re-entry begins. I can't do that while the AP is working. As for landing accuracy at Mun or Minmus, I like it. I'm generally within a second or two in any direction of the target coordinates, and more often than not, I'm dead on in at least one of the directions. Landing at KSC is never the same trip twice, however. I generally try to overshoot the center by about 3 minutes and go for a water landing, but still wind up in the hills west of the center.

Update to autostaging problem... Auto-stage works... and it doesn't... Two identical landers, using identical parts, but assembled with different sequences. The first lander is built straight-up as a single unit, starting with a MJ-equipped component and working down to the booster engine. The second has an initial MJ-equipped component used as a base, with the lander constructed separately on it, having its own MJ-equipped component. This lander is then separated into a subassembly for use later on different launchers. The straight-up lander assembly goes through auto-stage without a hitch, punching the carrier stage (sustainer) just before rotation to vertical (I timed out the delta-V in the sustainer tank to run out just before this point in the landing) and finishing the de-orbit burn with the lander's engine. The subassembly lander runs out of delta-V but does not auto-stage. The trigger is not being sent. I have to manually hit the space bar to get the lander to finish. The engine fires up and the landing is otherwise routine, but the staging event has to be done manually every time. The issue has to do with the difference between a "standard" build and a "subassembly" build. I can't see why there should be a difference, as the "subassembly" version still only has one MJ-equipped component, and the rest of the flight goes as it should. Even the ascent AP auto-stages correctly, so the system should work either way. But in the LGAP, the auto-stage isn't occurring.

They'll have to make-do with a shipment of fresh whities and some Lysol spray I'm sending up with the third crew...

Just installed dev183... Auto-warp seems to be broken. I'm having to manually trigger it each time within RendAP. Also, just had another high-speed pass of my station during final burn. My ship was a full 2 Km ahead of the target (station in Mun orbit), and it delayed the speed-match burn for over 5 seconds past the node point. I watched the station zip past at an alarmingly close distance, well within the 200m "desired final distance". I think I actually saw the distance number get inside 75m as the ship passed. My Kerbals aboard the station may have to come home early for underware changes!

My first thought about "safeDistance" was similar to the "keep out box" around the ISS. I thought it might have been used as the "edge" against which the Rendezvous Autopilot measured for its distance-to-target parameter. For #2, perhaps you could simplify it even more -- start at the exact center of the target complex, whether it is the docking port or not, then measure out about 1.5x or 2x the longest dimension of the target as the radius of the sphere. Yes, the sphere would be large. Here's why: For #1, only allow the object actively docking with the target to have "permission" to enter this sphere. The Docking Autopilot can thus ignore the sphere for the most part (it would have permission to enter the sphere) since it is aiming at one specific location, most often a port. The Rendezvous Autopilot needs to absolutely pay attention to the sphere so as not to inadvertently get too close and potentially impact the target. This sphere would have authority over the rendezvous distance value, and could be used as the default value given in the dialog. Regardless of the value put into the dialog box by the player, the RendAP should never try to approach the target closer than the "safeDistance" value.

Curious about some of the data on the Docking Autopilot. I presume the "safeDistance" value is an imaginary "sphere" around the target of the specified distance. What is "targetSize"? Is that the longest linear dimension of the target? How is "safeDistance" calculated?

Observations on Dev181: Tf Auto Tune seems to be working better than in earlier devs. Haven't had any skywriting so far. "Control From Here" issue with Rendezvous Autopilot appears to be fixed. At least, I didn't have to go through the tracking station to regain control of my ship. I could go directly into the Docking Autopilot. Update Nope, still isn't fixed. I just brought a crew ship up to the station, and can't get staging control to dump my sustainer. However, Rendezvous Autopilot overshot my target (large station in Mun orbit) at the end of the event. It was set for 100m, but didn't start the final burn until it was way inside 70m, and passed the station by 40m. The closing rate was over 20 m/s, and I was fortunate that the incoming ship didn't nail the station into oblivion. Docking Autopilot was a lot smoother this time. The movement of the ship into alignment was more fluid, and it seemed to hold the vector into the docking port better, even when time-warping. Autostaging is still borked in the Landing Guidance AP. It doesn't seem to be reading the value of the radiobutton in the Utilities dialog. The Ascent Guidance autostage function works properly, though. Ships of all sorts are trying to "chase their navballs" as they reach the end of their burns, usually in the last 1 m/s. This is a carry-over from quite a few dev builds, and may not be a MJ issue, but it's something I didn't notice in very early builds. The ships behave themselves well when their engines are running above a low tick or two, but if the throttle gets down into the basement regions, they begin to act ugly. The target vector reticle on the nav ball starts drifting around, and MJ tries to follow it dutifully instead of locking down on the original burn vector.

Sarbian, The Landing Guidance autopilot isn't autostaging, even with the Utilities checkbox set. I was able to manually stage. Dev180...

I'm afraid I have to give a similar observation. The Docking Autopilot tonight told me it was "Backing up" at some m/s, but watching the screen said it was trying to pass the target. Starting positions when I engaged the DAP had the target behind the ship, with both vessels in retrograde attitude (target catching up to me). I am also using dev180...

I just tried a new sandbox, and the spacecraft disintegrated at booster separation/sustainer ignition. Twice... The lander had a customized "instrument bay" (a 1.25m bulkhead with MJ and SAS modules installed) at the very top of the stack, and the heavy drill was attached just beneath that. Apparently, there is some issue with attaching stuff on top of the drill. Is there an exhaust port at the top of the drill? Anyway, I moved the drill to the top of the stack, with the instrument bay just under it. I then launched two identical landers without incident, setting them down about 20m from each other. So the problems might just be structural, but that behavior in the other sandbox was utterly bizarre. I've never had landers just "jump" off the ground like a flea before.

If this has been posted before, please direct me to the discussion... I have been having a crazy experience using K0.8.4. I can launch a large drill-equipped ship and make it all the way out to Mun. I get into orbit, but if I change to map view, then back, everything on the ship except the drill has vanished. All of the engine and fuel components still show up in MJ windows, but visually they're gone. If I try to land, the drill will still act as if those components are in place, but at some point the whole thing explodes. If I manage to land, then bring another ship down close to it, when I get the new ship within about 500m, the drill ship suddenly leaps off the surface, all of the non-kethane parts disappear, and the drill unit shoots upward until it reaches about 20km, where it arcs over and free-falls back to the surface. This has now happened on four straights attempts to put this drill ship down on Mun. I do use a texture compressor, XLP, latest MJ dev, and the Visual Enhancements" mod (clouds and lights). Is there a known incompatibility that I'm hitting here?

I had a strange incident the other day with the docking AP. The approach looked good until about 3-4 meters away, then the spacecraft began drifting off to one side. When it was within 1m of the target, MJ realized it wasn't lined up correctly, and it started to back up for another run. Instead of putting plenty of distance between the spacecraft and the target, however, it got into a tight loop of backing up and thrusting forward within that 1m space. MJ never managed to get lined up, it just looped inside that 1m gap.

Both stock and the "enhanced" mod are affected. Rats! That's something I was wondering about -- using the RCS (if available) when the Dv required gets below a certain (user-settable?) value. Using the main engine seems to be over-kill for some of these burns, and depending on the engine, it has to be "pulsed" rapidly to keep from over-burning.

A follow-up to my last post... I was watching the screen during one rendezvous, and saw the time warp indicator (upper left corner) flicker the second arrow briefly, but repeatedly, even though the ship was supposed to be at only time warp 1. Something is tickling the warp when it shouldn't...

Sarbian or Codepoet -- I'm using dev167... Minor technical issues to ask about. I'm experiencing a lot of nav ball target reticle jittering as a burn reaches the end, usually in the last 0.5 m/s. In the last 0.2 m/s of the burn, the reticle begins moving off-center (still shaking like a hairless dog) and the ship dutifully tries to follow it around. The other issue is when I'm closing in on a rendezvous target and switch to the docking autopilot, I cannot do a "control from here" when right-clicking the docking port, nor can I do a "set as target" on the destination's docking port. It is acting as if the ship is still in time warp, even though the warp indicator's all say I'm in normal time. I can usually clear this if I go to the Space Center, go into the Tracking Station, and select the ship to "fly". Any ideas?

Tiberion, Up until a few days ago, my installation was on Linux Mint 15, and NovaPunch2 (v2.03a) was loading fine under KSP 0.23. Within the last couple of days I upgraded to LM16 and had to re-install everything in my KSP folders. NovaPunch2 now consistently crashes during the boot sequence. It's the only one that seems to fail, BTW. I've tried breaking out those parts from the pack that I need most (engines), but it continues to crash. My system: OS: Linux 3.11.0-12-generic LinuxMint 16 64bit CPU: AMD Phenom 9550 Quad-Core Processor (4) RAM: 3952 GPU: GeForce GT 520/PCIe/SSE2 (1024MB) SM: 30 (OpenGL 4.3 [4.3.0 NVIDIA 319.60]) Not high-end, but not shabby either... The log from the last boot attempt shows the engine texture maps appear to have loaded (early in the boot sequence), but as it progressed, the boot just stopped and KSP shut down. For reference, neither of the 32-bit executables of KSP will run on the newer kernel, and even the 64-bit launcher crashes when you hit "PLAY". Am I looking at an "out-of-memory" issue (4 GB of RAM), or is this a 32-bit issue on a 64-bit machine? Suggestions? UPDATE: Looks like I hit the memory barrier. KAS was starting to do the same to me. I saw BolderCo's TextureCompressor plug-in, tried it, and all of the mods I want to use loaded without crashing. Moral of the story: You can't have everything, unless it's in moderation...