HansAcker

It does (works for me :). Being MechJeb, you need to check what it's been told to do. The "To Target" button adds a waypoint at the target CoM with default values. Make sure that the radius is large enough to lie outside the structure and the target is not obstructed. MJ will stop (or at least try to) if the first speed value (speed at waypoint) is 0. The second speed value is the maximum speed on the way (or whatever is set in the speed control option if it's 0). Watch the "Target Speed" in the rover window: To get to a docking port on the other side of a craft, it would try to drive in a straight line. The docking autopilot does consider the vessel bounds, indeed, but also does not see anything else flying around.

One simple thing I can imagine: Your craft doesn't include a MechJeb-enabled command pod or probe core. In that case, the MJ menu and button don't show in the editor (or flight scene for that matter). MJ also has settings to hide the icon and menu but that probably would affect all scenes. Deleting/Moving the config in GameData/MechJeb2/Plugins/PluginData/MechJeb2/*.cfg should fix that in any case. If that doesn't work, please upload a log file somewhere (e.g. Dropbox) and link it here.

Does it look like the screenshots here: https://bugs.kerbalspaceprogram.com/issues/25992 ? If that is the case, the "Scatterer" mod is supposed to have implemented a workaround for it: https://bugs.kerbalspaceprogram.com/issues/24995

I used the light variant CommNet Visualisation for some time before switching to CommNet Constellation. Its main feature is the additional "show only active connections" option that cuts down on the number of links displayed. I use CommNet Constellation with Kerbalism and the constellations still work. Kerbalism's data rate calculation do not take disabled antennas and multiple paths into account but that could be worked around.

A NullReference exception in the Update loop can probably interfere with GUI responsiveness. I looked at it again and could only reproduce it at the first scene of a new career game, where "currentContract" is null in the GUI Window. It does not happen anymore when I reload the same game. That's probably got nothing to do with the KSP version. Apart from that little bug, I have not experienced any problems in 1.10.1. @DMagic I see there's a null check in the function that allows a null contract on the records page but later on currentContract is referenced unprotected. Is there any special way to access these contracts or is that really just a quirk of starting a new game? For what's it worth, I fixed it locally by adding a check around the last GUI section:

Picking up the root part has the same effect. My "trick" is to try and pick up the craft without lateral movement and then use only the scroll wheel or Page Up/Down keys.

If need be, I press "B", then shift-click the craft and move it downwards into the floor (I usually use this to check wheels for ground clearance, not working at the top of the craft). For detail work on outriggers, I use "WASD Editor Camera" to move around more freely. I can't complain, it works for me. What happens? A quiet forum thread may just be an indication that the mod works without problems

I can confirm that this mod mostly works in 1.10.1, however. The globe icon is buggy, indeed, but the spam stops as soon as I close the window or change the scene. I can't say I even noticed the globe button before

Looks like it. The stack overflow already happens when the function is entered, a Debug.Log call at the start of the function does not log anything. It could be a quirk of Unity on this particular Linux distribution (Linux Mint "Serena" is already outdated a bit). I'll run tests on a more recent distribution. Everything works fine under Windows 10.

I was looking into an issue with the ShipEffects sound mod. On some launches, one of the sound effects would play the wrong clip (e.g. a decoupler sound) instead of the mod-provided sound. Additional logging showed that the first AudioSource component the mod attaches to a vessel's gameObject sometimes got its audio clip changed on launch. "Using GameObject.GetComponent will return the first component that is found and the order is undefined." - So I *guess* KSP does GetComponent<AudioSource>() somewhere and re-uses the returned component for the vessel's launch sound effect. Does that sound like a plausible cause or am I missing something? Here's a reduced variation of what ShipEffects does: It adds AudioSource(s) to the active vessel's gameObject and logs a line when its clip name changes. Various engines cause the audio source to be changed on rollout from the VAB, e.g.: [LOG] AudioTest: source1 changed: Thoroughbred:sound_rocket_hard A tentative workaround is to create a sacrifical, unused AudioSource component but there's the "the order is undefined" of getComponent() to consider. It could as well pick a different component frorm the first one. Should the mod create a new GameObject, attach it to the vessel and add the audio components to that child? Would that protect them from takeover and still play the sound? (I'll give it a try but didn't have time left to tests it right now) Does it warrant a bug report?

Floppiness can be countered in part by using moar power and locking joints when not in motion. Robotic parts seldomly keep their assigned positions over time and will probably drift apart:

You can try to put Breaking Ground grip pads onto custom landing gear. I'm not sure if the would attach to the end of a normal landing strut: https://wiki.kerbalspaceprogram.com/wiki/GP-004_Grip_Pad

It's an odd riddle. I added some logging and it appears as if the mod picks up stray audio clips from KSP. For example, I have seen the SoundFX function called with a group named "smallRattlesFXGroup" (ok) that held a clip named "sound_docking_port" (it should have been "ShipEffectsContinued/Sounds/small_rattles"). Another time it picked up "sound_vent_large". Wat? Why?

No worries. I stumbled over the same thing. In a similar way, crossfeeding fuel through decouplers requires the Fuel Systems tech node.

Nope. Is it mandatory to restore the stock behavior? It is stock behaviour that autostruts require unlocking the struts tech node in a career game.

Did you unlock the "General Construction" tech node? In career, you need to have the EAS-4 Strut Connector available in order to use autostruts.

Is it the "while (X) { if (!X) { unreachableCall() } }"? I spend too much time in the VAB mulling over security and redundancy constraints that no gameplay will ever need, so maybe I don't have a much qualified opinion on this I think that "stock" should not require a player to have planned ahead much in any situation and that improvising your way out of an unplanned situation and still complete a mission is an important part of KSP for me. By the way, doesn't KSP's Mission Builder already implement much of the "visual programming" for mission plans? Combine it with an autopilot that can launch and execute maneuver nodes as they come up. Getting to orbit is half the game, everything after that is bonus play

For the fuel transfer, the same workaround still applies that helped me in earlier versions where interrupted transfers wouldn't resumed: open the PAW of another part containing some resources (or just quickly mouse over the resource panel). That resets the fuel transfer.

On a Linux install, I get a StackOverflowException error when trying to enter the VAB and KSP stops: Does anyone else see this? I'll try to grab a better log with reduced and cleaned mod list later. Oh and while I'm looking at it, this is an improper use of "FOR" and should be "NEEDS": This forces "IndicatorLights" to exist and applies the config regardless, resulting in some probably harmless errors because of missing models and modules. It's not the source of the StackOverflow, though.

I asked the same question earlier, @sarbian told me it's for RO/RSS, not stock. I was looking at playing with "BetterSRBs" and would have expected to make use of this feature in stock, too. I had a cursory glance at the code and I'd say it is supposed to drop solids (or rather not count them as active engines) when the stage's remaining burn time drops below the configured threshold. I'm not sure on that last part, the glance was too cursory to determine what LastNonZeroDVStageBurnTime() actually returns. I'll try it when I restart the game next :)

Try the "Vessel" section ;) Impact prediction readouts are in the Surface section. Here's my HUD section for comparison: https://pastebin.com/Jf6wFBxw

They do (maybe that's a new feature) - if the robotic part is "locked". The lock can be toggled by KAL, too, e.g. at the end of the programmed move. The problem with the lock is that they sometimes don't want to engage because the part is still in micro-motion.

Let the dumpling tanks roll! I have something new to build on the weekend. Thanks for this mod

If need be, I use the radial attachment points from Talisar Parts to radially attach poodles:

I had a look at the log with no clear results, I'm afraid. Did the satellites have stable orbits before they were lost? What's the vessel type of the craft that went messing? Did you (or KSP maybe) set it to "debris/Trümmer"? KSP automatically clears up those and there are several sats winking out in the log that could as well be debris cleanup: [LOG 19:13:01.598] [F: 474612]: Vessel Minmus Recourcen Scan was on-rails at 16.0 kPa pressure and was destroyed. [LOG 19:13:01.599] [F: 474612]: Vessel Minmus Geo Sat was on-rails at 16.0 kPa pressure and was destroyed. [LOG 19:24:32.327] [F: 485115]: Vessel Kerbin Geo Polar Commsat was on-rails at 0.0 kPa pressure and was destroyed. This is the odd one: [WRN 19:31:00.490] [F: 491355]: Vessel Kerbin Geo Commsat 2 crashed through terrain on Kerbin. Among the more usual chuff of mod exceptions, there are lots of "dt is NaN!" messages coming out of KER. That's not a good sign itself but I couldn't see a sure reason for it in the log.