a.g.

I tried, and indeed, it doesn't work without the fixes: after a vessel switch the indicators in the left bottom corner move, but there is no effect on the current ship at all. Presumably the ship will respond if and only if the update happens within its own OnFlyByWire. Also, I just noticed that mouse control completely dies with trim set, which makes it largely useless for manual control of planes. Another minor bug: on linux (and presumably osx), the settings end up in a file literally called "\GameData\HydroTech\PluginData\mousecontrol\settings.cfg" - no directory separators implied.

Note that your code also assumes that there is only one vessel controlled, and it never changes. I bet it breaks when you switch with [ and ], and my patch fixes it. It is independent from how it loads, except that with KSPAddon it seems that there isn't any 'controlled' vessel at all when it is instantiated, so a change was necessary anyway.

I think it is something of a solution in search of a problem. What you get as a result is a mod that despite being a purely ui thing that should be freely addable and removable by copying a directory (like subassembly loader or dynamic warp) requires modifications to the persistent save-game state. It's not like it is an autopilot or something anyway, it's just a joystick replacement using the mouse for fine control. I think the dummy part based load mode doesn't work any more in 0.20, since parts are loaded only when needed - I had to switch dynamic warp to the unit test trick for it to work (didn't understand KSPAddon well enough at that time). So now it's only legacy unit test trick, or KSPAddon, which I think should be actually quite close to how scenario modules work, except that it is declared in code instead of the savefile.

Why this scenario thing? No other mod needs it, and I think neither does this one really - especially with the new KSPAddon stuff. In fact just yesterday I got the previous version loading via KSPAddon. Edit: And after a simple merge, this is the necessary change for the latest version: http://filebin.ca/jJWoJJhniXT/noscenario.zip

It's largely a matter of chance, based on where the kernel chooses to place memory areas for heap, and how to grow it. Allocating lots of memory merely makes it more likely. For some people it seems it crashes basically as soon as it tries to load a png image: http://bugs.kerbalspaceprogram.com/issues/752 (no idea what's the problem with his 32-bit version, since there is only one log) What might work is changing a couple of bytes in the executable to make libpng think that the cpu doesn't support MMX and skip all this optimized stuff, but I didn't have time to test it much yet.

I want to report a definite miscompilation bug in the 64-bit linux executable of KSP 0.20.* that results in a segfault in certain circumstances. It can be reproduced by loading the png file coming with the HydroTech Mouse Drive mod; it is not reliable, and is helped by high memory usage due to other mods and trying multiple times: http://filebin.ca/jFdwbprJ5pz/Player.log Observing disassembly around the crash point reveals that there is some obviously 32-bit code in the supposedly 64-bit executable. Some research shows that it comes from hand-coded assembly within pngvcrd.c of libpng: http://pastebin.com/599g7h7i. This code obviously should never be included in a 64-bit build, and will crash whenever called with pointers that don't fit in the low 4 GB. Since as I understand Squad doesn't actually build the native executables from source, this issue probably should be forwarded to Unity.

The bigger problem is how to make them display on top of the craft, i.e. not be obscured by its outside surface when inside it. I have a very faint idea how stuff is rendered in unity, especially the more complex effects like this. For the lines I basically looked how Quantum Struts draws its stuff.

In my modified version of FAR there are some indicators for lift and drag in flight, although they are based on the actual forces at the moment, and Ferram told me it's actually called center of pressure instead of center of lift, or something like that. I don't know if it is even possible to display indicators in flight on top of the craft like in VAB, so they are just crude long lines sticking out of the sides of the craft, and I'm not sure if it is good or useful enough to be included. You can see them in the flameout screenshot I posted a few pages back: http://i.imgur.com/yWFADPz.png

There also was an error about 'Mark3Cockpit' (should be mark3Cockpit) in the log file.

Hm, although I never noticed this before, I now did manage to reproduce the same intermittent flame-out using my backup of 0.19. So the effect isn't new; the new thing is that now both FAR and MechJeb are identically wrong in predicting it, while in 0.19 it starts happening exactly when air supply drops below 100% as computed by MechJeb. This might mean some new change in air consumption computations. Edit: After some more experimentation, I found that the difference seems to be entirely because I disabled the engine nacelle intakes when testing in 0.19. Therefore, this issue seems to be very similar to the one that was causing problems for Kethane earlier: if you request a resource amount that cannot be serviced by any single tank, even if the total amount is sufficient, it can intermittently fail and return 0. In this instance it appears to render the small nacelle intakes completely useless once the air flow drops to a sufficiently low level. A completely different issue that I just noticed is that it seems that in this latest FAR version the changes it previously did to the engines disappeared. The reason I disabled those nacelles in 0.19 is that it was hard to get the craft up to a height where it will flame-out with all intakes active, and I wanted to speed up events. In the current version however it is very easy to get it up to 18km even without specifically trying to - that's why I noticed this effect in the first place.

Whew, reproduced the asymmetrical air consumption and intermittent flame-out problem using pure stock fresh install, after tweaking the control surfaces and flying the thing for an hour to burn off some fuel mass: http://imgur.com/a/dJlt9 Now it should be safe to report it somewhere I suppose.

Yes, it's obviously some problem in how resources work; from the screenshot it appears that it tries to draw air from one intake more than the other for some reason, and starts toggling on and off frame by frame when it runs out. But to report this, somebody has to reproduce it using all stock, so I wondered if anybody already has.

I still get a nonsensical center of lift in the hangar with this stock craft: http://i.imgur.com/IqvPnUH.jpg Looking at Player.log, it doesn't seem that "@module = Part" does anything, or at least it isn't visible there. Edit: more importantly, you have two "part not found" errors in the log: for 'Mark3Cockpit' and 'smallCtrlSurf'. By messing with the craft I confirmed that the problem with that center of lift is because of those small control surface parts.

Either I somehow installed that ModuleManager thing wrong (twice), or it doesn't work properly - the CoL in the hangar is all wrong, the craft handles differently, and forces in stable level flight don't add up: http://i.imgur.com/VhQf1Xl.png. This is completely fixed if I remove it all and replace with the original cfg-overwriting version by ferram. Also, in both versions, I have also noticed a very weird effect that I haven't seen before: at around 120% intake power (a number agreed with by MechJeb) an engine would intermittently flame out, switching between active and flamed out every physical frame (seen if DynamicWarp slowdown is used). If you check symmetrical intakes, one would be at zero, and another would actually have air available; this looks like some new bug causing assymmetry in how resources are drawn. I wonder if the same happens in pure stock. http://i.imgur.com/yWFADPz.png

This is my update of Dynamic Warp: http://dl.dropboxusercontent.com/u/14711013/DynamicWarp-0.20-fix.zip

Since the Dynamic Warp plugin by DEADBEEF also stopped working, I updated it for 0.20: I find its extreme slow down mode very useful for observing how exactly things blow up

Actually the working version at http://kerbalspaceprogram.com/docking-strut-2/ is 1.0.0.0, and the broken one is 1.0.0.1; the broken one has more complicated code and slightly later dates. Probably it was uploaded prematurely for whatever reason. Note that the working one isn't without faults either - it suffers from the same problem as quantum struts if combined with octagonal struts, except that you have full control about both ends of the connection here. Edit: from the source code of the broken version: The problem is that point one doesn't work for various reasons.

It looks like you have a docking port connected to octagonal struts. That is a known source of problems and I wouldn't recommend using those parts anywhere between a docking port and another docking port or command module.

I sent you a fix for air intake percent calculation and a couple of other small tweaks some time ago via pm - did you receive it?

Placing the center of mass at or near the attachment point may be simply improving the capability of the joint to immediately arrest the movement. There are more limitations on torque and angular velocity in the physics engine than on plain linear force, so a shorter lever arm is probably more stable.

About intakes, I'm currently messing with the code trying to add indicators of forces acting on a craft in flight, and in the process found a bug where it counts engines and intakes multiple times. Specifically, every engine or intake is counted once for every part module of any type that it has. This probably throws off the calculation in some way.

Try opening the part.cfg file for the wings and deleting the "CoMOffset = -4, 0, 0" line; it seems to fix that.

If that rover was using the bobcat plugin, that is probably because in order to make rovers more stable and avoid all the complaints about difficulty of steering it applies artificial gravity of 1 kerbin g to the rover when wheels are deployed.

Trying that persistent.sfs from the above post, it seems that removing the CoMOffset line from part.cfg completely fixes the jumping and exploding. Maybe that parameter is bugged due to relative disuse and shouldn't be used, especially for something this heavy. About the weird angle issue, it seems it may be caused by the adapter's attachment surface sides not being parallel to the center axis of the craft: Since the rearmost area of the collider already seems nearly parallel, maybe it can be changed to be fully flat?

There is one more thing I noticed: if you surface-attach a wing part at an angle, then surface-attach a control surface to it, this usually works ok; however on the last adapter in the picture it sticks at a weird angle, which is roughly proportional to the rotation of the wing, but cannot be fixed by shift-rotating the surface back due to some minor inconsistency. A good workaround seems to be to first build the wing straight with all the necessary controls, then detach it and rotate to the desired angle as a whole, but it is a bit annoying.