misterbk

I think I remember seeing someone mention they had rigged up some kind of toggle, so they could effectively "switch gears" into reverse. Maybe that will work for you? Otherwise, like I said, maybe the throttle just won't work. Even if I am remembering right and did have it going both ways at some point, like I said I stopped using it that way due to not having a center detent and being pretty much unable to turn the throttle off. But rover wheels are so bugged and confusing anyway, it's possible I only thought that was what was going on. I assigned rover throttle to one of the trim wheels. Those go both directions. TBH, I think this plugin is dead. It's been long enough that I doubt anything more is coming. I've pretty much shelved KSP. It's too broken for me to enjoy. Last time I tried to build a rocket, it took three days because bugs with fairings kept forcing me to restart the game. Then once I got the thing to launch without physics glitches blowing it up, the solar panels spontaneously broke off for no apparent reason. I might check back in a year and see if the devs have managed to fart out something that works a little better.

Try using one of the finger knobs for the rover throttle. If you were to get the main throttle to work with rovers, you would probably experience problems trying to use it for liftoff and spaceplanes. I vaguely remember getting it to work once, but I have been experiencing a different odd glitch with the throttle. Usually it is zero to -1.0, but every now and then the game sees my throttle as a full axis that goes negative to positive. I don't know how or why, because by design that joystick's throttle axis (like all throttle axes) is supposed to be zero when the throttle is all the way down. It's possible that the first time I tried rovers was a time when I got that glitch. I end up calibrating inside AFBW on every launch. Ever since the first day, I've been using the finger wheels for rovers. The main reason is they have a detent in the middle where I know the wheels are off. Honestly though, rovers are so bugged in that game that I stopped using them entirely after I landed the first one on the Mun. They are nigh frictionless, like slowly melting ice wheels on a Teflon planet. The brakes don't even stop the wheels when the throttle is at zero and the rover is stationary, flipped upside down with its wheels in the air. You can make them stop spinning by deactivating their motors and then applying brakes, but until you do that throttle in both directions makes them spin faster, and it still takes like 30 seconds for a free-spinning rover wheel to stop itself. The rover can't even stay traveling forward, it will slowly angle to one side and start this weird infinite frictionless skid in the direction it was traveling. Yet somehow, even when the rover is sliding frictionlessly 30° to the left of its wheel axes and has no reaction wheels or RCS thrusters, you can still use the steering to slowly control its yaw. (Which would indicate to me that if it's only drifting 2° to 5° off axis, the wheels should have enough friction to turn that into a turn instead of skidding for miles in the same direction. But no, as soon as it's traveling faster than a Kerbal can run, it loses all control.) Unless there's a mod that fixes them, I recommend simply not using rovers. KSP has obviously faked the physics in some way that just doesn't work at all. In fact, ignoring friction seems to be a common problem in most of their math. Ever docked two spaceships only to get a slowly building resonant standing wave of spaceship wobble, when you are high in orbit and there are no forces acting on the craft? Ever put wheels on something, given it a tiny boost up to 10kph, and coasted along flat landscape for hours? Ever used a Kerbal climbing up a ladder into an obstruction as a thruster to get your science car moving after it runs out of gas? I've landed small spaceplanes (single small jet engine, two liquid fuel fuselage, cockpit and wings), hit the parking brakes and gotten something from the fridge while I waited for the thing to stop so I could get out and take a surface sample on Kerbin.

Check the game's regular bindings, make sure the axis isn't bound in those. Sometimes the AFBW plugin correctly removes the binding from the game's regular controls section, sometimes it doesn't. I had at least one axis stay bound in the vanilla settings area too, and thought the plugin didn't work until I found it.

Just if you add a joystick button binding to the keyboard/mouse bindings. Did you calibrate? I get this before I've calibrated. That's the expected behavior of quadratic. It adds precision to small movements and makes large movements less precise. Use linear, the x52 already has good precision close to center. Also, you should use either the deadzone in the control panel, or the deadzone in Kerbal, not both. I turned off deadzones in the drivers and that seems to work. You will probably notice laggy controls when your framerate starts to drop. This mod fixes that, but as you saw can add some other annoyances. If you have trouble with high part counts, give it another try. Also a must for remapping axes for spaceplanes and rovers, and gives you some new mappings that aren't in stock, like parking brake. Hopefully we eventually get either a fix for this or stock joystick support that doesn't suck. :\

You know what, this just happened to me too. My keyboard profile editor now looks just like yours. I was trying to map keyboard keys in AFBW instead of the stock input system, hoping it would solve my multiple keypresses issue. (Side note: it did not.) Since I use the X52, some of my joystick buttons are joystick buttons and some are keyboard keys. I tried adding a keyboard mapping for SAS Hold, which I thought was mapped to a keystroke but was actually a joystick button. The AFBW key mapper interface immediately changed into the window you pasted a screenshot of, all the way down to the almost-invisible outline of some GUI element in the top left. What happened is AFBW put the XML appropriate for a joystick button into the section for keyboard keys in advanced_flybywire_config_v21.xml, and permanently confused itself. My AFBW seems to be pretty good about not letting me press keyboard keys while assigning joystick buttons, but theoretically this could swing both ways. You might be able to fix your XML file and go on about your business. I was able to fix mine without losing my profiles. A joystick mapping looks like this: <KeyValuePairOfDiscreteActionBitset> <Key>Stage</Key> <Value> <m_SingleData>0</m_SingleData> <m_Data> <int>2</int> <int>0</int> </m_Data> <m_NumBits>42</m_NumBits> </Value> </KeyValuePairOfDiscreteActionBitset> A keyboard mapping looks like this: <KeyValuePairOfDiscreteActionBitset> <Key>Custom06</Key> <Value> <m_SingleData>0</m_SingleData> <m_Data> <int>0</int> <int>4194304</int> <int>0</int> <int>0</int> <int>0</int> <int>0</int> <int>0</int> <int>0</int> <int>0</int> <int>0</int> <int>0</int> </m_Data> <m_NumBits>329</m_NumBits> </Value> </KeyValuePairOfDiscreteActionBitset> I found this entry in the keyboard section (<wrapper>KeyboardMouse</wrapper>) <KeyValuePairOfDiscreteActionBitset> <Key>SASHold</Key> <Value> <m_SingleData>0</m_SingleData> <m_Data> <int>16</int> <int>0</int> </m_Data> <m_NumBits>42</m_NumBits> </Value> </KeyValuePairOfDiscreteActionBitset> Deleting it put things back to normal. AFBW interface is working fine now. If yours is acting up because of a misplaced button in your keys section, the bad entry will probably be at the bottom of that section. Looks like AFBW adds mappings in order as you enter them.

Good point. It works for me with 32-bit KSP, running on 64-bit Windows. The mod is very clear about not supporting 64-bit KSP, so I imagine there would be issues.

I think this must be a conflict with the other mods you have installed. I'm running vanilla KSP plus AFBW, no other mods, and the interface behaves relatively OK for me. See my comment on the previous page, I did a detailed writeup of what I see when starting the game with AFBW and how to treat it to get the desired functionality. I do wish someone would explain what "SDL Issues" means though, so I know what errors I should be expecting to encounter. For example, now that AFBW is installed I get very strange behavior from joystick buttons that have been mapped to keyboard keys within the X52 profiler. When the part count on screen is low, the keyboard keys sent by the joystick profiler act normally. When the part count on screen is high, even if it has not yet begun to affect framerate, joystick buttons mapped as keyboard keys cause a press within KSP once per frame. So pressing a button mapped to the key will rapidly toggle the lights on and off, and pressing a joystick button mapped to [F12] will rapidly enable and disable the aerodynamics overlay, and pressing a joystick button mapped to the [1] key with "collect goo data" set to Action Group 1 will collect that goo experiment up to 8 times. Is that the "SDL Issues?" I don't know. I've been trying to move everything I can to joystick buttons, but I really like being able to use the pinky trigger to make the toggle switches activate different sets of action groups. I wish the X52 profiler was better, it could easily solve all of this if it had the ability to change axis assignments as well as buttons, and the ability to change joystick button assignments in shift states instead of being limited to only keyboard keys. :\

Getting this same bug with O-10 "Puff" monopropellant thrusters, when they are placed in Symmetry mode. Placing two Puff engines on a lander with no other engines, with 2x radial symmetry mode, dropped on the left side: Placing the two thrusters the exact same way, but dropping on the right side: Placing one thruster only, no symmerty mode, on the left side, to show the error in direction is the same: I was shuffling parts around on the rover, trying to fix an unwanted pitch on my lander when thrusting. I rotated the Puff engines to point downward, and that made the arrow at least point mostly in the right direction. Might get more dV from them that way anyway. Obviously this will not help people with other situations.

I am attempting to send a Mun lander pod up along with a rover. The idea is to achieve Mun orbit, detach rover/lander stage (rover / separator / fuel tank / radial rockets and lander pod), Mun entry, hover close to surface and release rover, then land the pod. Then the rover can run around and collect stuff, deliver to lander, which takes it back to orbital lab. In my construction, it goes fairing base > girder > mini separator > rover probe core > large circular battery > mini separator > fuel tank > lander pod. The fairing is supposed to extend up as a straight cylinder and attach to the bottom of the fuel tank, to support and protect the rover parts during liftoff. The game supports this, recognizes touching the fuel tank as a condition to complete the fairing. The vehicle root is below the fairing base. If I detach or attach just about anything above the fairing base, I get the bug and can no longer click on things. VAB is then permanently broken until I exit the game. At least, I can't find any in-game action that resets it, including quitting to the main menu and reloading the save. I've also had this glitch happen several times when the fairing was the topmost cone of the ship, with an orbital survey probe inside.

Getting the exact same bug myself, and the exact same InvalidOperationException in KSP.log. [LOG 22:00:57.511] ---DockingAsDecoupler : 2 [LOG 22:01:05.794] fuelTank2-2 added to ship - part count: 104 [EXC 22:01:05.799] InvalidOperationException: Operation is not valid due to the current state of the object System.Linq.Enumerable.Last[FairingXSection] (IEnumerable`1 source) ModuleProceduralFairing+.MoveNext () UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) ModuleProceduralFairing:scheduleReconnect() ModuleProceduralFairing:<SetupEditorFSM>m__19B() KerbalFSM:RunEvent(KFSMEvent) ModuleProceduralFairing:onInterstageReattach() Part:onAttach(Part, Boolean) EditorLogic:attachPart(Part, ) EditorLogic:<SetupFSM>m__CD() KerbalFSM:RunEvent(KFSMEvent) KerbalFSM:updateFSM(KFSMUpdateMode) KerbalFSM:UpdateFSM() EditorLogic:Update() This has been happening a lot. I'm having to restart KSP 10 or 20 times to successfully finish any rocket that involves fairings.

Sorry for the double reply. I found something in the logs and wanted to edit it in, but I'm still waiting for moderators to approve my other comment. The error itself is at the very end of KSP.log. It's definitely related to fairings: [LOG 22:00:57.511] ---DockingAsDecoupler : 2 [LOG 22:01:05.794] fuelTank2-2 added to ship - part count: 104 [EXC 22:01:05.799] InvalidOperationException: Operation is not valid due to the current state of the object System.Linq.Enumerable.Last[FairingXSection] (IEnumerable`1 source) ModuleProceduralFairing+.MoveNext () UnityEngine.MonoBehaviour:StartCoroutine(IEnumerator) ModuleProceduralFairing:scheduleReconnect() ModuleProceduralFairing:<SetupEditorFSM>m__19B() KerbalFSM:RunEvent(KFSMEvent) ModuleProceduralFairing:onInterstageReattach() Part:onAttach(Part, Boolean) EditorLogic:attachPart(Part, ) EditorLogic:<SetupFSM>m__CD() KerbalFSM:RunEvent(KFSMEvent) KerbalFSM:updateFSM(KFSMUpdateMode) KerbalFSM:UpdateFSM() EditorLogic:Update() The full KSP.log

I'm having this same problem. Now that I think about it, it started happening when I started trying to use fairings.

So, Windows users can ignore the insistence that this should be installed with CKAN, install AFBW manually, apply Taniwha's Windows DLL from Git, and things should work OK except for rover controls? "SDL issues" sounded scary, since from my googling I think that's the layer that makes the joystick state available to AFBW. Edit: So far, this seems to be working! I encountered the following issues, none of which were fatal, but without someone else saying it works I probably would have thought it was not and uninstalled. CKAN will not show you this mod unless you force it, and will refuse to install it when you do force it. That's fine! Just install manually. Unzip AFBW, overwrite ksp-advanced-flybywire.dll with Taniwha's version from git, drop in Kerbal folder like it says in top comment. [*]Kerbal Space Program will notify you on launch that a toolbar plugin is known to be incompatible. Ignore it, press OK, seems to work for me. [*]My game's visual settings reverted to windowed mode and a low resolution. Ignore that, just set them back in the settings. [*]I got a weird looking toolbar-related icon right in the middle of my screen. It seems to be clickable through other menus, and interferes with e.g. putting your graphics settings back how they should be. That's going to be the AFBW button. AFBW just doesn't automatically activate its icon in that toolbar. Left-click the pulldown arrow and use Configure Visible Buttons. You just have to move it where you want it to be, manually. Pulldown menu, Unlock Position and Size, move it where it should be, Lock Position and Size. [*]Some of my axes responded funny after installing. They were stuck zeroed at odd places and wouldn't go all the way in one direction. Wasn't due to trim. When you assign a function in AFBW, it removes that function assignment from the main settings. Apparently sometimes it misses one. I had to unbind those axis controls from the main menu. [*]Lastly, you have to click the Configuration button next to your joystick and calibrate. I guess this uses its own calibration and deadzone system, not the one you probably already set up in the OS' joystick properties. After doing all that, it seems to be working great. I haven't tested it in flight yet, still tweaking my x52 profile, but even if all I get is the ability to swap my yaw and roll axes this appears to be a success. This is on Win7 x64, with 32-bit Kerbal and Saitek x52. More info after experimenting for a few days. When you start the game, the toolbar will always relocate itself to a strange default position that's in the way. Don't click it right away. If you try to fix it while you are in the space center, hangar bay, or anywhere but flying a craft, it will tend to glitch out and cause strange behavior, such as other game menus being active but invisible. This can lead to you being unable to leave the screen and having to end-task on KSP, because you can't click on the invisible menu but it is still active and preventing you using other buttons. The solution is easy. When you first launch the game, ignore the toolbar icon and switch to a spacecraft. The toolbar will suddenly figure itself out, show the AFBW button, and locate where you last put it. Now right-click the toolbar button that isn't AFBW, and it will go away. From then on the toolbar with AFBW in it will behave normally. (Until the next restart, then you do the dance again.) I use a flag at the head of the runway for this. (I called it "Not Space". It's helpful for finding the KSC runway too.) Everything else is working great. Windows users, give it a try it may work fine for you too.

What does the SDL input issues mean for Windows users? Should we try the Windows DLL and see if it works, or are the issues a deal breaker? I'm on Windows 7 with 32-bit Kerbal, 1.0.2. I've got a great x52 profile set up, but input lag and inability to switch axes for spaceplanes kills it. Is there any way to get fly-by-wire working? Is there an alternative? Sorry if this should be obvious. I tried to read through the thread, but I get confused about whether posted info pertains to Windows or Linux, Kerbal 1.0 or 0.9. Thanks so much to anyone working to get this running again. This functionality should have been in stock KSP!