evilC

OK, a few things I have noticed: The sluggishness seems to only happen when SAS is on - it is with SAS on that I also see the engines strobing their thrust rate a lot. I tried replicating the above craft in the VAB. With the root part as the top cockpit, TCA did not work in horizontal cockpit mode when SAS was on. With SAS off, it controlled the engines on OK, but with SAS on it went nuts. Intersetingly, my fork of Enhanced Navball also does not work properly with a vertical cockpit root part when in the horizontal cockpit.

100% Pure Awesome Sauce! This is the first throttle steering mod that has properly delivered. KCA had arguably better engine control, but lacked in simplicity of use. It also has not been updated and no longer works, so where I was previously left with no solution, now I can use TCA - I may actually start playing some more KSP again... I was just able to get this test rig flying and TCA handled using either cockpit and switching between them in flight!! In the front cockpit, the x axis controlled roll, in the top cockpit, x axis controlled yaw. PERFECT! (FYI, the front cockpit is the root object.) I find it is a little twitchy though (as in the throttle controlled pitch / roll etc), and can be slow to react to (actual) throttle changes - anyone else seeing that? Bad settings maybe or just something you have to iron out. Also, this mod is absolutely epic with my fork of Enhanced Navball (See post after that one for download link). You can use this to add additional prograde/retrograde markers that are rotated by 90 degrees. That way, you can fly a VTOL craft plane style (forward cockpit), but still see the retrograde marker on the navball to assist with vertical landing.

I tried using the version at this link, but it did not work for me. Removed all other mods, added this one. Start new ship in SPH or VAB (Both tried). Pick whatever pod. add structural fuselage to pod (x2). Pick up fuselages, click "Weld". Save welded part. I see the part in the parts list fine, when I select it, it appears, but it is in a different orientation. it only wants to attach in surface mode, in the middle of the two fuselages. It refuses to use the end nodes. One or more of my other mods also broke the weld, hence me stripping out everything. It would be one of: DavonTCSystems EditorExtensions ExsurgentEngineering Firespitter Kerbaltek KineTechAnimation MagicSmokeIndustries ModsByTal ModularFuelTanks ProceduralDynamics ProceduralParts RCSBuildAid ThunderAerospace TouhouTorpedo TurboNisu

Liking the mod, unfortunately it appears not to play well with RCS Build Aid. The yellow Center of Thrust lines are off-center when you change the initial pitch. B9 VTOLs do not suffer from this, I can use the preset to change angle in editor and the yellow CoT lines draw just fine. Not sure if this is just an editor bug or if the CoT is not where you actually think it is, I suspect it is OK as the default purple CoT indicator is aligned just fine. Any ideas why?

Does this mod help you deal with the KSP bug where removing a part that has symmetry enabled and re-attaching it breaks all the action groups?

Does this mod help you deal with the KSP bug where removing a part that has symmetry enabled and re-attaching it breaks all the action groups?

Hmm, I appear to have posted on completely the wrong thread. Apologies.

Great little mod, though unfortunately it falls short of what I need. My previous solution - KCA - seems discontinued, but the code is on GitHub. Any chance you would be interested in trying to get this working again? I think the underlying maths of what he is doing is probably fine, it's just that game changes have broken the code. I have some experience of KSP UI coding and would be willing to help there where I can, but the maths part is way beyond me.

Does this mod let you deal with the KSP bug where you set up action groups on a mirrored part (eg wing), then detatch the part and re-attach it. When you re-attach it, it breaks all the action groups for the mirrored side? Some way for it to automatically fix the error while in the editor would be nice.

Stumbled across this thread and I thought I would chip in... Regarding sticks, I have a couple of utilities that could be of some use to users of this mod. The first is called UJR and will allow people to create a virtual joystick with inverted axes if required. This is also useful for other things in KSP, such as making an XBOX pad work better, or combining two racing pedals into a virtual rudder. The second is currently in it's infancy. It is called MultiThrottle and is another virtual stick app that is designed to let you emulate multiple throttle levers using one physical throttle. ie in this mod, it would let you control all engines with one throttle, but you hold one button to make your throttle control one engine and a different button to make the throttle control another engine. As it stands, MultiThrottle requires you to install AutoHotkey and my ADHD library, plus configure some values in the source script, but ultimately it should be a stand-alone EXE like UJR, with all options selectable using a GUI. For more information on setting it up, view the source. Being still in it's infancy, I am open to suggestions as to how the whole thing should work when it is finished. enjoy

I did some testing with my laptop and have submitted a bug report here. Also, it may be worth checking the "preferred device" settings in windows. It is definitely set to vjoy, right?

I doubt both of those are joy 2. You probably had UJR using the thrustmaster stick as an input? It seems to me that vJoy is not moving from one ID to another, so I do not really sure why you are bothered so much about the stick IDs changing from KSP's perspective. Sure, KSP may decide one day that vjoy is one ID, and one day that it is another, but this is quite easily worked around. Just make sure all references to sticks in the KSP config file are to the vjoy stick. Then, if the vjoy ID changes in KSP, simply do a search and replace in the KSP config file. If all other references to sticks are removed, you can quite safely replace all instances of "joy0" with "joy1". Maybe even keep various copies of the config file and just swap them out. Finally, I am not 100% sure it is a unity issue. I have other unity games that behave OK. Monaco even lets you plug in/out controllers while the game is running. What may be worth doing is taking a fresh machine that has never had any sticks plugged into it and seeing if the problem can be easily reproduced. I have a laptop, I may give this a go. If we could get a bug report that allows squad to replicate the issue, we stand more of a chance of getting it fixed.

Oops, 6.0 had a bug with axis merging, it was not working as intended. The split function I put in at the last minute broke it. New version up, 6.1 Pedals to rudder should work properly now.

Merging still works in the same way, it is just that each merged axis is now on a different page. Slightly more confusing if you are using axis merging, I will agree, but for everyone else it makes the app simpler. Just set up merging as you did before (except you only need to set the right pedal on the "Axes 2" tab to "Merge") and it should work. However, now you can also set the left pedal (on the Axes 1 tab) to "Rests H". This will make the deadzone and sensitivity settings work properly for *both* pedals (ie independent settings for each pedal) . If you do not use those settings, you can ignore the "Rests" options. The main reason for the layout change was to remove the possibility of bad settings (eg 3 rows set to virtual axis 1) and also enable me to know which row was for which virt axis, so I could disable rows for axes that do not exist on the virtual stick. I am open to suggestions though, if you think things could be explained better or the way I have named things is confusing then let me know. Sounds like you are having way more issues than me with KSP. How about this for an idea? Have you tried using the joyIDs app to move the IDs around? Try making the TM stick and the virtual TM stick the highest IDs. I am starting to think that it may be TARGET that is causing the bulk of these issues. I know it could be a ball-ache, but it may be worth trying uninstalling TARGET and seeing what happens if you just use the TM stick with no drivers. I know KSP is guilty of some issues itself, but I suspect we may be seeing two issues layered on top of each other here.

Dude, you are too generous I already forwarded the money you put into the UJR pot to the driver fund! And I totally agree with you - I think vJoy is poised to become the ubiquitous virtual stick app that PPJoy once was, and that can only be a good thing for UJR. When you say that you use different configs (ie pedals for rudder / pedals for roll), do you tab out of the game and swap profiles? I was thinking of adding some kind of quick profile switching to ADHD (The library that underpins UJR), but have been unsure of how to implement it (as in the interface). I think the smartest way would be to add an extra binding for each profile, but that would require some changes to the code, to activate that binding for profiles other than the current one. I also really think that as far as UJR / AHK is concerned, in general sticks do not change ID of their own accord. The obvious exception is when you install or uninstall vJoy - that will grab ID 1. I have 6 sticks installed, and since I got them set up they never, ever change. KSP IDs jump around, but as I said I think that is because it labels sticks not as "stick number" but as "connected stick number" (ie it only counts connected sticks).

No problem Sal, thanks! Oh, and I do not normally nag or solicit for donations, but there is currently a fund going to cover the cost of having the vjoy device driver signed. What would this mean for UJR? It would remove the need for win7 x64 users to enter Test Mode. So if you find UJR useful, instead of clicking my donate link, please go here and donate to the driver fund instead. We only need to raise like another $100, so every little helps.

As I have said before - I would NOT trust what KSP "calls" the axis you just bound. Use the "QuickBind" button to move the virtual axis only in flight mode - does it manipulate the inputs? Disable UJR and move the physical stick in flight mode - does it manipulate the inputs? It is entirely possible that it is working, just KSP is calling the stick by the wrong name. What I normally do is not use the KSP bind routine at all, I edit settings.cfg manually. For example, here is how my entry looks for pitch: AXIS_PITCH { name = Custom Mapping id = joy1.1 inv = False sensitivity = 2.637589 deadzone = 0.1371864 scale = 1 group = 0 switchState = Any } Not that the name field can be ANYTHING, so I set it to "Custom Mapping" so I know which ones I have done manually. The id field is the stick and axis id, in the format joy<stick>.<axis> Regarding XBOX pads - they work OK, but various binds in the game do not recognize the dpad (as it considers it an "axis"), only buttons. However, UJR can let you work around this by mapping the dpad to buttons. You can then use this to your advantage. For example, for me in flight mode, the dpad is throttle (Mapped as an "axis", reading physical dpad). However, when on EVA, the dpad is movement (Mapped to virtual buttons). So as you can see, you can leverage the fact that UJR does not hide the underlying physical stick to double up on controls - as long as they do not cross over (eg for me, when in EVA, throttle does nothing, and when in a ship, the EVA walk commands do nothing, so it is safe for them to share a dpad).

When you say "the physical stick keeps getting chosen", do you mean you are trying to make game bindings and the physical stick appears in the bindings list? Are you using the QuickBind feature to avoid this problem?

The app I linked will let you change IDs around, so no biggie losing it under windows. Also, I think that it is the game engines that are causing the problem. My guess as to what is happening is this: Windows is passing an object of available game controllers: { id:1 {name: "Some Joystick", {...}}, id:2 {name: "", {(Disconnected controller, null object)}}, id:3 {name: "Some Joystick", {...}} } The engine parses this - game stick 1 becomes stick ID 1... Stick ID 2 is disconnected, so the game skips it Stick ID 3 is connected, so the game refers to it as stick 2 Then when it writes the settings file, it saves ID 2, Axis 1 But when the settings file is read, it uses the ID of 2 as a *windows* stick ID, which it is not. As I said, to my knowledge, windows does not change the ID of a stick, ever. If you plug in your 5th stick, it will become stick 5, and even if you unplug all other sticks, windows will refer to it as stick ID 5. So if a game does not behave in this way, it is a fault of the game (or the engine it uses). Some games manage it fine, so clearly it is possible.

I have experienced weirdness in the past with KSP - as you said, the game seems to decide the virtual joystick is a different ID and such. Also, for me when binding, it always calls stuff "Virtual Joystick", even if I moved a stick unconnected with the virtual stick. AFAIK windows always uses a consistent ID for a given stick - when you have plug it in for the first time, it gets assigned an ID, so if you are saying that the stick IDs change in UJR dependent on what is plugged in, well that is a new one on me. Get the JoyIDs utility from here. Run that - the ID listed for each stick should be the same as the ID UJR uses for that stick. I have never seen this change - I can have just one stick plugged in or all my sticks plugged in, and UJR will always use a consistent ID for a given stick. Have a play with JoyIDs, see if you can work out any patterns in the behavior, and maybe we can come up with something.

Thank you! 5.3 has been rolled out via the update notification system.

Windows does indeed support multiple hats natively. The "hats" box gets multiple arrows of different colours when you move them. Like so (Notice two arrows, one red, one blue): In fact, the site I found that screenshot on is talking about arduinos and stuff. May be of interest.

oh really? I didn't think the CH software was that advanced. Pretty impressive. I own a TrackIR too, been doing anything interesting with it? Do any of your sticks have multiple hats? Would you maybe know how to circumvent AHK's limitation of only being able to read 1 hat? I think it is possible via DLL calls and such, but wouldn't know how to do it. I would probably try to tinker if I had a stick with more than 1 hat.

Heh, just as I uploaded that, I had one of those eureka moments. The merge code was assigning the value of the first axis to the merged axis, then later on averaging with the 2nd axis and re-setting the merged axis. This of course could cause a momentary "kick" in one direction, which would only be aggravated by and momentary delays in the code. I have uploaded a new beta - 5.3, same link as in the previous post. I am 99% confident that this will solve your problem. Furthermore, I have been thinking about the overall structure of the axis processing code, and it could maybe do with a bit more work. I have made a post on the AHK forums asking for advice as to the best way to go about structuring the code to maximize responsiveness whilst minimizing CPU usage, so we will see what becomes of that.

Heh, the change I was talking about was indeed way easier. my old code: val := ((val/2)+50) + ((merged_axes[%ax%]/2) * -1) new code: val := (val + merged_axes[%ax%]) / 2 The result is a much more intuitive Merge mode Now I am not sure about your bug, but I think the smartest thing to do is for you to guinea pig the new code for me and see what it does for you. As I have changed how merge works, if I roll out the code it will break other people's merge setups. Not a huge deal if the end result is worth it, but if it doesn't even fix your problem then I probably need to do more work before rolling out a new version. Here is a link to the beta test version: http://evilc.com/files/ahk/vjoy/ujr_beta.zip Simply pop the ujr_beta.exe from that in the same folder as ujr.exe and run the ujr_beta.exe instead. You will have different profiles too, just to be safe, but you can rename stuff as required.