Black-Talon

evilC, I've already downloaded 5.1 and the new QuickBind is indeed very helpful! Thank you! I'm still struggling with merging two racing pedals into a single axis to use as a rudder. Setting it up works perfectly but a glitch develops in the rudder controls. As I'm flying a twitch kicks the rudder full right occasionally. Extremely frustrating as it knocks the flight out of SAS control and can be devastating to your flight or landing. Have you or others experienced this? Any ideas? It doesn't happen if I map a non-merged axis Definitely a great utility, thank you. I sent you a few pounds in thanks! -Talon

Thank you for this - amazingly helpful.

Thanks for the great post. I've been struggling with very similar things thing for several weeks and *nearly* have everything sorted out. I wanted to note that I'm using Universal Joystick Remapper (which leverages vJoy instead of PPJoy) because I've gotten the impression that it has been actively in development. For the most part I'm happy with it, easy to use. Still requires Test Mode. Does everything I need it to do (merge pedals into single axes, easily invert axes, change axis ids on the fly, and utilize/simplify multiple joysticks). My 1st issue was to get my racing pedals to map the Clutch and Accelerator to one axis for use as a Rudder. This has been done now and UJR w/ vJoy made that easier than what I had been trying with PPJoy and GlovePie (not to mention that PPJoy stopped successfully installing, even in test mode, for some reason). My 2nd issue is still nagging me, getting KSP to recognize the virtual joystick instead of the real one when setting inputs. I saw your tips in the thread and will give them a try. Thank you! My 3rd issue is going to be that these ids seem to get all mix'n'matched when you unplug and replug in joysticks...I have quite a few that I change for racing, flying, controller-pad for action, etc...so this is going to be a problem. I could probably see if I can get everything onto the virtual joystick and somehow keep it's id as 0...but I'm not sure that covers everything. Unity could really use a huge boost here... 4th issue is pretty silly? Once I get these joysticks working, there isn't a follow mode while in atmosphere? So I'll have to take my hand off the stick to turn my view so I can follow a plane? I haven't gotten to this point so perhaps the answer is really simple and I've just overlooked it. If other's have ideas... EDIT: Nevermind, chase camera view works just fine. For some reason it wasn't working the way I had previously experienced but that must have been a mistake on my part, everything works as expected. Joysticks need to come back to gaming... it would be fantastic if KSP helped that happen. :-) Glad to see all of you enjoying awesome setups. **UPDATE - Nov. 27th, 2013** 1. Universal Joystick Remapper is still working perfectly for merging my racing pedals into a rudder 2. The latest version of Universal Joystick Remapper makes this a snap and I can simulate the axis during mapping very easily and it works very well. 3. KSP still seems to get confused (though I still think I could find a way to force a consistent joystick ID and that should solve the issue) BUT, for the most part this is easily resolved. Often I can even solve the problem by just changing some of the associated Joystick/Axes IDs in UJR and that'll get them back inline with KSP. 4. Was never a problem again. I have concluded that I just made a mistake in an under caffeinated moment. 5. *new* I can easily switch between roll for rockets on the pedals and yaw for planes just with an alt-tab and few clicks in UJR! Nice! 6. *new* I was having a problem with the merged rudder axes twitching out occasionally, but since evilC is actively working to improve the utility this was fixed and it works super smooth now! - Talon Thrustmaster HOTAS Warthog Joystick & Throttle Fanatec Club Sport Petals Universal Joystick Remapper!

I just want to confirm that this did, as expected, address my stutter (in 0.7.3). It really is an impressive improvement and runs smoother than I was able to perceive it's previous slowness. Nice work going the extra mile with the profiler...not everyone does that. ;-) Very appreciated here! And as always, extremely impressive mod overall. Really enjoyable. Thank you! -Talon

I reloaded 0.7.1 and can confirm that 0.7.2 has a lower glitch per minute density than 0.7.1. So there was an improvement. :-) That said, I've discovered that I may be reporting a bit of a red herring (very sorry about that). Or at least something that I haven't been able to figure out. I can't get the glitch to reproduce on a stock setup with just Kethane installed. If I install many other mods the glitch while mousing over the grid will be there in the fresh install (but obviously that doesn't help at all). I've spent the afternoon enabling and disabling mods to try to narrow it down (while also enjoying a mojetto, so things could be worse :-p), sadly, I have not been able to narrow it down. It basically seems that once many mods are installed (memory usage while flying a stock craft is at or above 2 gb) the glitch shows up. But I've had various sets of mods installed and nothing seems wrong. When I install everything, the glitch shows up. I'm going to take a break from testing now, maybe I'll discover a mistake I made at some point and have better information. -Talon

I'm not sure if what I have is the same as everyone else, but in 7.1 I had constant stutter from the overlay. Now that (in 7.2) the overlay isn't calculating all the time, I only get hiccups while mousing over the map grid. I think a video will best show you what I'm experiencing... http://www.screencast.com/t/CapIVYwm (I'm in progress on setting up a complete stock, Kethane only, game where I can confirm this occurs with Kethane on it's own) Regardless, it's playable and I love it. Thanks! Specs for reference: Kerbal Space Program - 0.20.2.186 (WindowsPlayer) OS: Windows 7 Service Pack 1 (6.1.7601) 64bit CPU: Intel® Core i7 CPU 870 @ 2.93GHz (8) RAM: 8152 GPU: ATI Radeon HD 5700 Series (1012MB) SM: 30 (Direct3D 9.0c [aticfx32.dll 8.17.10.1172])

I'm interested in knowing more about how drag is determined by FAR. For example, the above example of the heat-shield, I'm really curious to find out what causes that? Similarly, does the comparison between these two ships (one with what I'd assume would be high drag components added on) seem correct? I'm only asking to better understand how FAR works and what types of things could go wrong so I can avoid them. This should be high drag? This should be much less drag?

This was working prior to Kethane but not after? Hmm... I would guess that your ModuleManager isn't working, where did you put the ModuleManager.dll? Do you have more than 1 copy of ModuleManager in different locations within the GameData folder (RemoteTech installs by default this way - see link below)? Is it possible that the ModuleManager.dll was overwritten with an older version when installing another mod? Older versions had conflicts with B9, but the newest version (comes with FAR) works very well. If you want examples of how ModuleManager should be installed to eliminate conflicts, I go into a fair bit of detail with screenshots showing where things should be installed in this post . FWIW, I'm using newest Kethane & FAR and have no issues.

Beautifully done!

Well done! Impressive! ...and I'm drooling. ;-)

I've learned a few more things about using FAR with Firespitter Wings/Controls in case it's of interest to anyone trying to use both. I have a separate installation for FAR which I enjoy using to make/fly planes. I have Firespitter installed in both my non-FAR version of KSP, and the FAR-enable version. I do enjoy Firespitter in both! Previously I noted that I was attempting to load and fly Firespitter's (Stock) K-17 in my FAR-enabled version of KSP and I observed a few hiccups that made it impossible to do: Controls don't update graphically unless they are locked and then unlocked prior to flight Even once the control surfaces are updating graphically they don't seem to apply much control to the craft Take off results in a uncontrolled loop and unintentional rough 'landing' ;-) For someone familiar with FAR you would notice that the control surfaces aren't configurable in the VAB These four issues can be resolved by eliminating the FSwingletRangeAdjustment Module from the Firespitter wings and changing the FAR Module from a wing to a control surface. Previously I floated some questions about things I didn't understand: It seems a FARControllableSurface is more accurate for the wings with control surfaces? Note that there is some concern noted in both the FAR and Firespitter threads that wings with integrated control surfaces are not yet supported in FAR...but I've found that without at least some tweaks, Firespitter wings are unusable in FAR, but work enjoyably once modified. This is all confirmed. In order for the Firespitter wings to be used as control surfaces with FAR installed they must be changed to be FAR Control Surfaces. This doesn't model them correctly, it treats the entire wing as a control surface instead of just the actual surface. That said, it does work which is better than not working. The root cause here is that FAR doesn't support this wing type. The default drag and lift configuration is zeroed out on stock parts...should the same should be true for Firespitter wing/control parts? The suggestion is that no, there is no need for them to be zeroed out. FAR does that behind the scenes on it's own. Some of the FAR configuration values used on Firespitter wings aren't documented in the FAR Readme.txt, perhaps they shouldn't be there? Others need to be there instead? These are older values and don't cause any harm but neither are they needed. In FAR, when a AoA Sweep analysis is done, only CL is graphed... does the lack of CD and others indicate incorrectly configured parts? This is caused by the InfoDrive part that is installed on the K-17. A part I really enjoy! While I have no idea why, it seems that a part without a "rescaleFactor" defined in the config will destroy FAR's drag model. By setting "rescaleFactor = 1" for the Info Drive part, all works perfectly. By making these minor adjustments I was able to enjoy a fantastic flight of the (Stock) Firespitter K-17 to the south pole and back. Nice! Easy way to get Firespitter wings working with FAR so that the stock planes can be flown: use this Additional ModuleManager Config to make the modifications noted above. It is simpler than my previous ModuleManager Config and I'm just happy that it lets me enjoy the Stock Planes in my FAR-enabled KSP Installation. The config won't overwrite any parts and can be undone easily at any time by removing the config. Note that it only changes anything if FAR is installed (which comes with the required ModuleManager). -Talon

I've learned a few more things about using FAR with Firespitter Wings/Controls in case it's of interest to anyone trying to use both. I have a separate installation for FAR which I enjoy using to make/fly planes. I have Firespitter installed in both my non-FAR version of KSP, and the FAR-enable version. I do enjoy Firespitter in both! Previously I noted that I was attempting to load and fly Firespitter's (Stock) K-17 in my FAR-enabled version of KSP and I observed a few hiccups that made it impossible to do: Controls don't update graphically unless they are locked and then unlocked prior to flight Even once the control surfaces are updating graphically they don't seem to apply much control to the craft Take off results in a uncontrolled loop and unintentional rough 'landing' ;-) For someone familiar with FAR you would notice that the control surfaces aren't configurable in the VAB These four issues can be resolved by eliminating the FSwingletRangeAdjustment Module from the Firespitter wings and changing the FAR Module from a wing to a control surface. Previously I floated some questions about things I didn't understand: It seems a FARControllableSurface is more accurate for the wings with control surfaces? Note that there is some concern noted in both the FAR and Firespitter threads that wings with integrated control surfaces are not yet supported in FAR...but I've found that without at least some tweaks, Firespitter wings are unusable in FAR, but work enjoyably once modified. This is all confirmed. In order for the Firespitter wings to be used as control surfaces with FAR installed they must be changed to be FAR Control Surfaces. This doesn't model them correctly, it treats the entire wing as a control surface instead of just the actual surface. That said, it does work which is better than not working. The root cause here is that FAR doesn't support this wing type. The default drag and lift configuration is zeroed out on stock parts...should the same should be true for Firespitter wing/control parts? The suggestion is that no, there is no need for them to be zeroed out. FAR does that behind the scenes on it's own. Some of the FAR configuration values used on Firespitter wings aren't documented in the FAR Readme.txt, perhaps they shouldn't be there? Others need to be there instead? These are older values and don't cause any harm but neither are they needed. In FAR, when a AoA Sweep analysis is done, only CL is graphed... does the lack of CD and others indicate incorrectly configured parts? This is caused by the InfoDrive part that is installed on the K-17. A part I really enjoy! While I have no idea why, it seems that a part without a "rescaleFactor" defined in the config will destroy FAR's drag model. By setting "rescaleFactor = 1" for the Info Drive part, all works perfectly. By making these minor adjustments I was able to enjoy a fantastic flight of the (Stock) Firespitter K-17 to the south pole and back. Nice! Easy way to get Firespitter wings working with FAR so that the stock planes can be flown: use this Additional ModuleManager Config to make the modifications noted above. It is simpler than my previous ModuleManager Config and I'm just happy that it lets me enjoy the Stock Planes in my FAR-enabled KSP Installation. The config won't overwrite any parts and can be undone easily at any time by removing the config. Note that it only changes anything if FAR is installed (which comes with the required ModuleManager). -Talon

Everything goes in GameData. RemoteTech in a folder. Probe Compatibility in another. Just copy the folder and put it in there, not just the contents.When I open the .zip from spaceport, I have RemoteTech_MM_ProbeCompatability/ModuleManager.dll and RemoteTech_MM_ProbeCompatability/RemoteTech/RemoteTech.cfg and Readme.txt. What needs to go where? I have tried putting it all in the gamedata as is.Just place the entire RemoteTech_MM_ProbeCompatability folder into GameData and it should work without a hitch.@JDP & Cliph - I humbly suggest that this is not the best way to install the ProbeCompatability pack. Allow me to share some of the potential conflicts with this... I would love there to be a better consensus on this to make it easier for everyone to install mods, but as a start I only offer my observations. - First I want to say you're absolutely right, in a completely stock game of KSP v0.20.2, adding everything to the \GameData\ folder as you suggest, will work just fine. It would look like this: http://screencast.com/t/RrMtFjQ8snq4 But a couple things have come up: The version of ModuleManager.dll that shipped with RemoteTech had some conflicts with the B9 parts pack. Specifically the plugin "ExsurgentEngineering" which ships with that pack. Since that conflict arose new versions of ModuleManager were updated to ensure that conflict didn't occur. It can be found on the ModuleManager forum post. Other mods that are shipping with ModuleManager (DeadlyReentry, FerramAerospaceResearch, IoncrossCrewSupport, and ModularFuelTanks) set up the \GameData\ folder with the ModuleManager.dll naked in the \GameData\ folder: \KSP\GameData\ModuleManager.dll (Side Note: I'm confident that this is how those modders intended for their files to be installed because the GameData folder is included in their distributed .zip file; thus clearly communicating the intended folder structure.) This means that if I install RemoteTech and another Mod using ModuleManager then it would look like this. The multiple copies of ModuleManager.dll is problematic and likely causes conflicts with itself. - Personally, I really like the direction you headed in with the ModuleManager.dll and configs in their own folder (though I would've named the base folder "ModuleManager" such that a single .dll in a generically named folder could be used by all other mods as well). But unfortunately that's not what everyone else has done so it would still be an issue. Longer term, it would be awesome to change the norm here. I haven't actually looked at the code yet but I'm a bit concerned that I suspect ModuleManager.dll is looking through all the .cfg's in child directories of it's root location. It would be nice if the scope of this location was limited to .cfg files that were intentionally meant to be leveraged by ModuleManager. This is why your installation method really apeals to me...but the norm would have to change. (EDIT: A quick glance at the ModuleManager source has me less convinced that this is how it works. Probably no reason to stop putting the ModuleManager.dll at the \GameData\ModuleManager.dll location...no reason other than my own OCD I suppose; FOLDER FOR ALL THE THINGS!) - IMO, the best course of action in the short term would be to recommend a different installation practice. One where the ModuleManager.dll is utilized in the base location of the GameData folder, and the ProbeCompatability_ModuleManager.cfg is located in a RemoteTech folder of any name desired. This would look like this. - So in short summary, two things should be done differently for the short term. Do these justify a maintenance release or should people just use some special instructions to install the mod without conflicts? RemoteTech's ProbeCompatibility pack has an outdated ModuleManager.dll, the latest version should be used. The ModuleManager.dll should be installed in the same location as is used by other mods to prevent it from being installed more than once and conflicting with itself. (optional IMO) If a new .zip was released, I would also personally recommend a .zip file structure which included the \GameData\ folder such that there isn't any confusion about where the files/folders should be merged into KSP directory. As it is now I can see that someone might think that Parts, Plugins, and Resources folders should be merged to their legacy locations. BTW - I'm still LOVING RemoteTech, thanks for the awesome work! I also really appreciate the use of ModuleManager, it really makes updates much easier when I don't have to figure out all the part.cfg overwrites, double checking for conflicts. -Talon

You're talking about ModuleManager.dll, right? It actually works pretty well, I really enjoy it so I don't muck up my original part.cfg's. You might first make sure you have the latest ModuleManager.dll: http://forum.kerbalspaceprogram.com/showthread.php/31342-0-20-ModuleManager-1-3-for-all-your-stock-modding-needs Doublecheck the rest of your mods as well - there were some earlier conflicts. Then arrange things like this: KSP\ -GameData\ --ModuleManager.dll --RemoteTech\ ---Parts\ ---Plugins\ ---Resources\ ---RemoteTech.cfg In case it's confusing, what I was trying to say in the diagram is: 1) Put ModuleManager.dll in the KSP\GameData\ folder 2) Put the RemoteTech.cfg in the KSP\GameData\RemoteTech\ folder 3) Put RemoteTech's Parts, Plugins, and Resources folders into KSP\GameData\RemoteTech\ folder as well If this doesn't work ... I umm, well... not sure.

Completely understandable and as expected. Testing your parts with all the other mods would be ridiculous. Given I saw others with the same challenge I was having I just wanted to share what I'd found. I didn't see it clearly explained elsewhere so I hoped it would be helpful to some. Thanks again for the great stuff! Just to make sure my own confusion is clear, I don't really know if it's actually a problem with Ferram's support of this wing type. I mean, with my minor changes it seems to work... I wouldn't know if it's being modeled correctly but it works well enough for me. So I really don't know if Ferram needs to make changes to support this specifically or if it's just an opportunity for him to model it more accurately. I do know that I'm enjoying using both mods congruently with the few tweaks to eliminate the conflicts. I also know that I really appreciate all the enhanced entertainment I've had due to the volunteer work of all the modders. Thank you! It's been a blast!

[cross-posted in Firespitter Propeller Plane and Helicopter Parts Addon Thread] I've been enjoying seeing all the great things made using Firespitter for quite some time. Unfortunately I had a rough time when I went to try it because I had the bright idea to install with into my game with Ferram Aerospace Research installed. My thinking was that of course I wanted to fly awesome planes using a much better flight model (thanks to Snjo or Ferram for great mods, and wonderful support!). I quickly realized there must be a problem with this and used Firespitter without FAR. But I still really wanted to do it... sadly I haven't seen anything obvious on how/if this can work. A couple comments seem to have the same issues I had when using with FAR... Using the Firespitter's Stock K-17: Controls don't update graphically unless they are locked and then unlocked prior to flight Even once the control surfaces are updating graphically they don't seem to apply much control to the craft Take off results in a uncontrolled loop and unintentional rough 'landing' ;-) For someone familiar with FAR you would notice that the control surfaces aren't configurable in the VAB After reading a few more tips about how to apply FAR onto wings, how Firespitter wings have the FAR values included on them by default, etc... I dug into seeing if something in particular was wrong... DISCLAIMER - I really am new to both FAR and Firespitter. I did my best to find information on how to use both together... I don't claim to really know what I'm doing here. :-) And I would love to hear from others on the best way to get these two fantastic mods working well together. Here are a list of things I found: I firstly discovered that (sadly) the FSwingletRangeAdjustment Module seems to conflict with FAR. The FAR configuration values are all configured as FARWingAerodynamicModel - it seems a FARControllableSurface is more accurate for the wings with control surfaces? Note that there is some concern noted in both the FAR and Firespitter threads that wings with integrated control surfaces are not yet supported in FAR...but I've found that without at least some tweaks, Firespitter wings are unusable in FAR, but work enjoyably once modified. The default drag and lift configuration is zeroed out on stock parts...should the same should be true for Firespitter wing/control parts? Some of the FAR configuration values used on Firespitter wings aren't documented in the FAR Readme.txt, perhaps they shouldn't be there? Others need to be there instead? Results: I created this ModuleManager config which allows me to use Firespitter and FAR together (suggested changes/improvements?): FirespitterFAR_MM_CFG.zip With heavy trim, the Firespitter Stock K-17 is a joy to fly. :-) I don't really have confidence that this was done correctly and it obviously loses the ability to adjust the control range in flight (something I'd love to have on all my planes while using FAR - hope a solution for them to be compatible is found/developed). In FAR, when a AoA Sweep analysis is done, only CL is graphed... does the lack of CD and others indicate incorrectly configured parts? Lastly - If either Snjo or Ferram object in anyway to the ModuleManager configuration I will happily take it down or adjust it to meet their needs. I only wanted to share what I've found to get things working. Oh, and I'd be happy to pass on videos and logs of the behavior I'm describing if that would be helpful to anyone. -Talon

[cross-posted in Ferram Aerospace Research Addon Thread] I've been enjoying seeing all the great things made using Firespitter for quite some time. Unfortunately I had a rough time when I went to try it because I had the bright idea to install with into my game with Ferram Aerospace Research installed. My thinking was that of course I wanted to fly awesome planes using a much better flight model (thanks to Snjo or Ferram for great mods, and wonderful support!). I quickly realized there must be a problem with this and used Firespitter without FAR. But I still really wanted to do it... sadly I haven't seen anything obvious on how/if this can work. A couple comments seem to have the same issues I had when using with FAR... Using the Firespitter's Stock K-17: Controls don't update graphically unless they are locked and then unlocked prior to flight Even once the control surfaces are updating graphically they don't seem to apply much control to the craft Take off results in a uncontrolled loop and unintentional rough 'landing' ;-) For someone familiar with FAR you would notice that the control surfaces aren't configurable in the VAB After reading a few more tips about how to apply FAR onto wings, how Firespitter wings have the FAR values included on them by default, etc... I dug into seeing if something in particular was wrong... DISCLAIMER - I really am new to both FAR and Firespitter. I did my best to find information on how to use both together... I don't claim to really know what I'm doing here. :-) And I would love to hear from others on the best way to get these two fantastic mods working well together. Here are a list of things I found: I firstly discovered that (sadly) the FSwingletRangeAdjustment Module seems to conflict with FAR. The FAR configuration values are all configured as FARWingAerodynamicModel - it seems a FARControllableSurface is more accurate for the wings with control surfaces? Note that there is some concern noted in both the FAR and Firespitter threads that wings with integrated control surfaces are not yet supported in FAR...but I've found that without at least some tweaks, Firespitter wings are unusable in FAR, but work enjoyably once modified. The default drag and lift configuration is zeroed out on stock parts...should the same should be true for Firespitter wing/control parts? Some of the FAR configuration values used on Firespitter wings aren't documented in the FAR Readme.txt, perhaps they shouldn't be there? Others need to be there instead? Results: I created this ModuleManager config which allows me to use Firespitter and FAR together (suggested changes/improvements?): FirespitterFAR_MM_CFG.zip With heavy trim, the Firespitter Stock K-17 is a joy to fly. :-) I don't really have confidence that this was done correctly and it obviously loses the ability to adjust the control range in flight (something I'd love to have on all my planes while using FAR - hope a solution for them to be compatible is found/developed). In FAR, when a AoA Sweep analysis is done, only CL is graphed... does the lack of CD and others indicate incorrectly configured parts? Lastly - If either Snjo or Ferram object in anyway to the ModuleManager configuration I will happily take it down or adjust it to meet their needs. I only wanted to share what I've found to get things working. Oh, and I'd be happy to pass on videos and logs of the behavior I'm describing if that would be helpful to anyone. -Talon

Not at all. Deadly Reentry [into the atmosphere of course, what else are you re-entering??] is perfect. Reentry is deadly for lots of reasons...

Great stuff. Very much enjoying these! Makes me crave a re-engineered Modular Multiwheels and Omniwheels to use similar new physics and the games standard wheel mechanics. They do seem a bit excessively strong ... I like the new medium sized stock wheel you can push it pretty hard until the tire pops, repair it, and continue on. Would be nice to have a similar play style here with these. But either way, they're really great, thanks!!

Eager to try it! Thanks again for the great work!

Thrilled to see the GameData folder included in the .zip - that helps me be sure I'm installing it correctly, thank you! FWIW, I do agree about the temperature scale concerns. Once again I greatly appreciate the realism but the need to modify all my parts (while greatly improved with your work on module manager) to maintain the awesomeness of this mod is tough. Another idea I had that might make this easier to cover both cases... I'd love if the temp limit was actually displayed in the right-click context menu during flight. That way I could see both the current temp and the max for that part. Now... what if the units displayed there were actually Celsius as you and real-life desire BUT meanwhile all the parts temps listed in the config files were considered Kerbal Degrees and converted to Celsius on the fly as suggested by others? Now you'd get best of both...display of real life temps but no need to modify every new part other modders create. win-win-win!

Quite impressed. My first few Deadly Re-entries have been spectacular! I'm going to continue to experiment and explore. Curious on a couple points for clarification in this release: - from the previous discussion, FAR is highly recommended or does it work with/without equally? - could I get an idea of the g-force tolerances? from what I've seen so far they're enjoyably relevant!

For what it's worth, I think having the GameData in your .zip is key. This confirms to me as a user where the mod fits into my installation. It gives me the name of the folder I already have so I know the correct structure to install the Mod.

Thank you for the update and confirmation. I found the same, no issues with the nodes for these parts. =)

KasperVld, thank you for the update and repost (particularly with permission - nicely done). I know you're not intending to do much continued development on the parts. However, I'm very curious if these earlier comments are current issues still and if they can be fixed with config edits: Also there was a post about this here: http://forum.kerbalspaceprogram.com/showthread.php/30755-KSPX-incompatibility-with-v-0-20-quad-couplers Perhaps this was fixed and just not noted in the thread/patch notes (or was never a problem with corrected fixed parts?) ...but I was left confused after reading the thread and thus I'm planning to take a look and see if this is an issue that exists and see if it could be fixed. <EDIT> UPDATE: As also noted below, I have confirmed that these bugs do not in fact exist in the current download. I don't know why Scoppio was experiencing them.