a.g.

CKAN doesn't even work on my linux system because the system version of mono is too old or something. Also not sure what would be required to actually put anything on it.

This is a small plugin I made for myself quite a while back, but seeing even Scott Manley complain in one of his streams about the difficulty of clicking menus from EVA when drifting past I thought I might as well upload it. All the plugin does is make any part right-click menu freeze its position on the screen in flight when the mouse is above any part of it, thus making selecting the correct button a lot easier. If mouse moves away or the camera is rotated, menus pop back to follow their part as usual. This plugin simply solves one small problem so there is no plan to extend it further in any way. License: MIT Download: MenuStabilizer.zip Source on GitHub To install, just put the dll file anywhere in GameData.

Btw a couple of months ago I have modified it to use the stock App Launcher menu for its button since it kinda overlaps it now. The source is on GitHub. I've made a pull request but the author seems to be inactive.

This really makes no sense. You can use quaternions just fine by thinking about them like weirdly packaged rotation matrices and using the rules of matrix algebra. Also there is actually a way to do real debugging, but you have to use MonoDevelop.

I think the first post should mention how to use the mouse input feature, since there is barely any gui besides the checkboxes in the options window and it's not discoverable. The basic points are: When enabled, mouse input can be done by dragging the mouse over the center area of the HUD. Window positions obviously must be locked, otherwise it will move the HUD window instead. Input can be toggled between Rocket or Plane modes affecting either Pitch/Yaw or Pitch/Roll. Enabling mouse input adds a minimized mode to the HUD where only a center mark is visible until mouse is pressed down on it to activate input and more elements appear. This mode is available even where full HUD is not accessible because of career limitations or being in Map mode etc, and the hud toggle button also cycles through it. Input is calculated from the distance between the mouse cursor and the center mark of the HUD. There is a sizeable dead zone (the center is indicated by a cross like mark) and the input curve is slightly nonlinear to enable more precision near zero. When SAS is active, mouse input adjusts the orientation it tries to keep instead of directly appyling input. This target orientation is made visible by an additional mark. Holding right Ctrl when pressing the mouse down temporarily inverts the Plane/Rocket switch until the mouse is released. Holding the modifier key (left Alt or right Shift depending on OS) when releasing the mouse adds the current input to trim instead of simply resetting to zero.

So I've recompiled the libraries for Unity 4.5 and briefly tested debugging on linux, but windows is completely untested. The binaries and sources are on github.

Ignored by what? Obviously you won't be trying to do that using RequestResource, and don't let the stock tweakable interface even look at your misbalanced container (hideFlow=true, isTweakable=false etc). Otherwise, if you edit a craft to introduce that it will be properly loaded, saved, launched, recovered, and all the costs will be as expected.

Where is the source code?

You actually can fill a resource tank above capacity, and even set the maxAmount to zero, and it seems that things still work just fine. Cost from such resources is simply added to the base cost.

The KAS fuel pipe ends are about 2.6 times heavier than the KAS struts, and it is a known thing that part mass matters for connection strength. Stock struts are non-physical and actually create a connection directly between parts they are attached to.

Use this to find out what the bits mean:

You can look at fields of all objects; mdb is only needed for breakpoints and single stepping. Also, all Local Copy does is copy all kind of junk like even Assembly-CSharp.dll into the directory with the dll, which isn't a good idea seeing as KSP would try to load all of them from GameData. Apparently that debug option error is some kind of bug in some versions of MonoDevelop or something.

You can plant a flag at one of the ends just off the runway embankment and target it - that would provide a reasonable indicator within 100km range. At visual range you can also use the PAPI light mod for vertical alignment.

Did you do the steps to set up the project exactly to the letter, like setting the build output directory to inside GameData. Unless the mdb file is placed next to the dll in there, breakpoints won't work. Profiler percentages are of total measured time, even though they can be >100% in places because of weirdness when measuring recursive calls. Do you have any stupid antivirus firewalls or anything active? I have no idea otherwise.

There can only be one control link, so if the plugin is running, any subsequent telnet connections won't work. The Alt+F10 problem may be because of the stupid window manager bindings for Alt+*, which I changed on my computer to use the windows or menu key I think. Also, you are generally not supposed to have any MONO_PATH, although maybe the network code in the plugin needs some dll that is not in KSP_Data/Managed. What does Player.log say about loading the dll?