BARCLONE

Mentioned before -- Dev 223... Testing a crew pod to my station... safeDistance = 20.55 targetSize = 14.00 Oh, boy! The ship arrived to within 100m of the station, and MJ fired the RCS briefly to begin moving the ship away until it was fully 100.5 m off the side. It gave the appearance of locking up, and I almost wrote it up that way. What it didn't do immediately was rotate the ship to align with the docking port, and this is what was throwing me off before. But once outside the 100m sphere, the ship suddenly rotated correctly, and began backing up to position itself at the port end of the station. I'm watching the docking maneuver as I type this. It's like watching grass grow, or like watching the last 15 minutes of the Falcon launch earlier today with the sound off... The crew ship is gradually making its way nearer to the station, and it's on the correct end. It took several minutes, but the ship is now within 15m of the port and smoothly gliding into alignment. As the alignment points straight into the port, the ship is now moving forward for the connection. DONE! My ship is now docked and things look stable. While I'll need to conduct more tests, I think what was throwing me off was the delay in aligning the ship to the docking port. I'm so used to MJ doing that in the other APs that not seeing it happen immediately here made me think something had broken. So, everyone might just need to watch their numbers on the AP dialog box before giving up. It might "correct" itself before you realize what's happening.

I'm using the latest, 223. It came out Wednesday.

...And just conducted a 4th test flight, this time moving the probe 100m off to one side to mimic the approach of a ship via RendAP before engaging the DAP. The DAP worked just as it should, and now I think I've verified what Sarbian said about his tests. I'm going to try a flight with a three-Kerbal ship to a station positioned at 300 km, to see if I get different results.

OK, I just went 3-for-3 with a small test probe design in LKO. One flight started from the opposite end of the target port, one from the front, and one from the side. The docking AP made the proper moves to re-position the probe for the line-up and brought the two craft together, although a bit herky-jerky. The Tf setting needs to be adjusted to a minimum of 0.3 to keep the craft steady. Anything smaller and the craft cannot point its docking port straight into the target; it circles around the outer edge due to torque (on my probe, anyway). Sarbian, this suggests you really do need to test with a larger, heavier ship to see the effects.

In principle, the number of mods a user has shouldn't change the way MJ operates. Where problems occur is when two mods change some critical common game variable in ways that are incompatible with each other. In reality, though, I can see the possibility of the platform being run on (Mac, Linux, or Windows) having slight changes in the way code runs between them. And being one who has seen the "dark sides" of MJ's docking AP, landing AP, rendezvous AP, and ascent AP, I can also understand Sarbian's frustration when his installation runs perfectly and ours doesn't. I'll state here that I don't use the AR-202 part on anything. I add the MODULE to a number of my parts in their CFG files to both reduce parts count, and to give some of my stages the ability to de-orbit themselves after putting a payload into orbit. This has worked out well most of the time. Also, there were builds of MJ where the docking AP worked exceptionally well, if perhaps a bit fuel-inefficient with RCS. I'll take fuel-inefficient over non-working any day. I use almost 30 mods in my installation, and I've had good results in the past with MJ's AP modules. Right now, I'm having great results with the ascent AP, especially after modifying the thrust vector range of some critical booster engines that weren't providing enough corrective vectoring. That was the cause of some wild aerial acrobatics with a few heavier designs. Now, I'm routinely putting rockets into 200 km orbit with a starting mass of 1045 T, with ultimate destinations of Moho and Eeloo. I think this already surpasses the capabilities of the "new" parts from the ARM kit, and MJ handles them without further trouble. BTW, Sarbian, I'm using the "Auto Tf tune" feature doing this, just limiting the top-end range value to 0.3, and leaving everything else at default settings. At least in Kerbin orbit, the rendezvous AP works in getting me to the target without crashing into it. I can even re-engage the AP to bring my chase ship in closer if I need to. The only issue I have with this AP currently is the four-step burn sequence (burn to phasing orbit, circularization, burn to target, circularization). But this is a minor thing compared to the problem with docking. Sarbian knows I've had issues with the landing AP for some time, and in a similar way to his frustrations with the docking AP, the LGAP works virtually perfect for me at Mun and Minmus, but fails completely when the very same lander design reaches Moho. If I knew there were temperature variables changing the way equipment behaves, I might understand. This may also be a FAR issue that I'm not recognizing. What I do know is, previous LGAP modules worked perfectly at Moho, but the current code doesn't. On my installation, the docking AP seemed to be working reasonably well about 70 or 80 builds back (somewhere between build 150 and 170), but started to degrade thereafter. There was a series of builds where the response was quick and the accuracy was within acceptable reason. I'll try Sarbian's test of a small probe in LKO to see what happens. Sarbian, I'd suggest testing a much larger craft to see if there are any issues with mass and/or balance. It's going to take a lot of testing on a variety of designs before some of these bugs are exterminated. A typical ship would be a Mk 1-2 3-seat command pod with a service module (good ole Apollo-style CSM) as a test vehicle. This would represent something more "common" among all of us, since we have an absolute need to take our Kerbals to stations or other ships. See if this produces the anomalies we're experiencing. Also try embedding the MJ MODULE into these test pods instead of using the AR-202. There may be problems with embedding the module as opposed to using the part. Don't know, don't think there should be, but could be possible...

Sarbian, Minor questions: Why does MechJeb insist on burning to a higher-altitude phasing orbit than the target when the target is already in a higher orbit? Why can't MJ be a bit more "fuel conservative" and just wait for a transfer node to take the chase ship in two burns (transfer up to target, circularization) instead of four (transfer up to phasing, circularization, transfer down to target, circularization)? Major issue: Now using Dev 223. If I'm approaching from the side of the target, the docking AP doesn't even want to get started. It burns the RCS briefly, then locks up. If I manually maneuver directly in line with the docking port of the target, MJ immediately starts firing the RCS to move the ship past the target instead of backing up. I'm getting several of these in the log: I also found one of these near the end of the log: ADDENDUM: Although this shouldn't be an issue, I'm running Linux Mint 16, 64-bit. Don't think there should be any execution differences between platforms, but there might be...

Too many to list easily... I'll try 217 and see if it persists.

Dev216, KSP 23.5... Sorry to say, the LGAP is still wonky. Just had two Pathfinders slam into Moho at 500 m/s while using "Land Somewhere". MJ started the final burn much too late to be effective. When using "Land At Target", the ship starts oscillating +NML to -NML (around the RAD axis) when the delta-V remaining in the de-orbit burn reaches 0.1 m/s, burning in brief bursts as the ship crosses retro-grade, finally giving up and going into a spin around the RAD axis which it never seems to come out of. The ship just locks up with that 0.1 m/s remaining. Interestingly, this same lander design functions perfectly with MJ at Mun and Minmus. It also appears to work properly at Duna. The thought has occurred to me, is MJ being affected by FAR and/or thermal extremes here at Moho? This error message is repeating itself throughout the logfile ad nauseum : The first instance I see comes within 200 ms of the launch, then proceeds to fill the remainder of the log with only a few entries from other items. Spotted this error at multiple points in the flight (post-separation from carrier, pre-impact): Significance?

Wouldn't that include 2.5m joints? The rocket in my two screenshots is a 2.5m diameter vehicle.

e-dog, I just replaced KJR, Kethane, and ExLP, so I'm up-to-date with those... The structural fairings are still not releasing. Staging is recorded in the logfile without error notes, and all indications are the stage should have separated. That's what I gather from these logfile entries: IIRC, the new build of KSP was supposed to "improve" joints by making them stronger. These sure are acting like they're "welded" to the upper stage. Full stack in the VAB of my Columbia-Class crew ship Cut-away view of the stage separation area

Yes, that's what I was trying to use. I'll try to set up some screenshots. I am using KJR, so I'll go check for an update. Thanks!

e-dog, Version 2.4.4 The structural (conic) fairing has an issue with 0.23.5 (ARM). I had two launch failures back-to-back where the fairings would not release at the top. The stages would not separate, and remained firmly attached even as the next stage's engine was blasting away. The aerodynamic shroud sections appear to work fine. ADDENDUM: Hundreds of instances of this line appear in the logfile:

Dev197 and ARM 23.5... Is it just my imagination (running away with me), or does the new release feel a bit... less jerky? Less "sticky"? Just landed a Pathfinder on Mun as a test; only my forgetting to turn SA off before engaging the LGAP kept it from being a "picture perfect, textbook" landing. SA tried to flip the lander with torque because I still had it set to "PRO GRADE" instead of "OFF". I had to quickly hit "RAD+" to get it upright before the solar panels were ripped off... Dev197 looks good so far, Sarbian. One test, of course, isn't enough to confirm anything, but this first landing went smoothly enough to try a Moho mission. One heads up to everyone: 23.5 breaks several mods. Many appear to have been addressed by their authors, but if you're like me and you've been using the older ones 'cause they ain't broke yet, be ready to update at least a few. Besides MechJeb, I had to replace KAS and Procedural Fairings, which are two of my most-used mods. ADDENDUM: Ooops!

Build 194... Just pulled two completely successful flights out of the hat using the same hardware that had been giving me fits earlier. What was different? Something completely overlooked and not considered, but apparently running around in my squirrel cage of a head. It has to do with the names of the ship and the lander. MechJeb doesn't like two ships having the same name, nor does it like having one ship have the same name as a piece of debris. It seems that MechJeb could not distinguish between my crew ship and my lander, or between my crew ship and one (or more) of the aeroshroud panels that get blown off to expose the lander. What happens is this: When you build the ship that I'm using, it launches as one ship under one name. When you separate the pieces, there is enough similarity between the "lander", the "ship", and "debris" that MechJeb mistakes one for another. This is what seems to have happened with an earlier test, where the command pod "exploded" in the background. Looking at the log, what it was described as doing was hitting the surface of Mun. I was at the time focused on the lander, going through the landing sequence. MechJeb saw the names of both ships as being the same, and so the command ship plunged along with the lander. The change I tried on both of these successful missions was to rename the command ship immediately upon separation from the carrier stage, then switch over to the lander and rename it something totally different. When the command ship docks with the lander, both ships are recognized by the command ship name, but now the lander has its own identity after it separates from the command ship to go down to the surface. MechJeb liked the difference. and didn't summarily clobber the command ship, leaving it positioned comfortably in orbit. Wild, ain't it? Screenshots of my wundership: Full Stack in VAB Spacecraft portion, all buttoned up Spacecraft showing some leg (under the shroud, my lander) ADDENDUM: Sarbian just posted dev195, so I'll play with it tomorrow.

OK, now this is really weird... Using Dev194... Here's the interpretation: I'm carrying my lander Apollo-style inside a ProcFar adapter shroud. The lander has its own decoupler attaching it to the PF adapter base. From launch through to crew ship docking, and even decoupling from the adapter, everything appears to be working without issue. Time comes to separate the lander from the crew ship, so far so good. As soon as the lander gets out of the crew ship's SOI, the crew ship explodes. I didn't see the explosion, but I heard it and knew something nasty occurred. Curiously, the lander then went down to the surface (Mun) without a hitch, landed perfectly on target, and I was able to get back to KSP (game pause). The game did not crash internally to the point of instability. Thoughts?

Dev194 -- again... Game crashes internally such that my command ship jumps 700 km away from the lander in one instant of time. Same orbit, just 700 km away... What I'm getting is "Null Reference Exception"... 27 MB worth in the logfile... No immediate indication of where the crash is happening; the logfile doesn't specify which module the crash is starting from. Too tired tonight to go another round.

Sarbian, In testing the 194 dev again, my lander's MJ unit swung the ship immediately on decouple and broke off a solar panel. Could you introduce a concept of "master-slave" into the MJ units, so that one ship always has "absolute top-dog command" and the others have a subordinate position? Perhaps also have a radio button to tell all subordinates to "Free Drift upon separation", or "Kill rotation upon separation", so that they hold a steady attitude after a decoupling occurs...

And another possible incompatibility to report... I backdated to dev192 to see if the crashing problem could be duplicated, and it was. However, I remembered something from a much earlier problem with NovaPunch components. As a test, I redesigned my lander -- I had been using the Thor decent module for the lander, which is an all-in-one tank and engine combination -- using a simple stretchy tank and a normal engine instead. The problem went away. I had some problems earlier with the NovaPunch Odin command pod. It may be just graphics-related, but the result was a game instability. If you are having similar problems to what I've been describing the last few days, check to see if you are using any NP parts. I'm going to re-install 194 to test this theory...

I backdated to dev193, and started a new sandbox... The logfile starts throwing exceptions with the Docking AP at time reference 12:18:28:256. The game goes unstable at this point, but visually continues without giving the appearance of anything wrong. I cannot get back to KSC. I'll try dropping back to an earlier dev and see where or if it crashes...

Dev194... The attached logfile shows MechJeb throwing exceptions beginning around 08:23:53:949. The game has already crashed at this point, and you cannot get back to the space center. You can only kill the game.

Dev194... Serious problems. RendAP is borked in the final phases of a rendezvous, and I'm getting tons of exceptions in the logfile . Here's what I observe: In Kerbin orbit, my crew ships seem to behave well. But out at Mun, my lander acts ugly when returning to a rendezvous with the crew ship. The lander reaches my 200 km orbit with no issue, and handles the phasing orbit (and plane matching) OK. The initial transfer burn down to the crew ship appears to work, but when the AP enters the velocity matching part of the maneuver, it undershoots the target. When trying to do the last (short) burns to bring the lander close to the target, it starts a repeated series of +NML and -NML twists and turns, burning about 1 m/s each time. It never stops doing this, and steadily gets farther away from the target instead of closer. The lander never points toward the target, but always +NML and -NML.

Dev194... Landings on Mun and Kerbin seem to work fine, no glitching or shaking in the landing sequence. However, every time I try to "plant the flag", the game crashes. Whoever is on EVA, the game goes into ultra-slow-motion and the Kerbal no longer has any response to the direction keys. I can't even get the text entry screen up to say what I want on the flag plaque. Haven't tried a landing anywhere else yet. Doesn't seem to be any point in going out farther when the game crashes like this. I'll try creating a new sandbox and see if that clears the cobwebs a bit.

Additional observations, re: dev189-193... Just flew a quad-path mission to Moho to see if dev189 had the shakes. Sadly, yes it does. So the problem (whatever it is) is pre-189 in origin. Here's what I watched, though: When using the LGAP, selecting "Pick Target On Map" / "Land At Target", the event is well-behaved until the de-orbit burn gets down to 0.2 m/s (there's that low-ball value again). At that point, the guidance goes crazy and never seems to find a vector that properly allows the lander to finish the burn. The "pitch" and "yaw" needles oscillate back and forth in very wide swings (at least half the meter's range). If I abort the landing at this point, switch to SA, and engage RETR GRADE, then give the throttle a slight nudge, I can adjust the path to something close enough to the target to call it OK. I then turn SA off and re-engage the LGAP to "Land Somewhere", and LGAP takes the lander beautifully down the path to an altitude of about 15-20 meters above terrain, then flips heads-up to complete a soft touchdown. "Land Somewhere" works really well, if a bit on the nerve-wracking side of life as the terrain gets very close very quickly. Only quirk I can speak of in the "Land Somewhere" routine is, it never engages Time Warp during the free-fall from orbit. I found I could engage it manually down to about 25 Km above the (Moho) terrain, then drop back to normal time, and LGAP picks up right where it should. Noticed you posted dev194 while I was doing all this. I'll install it and see what's changed...

Understand fully, Sarbian. Life isn't just about Kerbals... Something to look at when you get time -- I just had two perfect landings on Mun with my Pathfinder, using dev189. I dropped back to something I knew I had experienced good results from. I'll check out how it works on Moho tomorrow, so I'm not saying 189 was completely "right". But those jitter bugs I described with 193 seem to have gotten introduced shortly thereafter... I just thought about something else, concerning the "thrust vector drift" that has plagued me and a few others at the tail-off of a maneuver node burn. It bugged me that I see this drift in every node, but not at the end of the "ascent to apoapsis" burn of the ascent AP. There is no thrust vector on the nav ball during that portion of the ascent, but there is when the AP goes into circularization mode. The ascent AP borrows code from the maneuver nodes routines to do the circularization, doesn't it? The bug is common to every maneuver, and obviously it handles the tail-off differently than the ascent AP does in the apoapsis portion of the flight. How does MJ compute vectors in that part of the code? The nodes, on the other hand, do not compute the vector, but instead use the value provided by (whatever feeds) the nav ball code. What if the nodes captured that vector internally before beginning the burn, then use that captured value through the entire burn, ignoring any changes made by the nav ball code, especially near the end of the burn? The nodes would consider any later nav ball value changes as "corrupted" once the burn starts, and disregard anything it provides until the start of the next node.

Using dev193. I tried a landing at KSC with one of my "standard Kerbal ships" (a Mk 1-2 command pod) and got the same jittery needles as soon as the de-orbit burn tailed off. So, the problem is not limited to the Moho SOI, nor is it limited to small, quick-responding craft like my Pathfinders.