Monkeydonut

I would like to strongly advocate for ED granting rkApps an official license for SimHaptic. I've a rather expensive motion rig setup with 4 ButtKicker Minis on it. SimHaptic is BY FAR the best software I have used for interpreting DCS telemetry and converting it into extremely immersive haptic feedback. The official software that came with my rig is woefully inadequate for flight simulation and SimHaptic has massively improved my enjoyment of DCS - allowing a deep level of customisation for each aircraft. It's extremely well produced and functions very well. I would go so far to say that SimHaptic is increasing the amount of money I spend on DCS - it certainly makes me more excited to play - and I can only see a benefit to ED in partnering with companies whose software supports their simulator and makes DCS more enjoyable. Massive thumbs up to rkApps - ED please do the right thing and make them official partners.

That was very cool. I'm not an F18 driver but at least now I know how the HDG and CRS switches work and why 3-way switches get talked about so much in these threads Honestly from what I can see you're not far off a working solution for the F16 HDG/CRS knobs. Surely if you have a wrapper reading the USB data you can accumulate clicks from the throttle base, and then send a UDP packet at the set interval with the requisite number of signals for e.g., 5 presses of 'HDG CCW'.

Ah ok - I did understand you correctly then, I just wasn't sure. I'll dig into this more if I have some time but thank you for the info and files!

I found your last post both interesting and somewhat confusing - I'm not sure where the talk of 3-way switches comes in. Are you mapping HDG/CRS CCW and CW to the up and down position of a 3-way switch just for learning purposes and seeing that the virtual knob continually turns in one direction while the physical switch is not in the middle position? I.e., that the 'TRUE' state of the switch continually registers in a way that the TRUE/FALSE/TRUE/FALSE pulsing of the encoder does not? I'm going to be giving your post a thorough re-read, but as I believe that not all planes in DCS have the same HDG/CRS functionality, I would like to clarify my original post in case it helps. The HDG / CRS rotary encoders on the Orion 2 are mapped to the HDG and CRS knob CCW / CW buttons in my F16. In the F16 twisting the HDG or CRS knobs with the mouse smoothly changes the heading or course angle respectively and, in a perfect world, reaching down and twisting the HDG or CRS rotary encoder on the Orion 2 would have a 1:1 correspondence with the virtual knob. Ideally this means mapping a given twist angle of the physical rotary encoder (or number of clicks) to a given twist angle of the relevant virtual knob in DCS, somehow. The only way I can see to do that is to make sure that all clicks register, and to have DCS acknowledge all clicks within a short enough time interval to respond realistically. One should ideally be to tune the scaling between the encoder rotation angle and the HDG/CRS angle change to get their preferred sensitivity. As you say, it's a rotary encoder, and is just firing a button press every time it clicks. If the interval is too small, DCS will actually miss some of those clicks. If the interval is high enough all of the clicks will register, but as you say they will be enqueued one-by-one and sent once per interval, leading to terrible lag. It's good to hear that this might be solvable in some way. I do feel like finding a way to send multiple events in a single time interval makes the most sense. Clearly the issue with these devices is the USB polling frequency and the management of resources in the event loop. However, practically speaking if multiple clicks are accumulated on the device and then sent in a single command at each polling interval there is essentially zero overhead because only one command needs to be sent no matter how many times the encoder was clicked. In other words saying 'button was pressed 5 times' is the same as saying 'button was pressed 1 time' in terms of the USB communication overhead.

Very interesting work, thank you. What light, if any, do your investigations shine on rotary encoder optimisation? I've been struggling with the rotary encoder behaviour on the Orion 2, but assume it's the same for all Winwing devices. In SimApp pro you can change the interval of a rotary encoder between 10 and 200 ms, and the 'acceleration' between 1 and 5. As far as I can see, acceleration has no material effect. I presume that interval controls the maximum rate at which button press signals are sent to DCS on rotating the encoder. Winwing told me that the hardware supports 1 ms, but that games like DCS can't do better than 10 ms. SimApp Pro even says that if clicks of the encoder wheel are missed by the application, that the interval should be raised. In DCS I find that using a 10 ms interval results in a large percentage of clicks being 'missed' entirely. Raising the interval to 30+ ms improves the situation, in the sense that fewer (eventually no) clicks are missed, but introduces huge lag whereby a fast twist of the rotary encoder will take seconds to play out in DCS. Key examples are the HDG and CRS rotary encoders, which seem ideal for binding to the HDG and CRS knobs in the F16, but which don't offer the performance one needs to be practical. Is there anything in a .lua that could be adjusted help with this? One obvious idea is to somehow 'accumulate' rotary encoder signals within the set interval, and then send the accumulated signal to DCS. For example, imagine 5 clicks of the HDG encoder carried out within a set 30 ms interval, and say for the sake of argument that 1 click == 1 degree of HDG angle (not actually true). Currently what appears to happen is that one click is sent out, then there is a wait of 30 ms, then the second click is sent out, and so on. It takes a worst case of 5 x 30 ms or 150 ms to get that 5 degree change in DCS. What would be nice is if those 5 clicks could be accumulated, and after the current 30 ms interval a signal saying 'turn 5 degrees' is sent to DCS. This would perform much better - no dropped signals and no horrendous lag. Other options might be to increase the sensitivity of the encoder - currently one click of the encoder is less than 1 degree of angle change in DCS. Practical use might be achievable if we could simply 'amplify' the signal. One click would send multiple 'button press' signals to DCS and this could be tuned until the user had the response they were looking for. Another option is virtually mapping the rotary encoder to an axis. This can be done for a single rotary encoder using Rz already, but due to the limitation of 8 axes per device on Windows, no more. Perhaps there is a workaround in LUA whereby this limitation can be avoided entirely or subverted: one imagines mapping ALL encoders to a section of a single axis somehow. Anyway, you get the gist - any gut feeling on a workable approach here? Thanks in advance.

Winwing support weren't helpful. Apparently the hardware supports USB update intervals of 1 ms, but most games including DCS won't do better than 10 ms. I couldn't really get much sense out of them with respect to potential workarounds re: virtual mapping or macros - I'm not 100% sure it can't be done, but nothing they said helped. They did see that they would try to improve rotary encoder behaviour / options in the future.

Winwing support weren't helpful. Apparently the hardware supports USB update intervals of 1 ms, but most games including DCS won't do better than 10 ms. I couldn't really get much sense out of them with respect to potential workarounds re: virtual mapping or macros - I'm not 100% sure it can't be done, but nothing they said helped. They did see that they would try to improve rotary encoder behaviour / options in the future.

Did you get anywhere with this? I have the same problem and SimAppPro's acceleration and interval settings do not help AFAICS. A 10 ms interval appears to be too short for DCS to register all the ticks, which means that you don't get a strong response - you're twisting the dial and not getting much movement even though input lag is minimal. Moving to 20-50 ms helps more ticks register, but introduces more input lag such that a large twist of the encoder can take seconds to resolve in DCS. Even if every tick registers, for things like HDG and CRS, one 'tick' or 'click' of the encoder should at most correspond to 1 degree for adequate control. Even if every tick registered, at the minimum 10 ms interval that's a theoretical best case of 3.6 seconds of twisting to do a full revolution of HDG or CRS angle. Real-life performance is worse as 1 tick appears to correspond to less than 1 degree and a good percentage of ticks are not registered. I can't say I've noticed much difference when changing the acceleration between 1 and 5. I'm starting to wonder about virtual mapping, macros and other possibilities. As far as I'm aware, there is a possibility of conflict between SimAppPro and Joystick Gremlin in certain cases so I'm not sure about that as a solution yet. The response of the encoders in DCS is surprisingly poor IMO - not sure where the blame lies though. I've opened a support ticket with Winwing and will report back.

Did you get anywhere with this? I have the same problem and SimAppPro's acceleration and interval settings do not help AFAICS. A 10 ms interval appears to be too short for DCS to register all the ticks, which means that you don't get a strong response - you're twisting the dial and not getting much movement even though input lag is minimal. Moving to 20-50 ms helps more ticks register, but introduces more input lag such that a large twist of the encoder can take seconds to resolve in DCS. Even if every tick registers, for things like HDG and CRS, one 'tick' or 'click' of the encoder should at most correspond to 1 degree for adequate control. Even if every tick registered, at the minimum 10 ms interval that's a theoretical best case of 3.6 seconds of twisting to do a full revolution of HDG or CRS angle. Real-life performance is worse as 1 tick appears to correspond to less than 1 degree and a good percentage of ticks are not registered. I can't say I've noticed much difference when changing the acceleration between 1 and 5. I'm starting to wonder about virtual mapping, macros and other possibilities. The response of the encoders in DCS is surprisingly poor IMO - not sure where the blame lies though. I've opened a support ticket with Winwing and will report back.