SolarSailor

I've tried to debug it with no luck since I don't have the skill. It seems to be stuck at every call to LFQueue.Produce() on 64 bit Linux/Windows, so it never advances past that log message ("listening thread here."). Perhaps a race condition between something, I know nothing about lock-free algorithms.

1) I have "ACCEPT" everywhere in iptables -L and no rules, it shouldn't be a problem. It also happens on very different systems and I believe it has nothing to do with firewall or networking. Especially since localhost connections shouldn't be affected by the firewall at all (this would break a lot of things in Linux otherwise). 2) I've tested it both locally and on a remote PC with the same result. From what I can tell, there is a try/catch block for logging socket binding errors in the Listener.ThreadProc (Listener.cs:167), so theoretically it should catch a system problem (port is already bound etc). I have no experience in C# or .NET or Unity, but I'll try to set up a debugger/ksp-devtools and check out what's happening, thanks for the idea.

For some reason, the plugin fails to open port 8282 under 64-bit KSP for me, and KSPTOT can't connect to the game. The plugin itself does report that the listening port is open though: [LOG 00:35:12.265] [KSPTOT Connect] init server on port8282 [LOG 00:35:12.266] [KSPTOT Connect] about to start listening thread [LOG 00:35:12.266] [KSPTOT Connect] started listening thread [LOG 00:35:12.267] [KSPTOT Connect] found interpreter 'GetNodesInterpreter' added under key: GetActiveManNodes [LOG 00:35:12.267] [KSPTOT Connect] found interpreter 'GetOrbitInterpreter' added under key: GetVesselOrbitByGUID [LOG 00:35:12.267] [KSPTOT Connect] found interpreter 'GetOrbitInterpreter' added under key: GetActiveVesselOrbit [LOG 00:35:12.267] [KSPTOT Connect] found interpreter 'NodeInterpreter' added under key: NodeData [LOG 00:35:12.267] [KSPTOT Connect] found interpreter 'NodeWrtPeriInterpreter' added under key: NodeDataWRTPeri [LOG 00:35:12.270] [KSPTOT Connect] Server started; now listening for data from KSP TOT. [LOG 00:35:12.327] [KSPTOT Connect] listening thread here. But with netstat -lptu I can see that the game process has only port 8295 open. It happens on both Windows and Linux 64 bit game versions, while under 32 bit ones the plugin is doing perfectly fine with both 8282 and 8295 open (and KSP TOT works as expected). So this is clearly not a networking or firewall issue. Any ideas what's wrong?

See this thread: http://forum.kerbalspaceprogram.com/threads/94378

What do you mean by uneven and not very clear? Some comparison screenshots would certainly help. Nevertheless, linux version is running in OpenGL mode (obviously), and some users can experience glitches or artifacts in OpenGL mode, depending on the driver quality. Antialiasing doesn't work on nvidia drivers in some games until you enforce it in nvidia-settings, that's a known problem.

Oh, someone finally did this. Thanks a million! There's no need to use overbloated Mechjeb for such a simple thing anymore.

I can confirm this. And apparently this issue exists everywhere, not only on Linux, but also on Windows with both 32-bit and 64-bit versions. Like many similar issues with KSP, it often makes the game unplayable on Linux, and is just sometimes noticeable on Windows. I'm surprised that this looks to be uncommon and nobody else is reporting that, because all my friends experienced this in KSP (with different OSes and very different hardware setup, multiple vendors, multiple configurations etc). The FPS drop can be seen when you are trying to rotate the camera with mouse quickly. On Windows, even if your time counter is green ("no lag"), it can turn yellow when you are trying this. On linux, it breaks the game completely. When rotating with keyboard or rotating with a mouse slowly, everything is usually OK. (can be dependent on the rotation speed perhaps, keyboard rotation is slow)

Alright, I did some testing and it looks like it comes from the joints. I've tried the telescope from Hullcam VDS, and it doesn't shake as long as you keep it minimal. After playing a bit with Mechjeb's PID controller, I was able to take a picture of Eeloo with almost no jitter. Without mechjeb, there's no jitter as well (only the natural drift). The point is that Hullcam VDS' telescope consists of just ONE part (with a pod, scope, solar panels and reaction wheel included), so it's a rigid body for the physics engine. With MechJeb's AR-202 attached, the view starts to shake a bit. With more parts attached, it's shaking just like this telescope. Cacteye Telescope is also prone to shaking, since it's also modular.

Also maybe I'm wrong, but I don't think this is caused by rendering method. I was experimenting with MechJeb PID settings to make it less jittery with TGT+ mode, and was able to reduce shaking a bit. MechJeb attitude correction window has some useful info about forces applied, and it was clear that jitter is coming from MechJeb. My guess is that MechJeb calculates object position from orbit parameters, and oscillation is caused by lack of precision in these parameters.

Can't you just lock the camera on the target when it's inside FOV and the magnification level is too high for image to be stable enough? Or maybe it's somehow possible to take this rounding error into account?

@blizzy78 No, it happens as long as MechJeb becomes active (e.g. attaching AR-202 to the rocket), even with side MJ panel hidden. Keeping Mechjeb windows open only makes it stutter more when rotating the camera.

It seems Toolbar doesn't work as intended with MechJeb. When trying to attach MechJeb to the ship, the following error pops up in the log/debug console: [Log]: [MechJeb2] Adding button for Vessel_Info [Exception]: ArgumentException: Getting control 0's position in a group with only 0 controls when doing Repaint Aborting Windows users might not notice anything, but it actually leads to some performance drop, which gets MASSIVE and makes the game unplayable on 64-bit Linux version, especially if you keep some MechJeb windows open (Delta-V Stats for example) and try to rotate the camera around. It only happens with MechJeb and Toolbar installed together. I'm not sure which addon is at fault here though.

@sal_vager I did some investigation, reinstalled everything from scratch, and apparently it only gets that bad with MechJeb and Toolbar installed together. When I install them apart, or use any other mod combination, everything is fine, but with both of them and with Mechjeb attached to anything mouse camera rotation seems to stutter both in flight and in the VAB/SPH. Here's my KSP.log: http://pastebin.com/QV4NLan1 The only unusual thing I can see in it is [EXC 18:57:46.315] NullReferenceException: Object reference not set to an instance of an object This exception only happens when both mods are installed, so I guess it's some kind of a conflict, but everything seems to be OK in Windows version.

For some reason, when I'm trying to attach MechJeb to anything, it makes my game stutter heavily on camera rotation with mouse, it's downright unplayable. Rotation with keyboard arrows and zooming with +/- is perfectly fine and smooth though. I'm running vanilla KSP.x86_64 (with fixes listed in the OP) on an nvidia card in Ubuntu 14.04. I guess it's somehow related to mouse input handling by the game, but why mechjeb is triggering it? Any ideas how to fix it?

Basically you have three options: - build reusable rockets, or SSTO rockets/spaceplanes. - put Sepratrons on your used stages, and set them to retroburn upon separating. - shoot them down!