Winwing SimApp Pro + Export scripts Analysis

[prestonflying]

SimApp Pro + Export lua Write Up

Disclaimer: this was written at midnight so there might be some errors. Please comment with any questions and I will gladly help in any way I can!

Goal
What the heck is SimApp Pro doing? And why are there so many reports of bad FPS, de-synced lights, and disconnects? This write up aims to explore those questions and more to better understand how this piece of software works and how we can optimize it.

Why does all of this matter?
As a flight simmer, I enjoy innovation of new products which improve my experience. I want Winwing to succeed and make a great product. In the end, that means I can get my F18 UFC/MFDs and other new products being developed. So the main take away:
1. Help others enjoy their Winwing products,
2. Shed some light on performance issues and fixes so Winwing can add for all to enjoy.

Purpose of Export lua scripts by Winwing?
To send game state to SimApp Pro to power vibration and lights on HOTAS + Combat/Landing Panels.

Attached Files:
Python lua network viewer
Snippet of network traffic between DCS and SimApp Pro

Table of Contents:

• Existing fixes
• New fixes/tweaks
• Overview of SimApp Pro + export scripts
• DCS Export lua traffic viewer (See Winwing messages and watch the data change as your fly)
• Network writeup on how SimApp Pro works

 

Existing facts/fixes

1. Comment out the `Export.lua` in Saved Games/<DCS>/Scripts`
   1. Yes, this does work and fixes all FPS issues, but you lose one of the best features of Winwing products, lights and vibration
2. Turn on VSYNC
   1. Yes, this does work but it only masks the issue. By locking your FPS at 60 most computers can achieve this, yet if you look with a benchmark or profilers, you will notice there stutters and the CPU is not achieving steady frame times.

 

Easy wins to fix FPS and other issues:

settimeout Fix

• Video tutorial here: https://www.youtube.com/watch?v=3TzNOnOYDbg
• Saved Games/Scripts/wwt/wwtNetwork.lua
  • Change `_winwing.net.settimeout(.001)` to `_winwing.net.settimeout(0)`
  • This will prevent a timeout when sending a UDP message which blocks the main thread.
  • This fix alone can help resolve most if not all CPU Frame Time issues
  • Documentation about LuaSocket Library: https://w3.impa.br/~diego/software/luasocket/tcp.html#settimeout
  • Winwing Customer Service has responded and said they will explore this fix in a few weeks time.
  • Test to validate this: Load up a mission with the fix, watch CPU Frame times (RCTRL+Pause), generally, frame times should not vary wildy. You should see smooth and high numbers.
  • CapFrameX for deeper analysis: https://www.capframex.com/download
    •  Note: I have sent this original small fix to Winwing but they stated they will look at in a few weeks. Hope more traction and noise is created so some fixes can come sooner.
• Expect FPS to increase dramatically if you have been using the Export.lua scripts by Winwing. I went from 117 to 180 FPS. Others had similar results. Please share yours as this is by far the biggest point of improvement and the simplest. 

Lua Interval Rate 

•  Saved Games/Scripts/wwt/wwtExport.lua
  •  Change `_winwing.interval=0.03` to `_winwing.interval=0.10`
  •  This will change the frequency at which data is exported to Winwing from every 30ms to every 100ms.
    •  Note: From my testing on i12-12700K and RTX3080, I was unable to send more than 13 message a second and given the human reaction time is between 80-250 milliseconds, having a 100ms update rate is sufficient for flight simulator purposes.
  • Want to see your game run at 1 FPS? Change the interval to something crazy fast like .0001 and change the `settimeouts Fix to be the original .001. This will make DCS run at 1 Frame even thought CPU usage is only at 1-10%. The reason is 1000 times a second there will be a sleep for 10 milliseconds blocking DCS from running. This helps prove that the FPS hog is the way Winwing sends UDP messages and is fixable.
  •    Test to validate this: Load up a mission with the `setimeout` Fix added and this interval rate fix added. Toggle landing gear light or apu light or AA/AG lights rapidly and notice the response time. This should feel fluid and fast and never de-sync.
  •    Why did the Winwing developers ever set this interval so fast? There is no need to send game state so fast especially for non-critical uses like showing a landing gear light.

 

Orion HDG/CRS/HMD Rotary Knobs are slow

• This issue has cropped up in these forums prior as seems to be impact many users.
• From what I can tell, there is no obvious easy fix aside from SimApp Pro changing how the USB device transmits these rotary events.
• The main issue, is when turning these knobs, an event of True is sent immediately followed by False. This is equivalent of using your mouse and tapping for 1-10ms on the CRS/HDG knob. You will see the switch move but it wont be registered as it is not held long enough for a change in course to take place.
• I am exploring a possible hack where a lua script acts as a middle man to control these rotary knobs, not ideal but if Winwing does not address it may be a good workaround. I will update this post if I do find a fix for this.

Light Desyncing

•  From my testing, I found it is easy to get in a state of desync when restarting a mission.
•  Try yourself, load up the Hornet and if you have the Orion Throttle Base, turn on AA mode which should light up.
•  End the mission, and reload the mission.
•   Now AA light should be on, cockpit AA light is off, and if you press AG button on HOTAS, then both AA and AG are on and cockpit state does not match HOTAS state.
•   The fix: Go to SimApp Pro settings (top right icon) -> DCS World Configuration -> "When starting a mission, do you reset the lights on all devices?". CHECK THIS BOX. I know, it sounds like a question and most people do not reset lights, but when this is checked, SimApp Pro WILL reset the lights for you to ensure a fresh state for each mission. Possible English translation issue for this setting, it tripped me up.
• For those other users who are seeing lights desync mid flight, I believe this to be a result of the following items:
  •   `settimeout(.001)` which just blocks the main thread and causes CPU spikes (Fix above)
  •   `_winwing.interval(.03)` which sends ATTEMPTS to send an unreasonable amount of UDP messages to SimApp Pro (Fix above)
  •    These two issues cause increased CPU load and the possibility of a dropped UDP message which results in SimApp Pro missing light/game events.
  •    Why might a UDP message not make it? That is one of the rules of UDP, there is no guarantee a message will arrive to the destination, 99% of the time it does, but if the sending logic is bad it can easily miss messages depending on the implementation.
  •    Again just a theory, I do not have solid proof for this fix but after looking at the code, with these fixes everything should be working fine.

USB Device disconnects??

• I have only experienced this once during my time of making this writeup, unsure what caused it and I was unable to reproduce.
• A simple unplug HOTAS + restart SimApp Pro fixed the issue.
• Not much else to add to this topic, if it crops up it could be hardware related (loose connection) or some other obscure reason.

 

How does SimApp Pro work?

• SimApp Pro works as a server in terms of socket programming.
• SimApp Pro waits for a message to start the mission, when that message is received, it gets the plane type, and sends over a list of "arguments" which are DCS lua variables for a plane in which the export lua scripts should export.
• SimApp Pro does not appear to be a CPU hog and simply processes incoming UDP packets and tells the HOTAS/Panels how to act in terms of lights and vibration.
• Assuming most of the code in SimApp Pro works I see no obvious issues originating from SimApp Pro.

 

Where does SimApp Pro go when HOTAS unplugged or window minimized?
It seems that SimApp Pro is made to run in the background so it can listen for mission start and the desired network messages to DCS. This way, even with SimApp Pro closed the panel lights+vibration still work.

You can verify this by checking Task Manager and seeing SimApp Pro processes running after the window closes. Seeing the lights + vibration work also re-enforce this observation.  

If you are still seeing general issues, then Force Stopping any SimApp Pro processes in Task Manager or restarting your PC might help remedy issues.
 

How does the export lua scripts work from Winwing?

•  Every DCS export lua script has a few hooks into the game, Start, Before Next Frame, Next Activity, Stop
•  Winwing Export is no different, these export scripts send UDP messages on localhost:16536 (SimApp Pro) containing the state of all the lights, switches, flight data.
•  The code in here is very ugly, but after diving into it it really does not do anything too exciting.
•  Listen for SimApp Pro to tell what DCS variables to export, export those at a regular interval to SimApp Pro, send any mission starts/stops.

 

The Technical Stuff
Why include this? Again, the better understanding there is about Winwing software the easier others can fix or extended. This is by no means official but serves as a good 101 on how this black box works. This was all deduced by viewing network traffic to and from the Export lua scripts. I do not have access to SimApp Pro and can not comment how that does work for sure. I can only see the lua scripts.

 

DCS Export Interceptor Python Script

• Attached to this post I have included a zip file which has a updated lua script files for Saved Games/<DCS_FOLDER>/Scripts which allows SimApp Pro messages to be intercepted and viewed for your viewing pleasure.
• There is a readme.txt attached with more info on how to run if you want to see light/game state that Winwing is reading.
• Here you can view message by message what SimApp Pro is doing! Most people probably wont care about this or the following info, but it is here if you want to learn more!
• Overview:
  • Install python3 if you do not have
  • Unzip the attached zip
  • Navigate to the unzipped folder
  • Open the `wwt_files` and copy the Export.lua + wwt folder into `Saved Games/<DCS>/Scripts` and overwrite
    • This step added the updated lua files which send data to our python program on port 17001
  • Open terminal
  • Navigate to unzipped folder
  • `python3 dcs_export_intercepter.py`
  • At anytime open SimApp Pro + DCS
  • Load into a mission, you will start seeing network traffic in the console of the python program.

What do the UDP messages from SimApp Pro look like?
    - There are 2 messages I have found that SimApp Pro sends to DCS export scripts
    - Add Common: {"func": "addCommon", "args": {
        angleOfAttack: return LoGetAngleOfAttack()
        cannonShellsCount: return LoGetPayloadInfo().Cannon.shells
        gearLeftRod: return LoGetMechInfo().gear.main.left.rod
        gearNoseRod: return LoGetMechInfo().gear.main.nose.rod
        gearRightRod: return LoGetMechInfo().gear.main.right.rod
        gearValue: return LoGetMechInfo().gear.value
        speedbrakesValue: return LoGetMechInfo().speedbrakes.value
        trueAirSpeed: return LoGetTrueAirSpeed()
    }

•    This message is determined by SimApp Pro and sent over at the start of the mission to populate the export script with the needed DCS Export methods and what fields to get. This is how Winwing DCS Export script knows what fields to read and send back.
•    I found updating my vibration profile in SimApp pro to include new fields such as thrust/acceleration made new entries into this message: 'accelerationX: return LoGetAccelerationUnits().x'. It is safe to assume that as more devices are released and more features needed, SimApp Pro has the ability to configure the data being exported to its liking.

   
    - Add Output: {"func": "addOutput", "args": {
        152: 0,
        154: 0,
        156: 0,
        158: 0,
        160: 0,
        227: 0,
        3116: 0,
        376: 0,
        440: 0,
        460: 0,
        47: 0,
        48: 0,
    }

• This message from SimApp Pro populates DCS Winwing Export lua with a clean slate of in game variables state. Think of making the bed in the morning, you always want to start with a fresh state (gear handle light, aa/ag mode light, etc are all set to 0)
• This message is sent when the mission is started.
• The values in this message correlate to the lights/switches in: `DCS\ World\ OpenBeta/Mods/aircraft/FA-18C/Cockpit\Scripts/Cockpit\Scripts\MainPanel\lamps.lua`
•  I have yet to identify some of these values, but some of these are AA/AG light, APU Ready Light, Gear Handle Light, Stores Selected Lights, etc.

   
What do the UDP messages from DCS Export lua look like?
    - There consist 4 message types and they all follow a similar structure
    - Network ready: {"func": "net", "msg": "ready"}
        - This message is set to SimApp Pro when DCS finishes loading the export lua scripts
   
    - Mission ready: {"func": "mission", "msg": "ready"}
        - This message is sent when the misson is ready to start to SimApp Pro
   
    - Mission start: {"func": "mission", "msg": "start"}
        - This message is sent when the mission has started to SimApp Pro
   
    - Mission stop: {"func": "mission": "msg": "stop"}
        - This message is sent when the mission has stopped to SimApp Pro
   
    - Add Common: {"func": "addCommon": "args": {"angleOfAttack": 1.4, "gearValue": 0.6", ...}}
        - This message is sent EVERY '_winwing.interval' to SimApp Pro and contains basic aircraft data used for vibration feedback and lights.
   
    - Add Output: {"func": "addOutput": "args": {0: {152: 1, 154: 0: 47: 1, 46: 0, ...}}}

• Why does args have a 0: {fields}? I do not have a solid answer, my hunch was so multiple devices but this code is so crazy I did not spend much time on this portion. All I know is this message contains the APERIODIC messages that are sent whenever a change occurs, which is kind of an issue and possible reason for lights de-syncing mid flight. All it takes is one missed message.
• This message is sent anytime there is a DIFFERENCE in light values/switches. The numbers here in args are mostly found in `DCS\ World\ OpenBeta/Mods/aircraft/FA-18C/Cockpit\Scripts/Cockpit\Scripts\MainPanel\lamps.lua`
• If no values in here change, then this message is not sent to SimApp Pro.
• This could explain the light de-sync issue others reported, as one single missed UDP packed means that light/game event goes undetected by SimApp Pro meanwhile DCS did get the update. So you are now in state where gear handle light is flashing in game, but not on your panel.
• Possible fixes for winging, either include these states every time like those in `addCommon` message, or add a feedback check where SimApp Pro asks for these values every 5 seconds or something to correct any de-sync issues. I would prefer the first fix, just include this state and treat it the same as `addCommon` message.
•   Mapping of args to light/switch name. Some are missing as I could not locate all.
•             F18_ARG_TO_LABEL = {
•                 "47": "Master Arm AA",
•                 "48": "Master Arm AG",
•                 "152": "Stores Center",
•                 "154": "Stores LI",
•                 "156": "Stores LO",
•                 "158": "Stores RI",
•                 "160": "Stores RO",
•                 "227": "Landing Gear Handle",
•                 "276": "RWR Lower Lt",
•                 "376": "APU Light",
•                 "440": "Radar Switch",
•                 "460": "Console Light",
•                 "3116": "Unknown 3116"
•             }

       
   

Winwing_Intercepter.zip example_message_traffic.txt

Edited August 10, 2022 by prestonflying

[Monkeydonut]

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.

Edited August 10, 2022 by Monkeydonut
Grammar

[prestonflying]

3 hours ago, Monkeydonut said:

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.

 

TLDR: Most if not all of these problems are fixable with just software alone. But requires changes from WinWing

Are the rotary knobs bad? I do not think so, for an actually rotary like function these knobs would work and fire the proper events. But when labeling them CRS/HDG and trying to use for a 3 way switch it causes issue. First solution I see is adding a 3 way switch for the binding which is the obvious move. If we must stick with a rotary encoder, then the below comments explore that a bit more.

Small idea: It might be possible to add some lua script that changes how DCS process the rotary events, basically adding the debounc but on the client side. I have a rough idea on how to do this but will give it a try and report back if there is any success. Not super ideal but curious if this is one fix for the meanwhile.

First, how does the CRS switch work in DCS and what does it expect?
- When giving the course knob a single click at varying speeds (super fast click, vs long click) we see the CRS heading turns either barely or it turns a degree or two if held for just a few milliseconds.
- This tells me that this button works based on if the button is held (left or right) in the True state. With a mouse, this means holding the click in any direction.
- With a 3 way switch on the Orion you can bind the down position to CRS Left, middle to none, up to CRS Right. Testing this out, we see we get the desired behavior but not on the ideal switch.

How does the rotary knob on Orion work?
- Taking these findings and moving to the rotary knob in question
- Looking at SimApp Pro, one turn left or right triggers a button to be pressed, which seems like a great start.
- The problem I see is that in the Record Log, turning the knob shows button 90 or 89 being true/false very rapidly which yields a on/off motion in the cockpit (similar to a super fast click but over and over)
- It DOES appear SimApp Pro has some control over these rotary encoders and does not spit out the raw value as we have options for Interval and acceleration (which agreed, does nothing it seems).
- I do not see a way to make the needed change without changing SimApp Pro or the firmware on the HOTAS, in a perfect world there would be a debounce added to the rotary encoder which basically would send one signal and hold it in that position until events stopped.
- Example: I am quickly turning my knob left, SimApp Pro notices that and sets the state to True, as I keep turning I keep firing True/False events,. The debounce would be for like 100ms or something and only send False to DCS/Sim if there was no True event within the last 100ms. This is very commonly used when scrolling on a website, as the scroll wheel moves super fast we do not want to send thousands of scroll down events, just one "keep scrolling down until I say stop". The goal of this would be to prevent the spammy True/False of the knob.
- Is rotary encoder the best solution for CRS/HDG? Not until there is no more True/False events being sent. This is like trying to put an autoclicker with 10ms interval on the CRS switch in the cockpit, you would not make it turn. And the way their 'interval' works for these knobs seems to queue up the events and send them all in a row which takes minutes to complete if trying to turn 360 times.
- I have no way to test or confirm this, and it may not even work. But its an idea for Winwing that is fixable by future software versions of the software and could be tested and explored.
- But the idea that DCS is too slow at processing is not likely, you can visible see each rotary knob event in the cockpit, the issue is on how the software controlling the knobs is processing the events.
- Also the way the CRS/Heading buttons work in DCS might be catered towards this fix of CRS/HDG, so adding a Button Mode in SimApp (Hold True as turning) could be a good idea to only opt into this functionality. 

Edited August 10, 2022 by prestonflying

[Monkeydonut]

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.

[prestonflying]

17 minutes ago, Monkeydonut said:

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.

RE- 3 way switch: On the F18 i bound the CCW CRS HDG and CW CRS HDG to an extra 3 way switch. More so did so to prove to myself that by just sending one True event will suffice (how a button acts). Then taking that learning and trying to find a way to make the rotary encoder behave similarly. I am not familiar with F16 knobs so no comment there.

As you state, 'button was pressed 5 times' is the same as 'button was pressed 1 time'. I agree and that relates back to the idea of making the rotary encoder just send if its spinning left, right, or stopped. Basically 3 button events that mimic that of a 3 way switch.

But at the end of the day, it is the devices and how it manages the sending of these USB events

[Monkeydonut]

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!

[Dos]

Light syncing gave me issues one module (PTO) would turn off when I shut down the hornet but another would stay on. I deleted everything except the winwing line from the export.lua. file and began there and it worked. I added one by one the lines to the export.lua and in the end found that winwing, for me, worked only when it was the last line in that export.lua file. The order in which thnig are listed in the export.lua file matters with light sync. All my lights work on/off and sync with winwing last in export.lua.

Hope it helps someone.

Dos

[markom]

Great job @prestonflying - new release of SimAppPro is out and credits you and this thread. I suppose others pitched in through support tickets as well.

Let's see if this solves our several issues!

[CaptHawk]

8 hours ago, markom said:

Great job @prestonflying - new release of SimAppPro is out and credits you and this thread. I suppose others pitched in through support tickets as well.

Let's see if this solves our several issues!

So far it's working well after 3 hrs of flight time! Thx again @prestonflying.

[m005106]

I just ran into this simapp pro update and WOW..

Thanks for the fix @prestonflying. I can light up apu, a/a, a/g and other stuff I turned off since I bought this rig a year ago.

[prestonflying]

@m005106Yeah! Glad to hear its working well. Makes me happy to see others being able to fully use their equipment! 

Unfortunately, I want to share a warning for others who deal with Winwing. This fix was shared after being submitted to Winwing under the promise of coupons/rewards if the fix worked due to how important it was with the upcoming F18 Panels/previous products, may users stated they would not purchase due to the FPS issues. After Winwing added the fix and validated it, they refused any form of coupons/rewards they has promised.

Their Terms of Service really drive home how much they want to avoid working with the community.  For this reason, I will be cautious of sharing fixes again. I caution others who one day find myself in the same boat.   

Quote

If you choose to provide input or suggestions regarding problems with, or proposed modifications or improvements to, the Product (“Feedback”), then you hereby grant WINWING an unrestricted, perpetual, irrevocable, non-exclusive, fully-paid, royalty-free right to exploit such Feedback in any manner and for any purpose with no duty to make any payments or notice to you for such exploitation. https://wwsimstore.com/view/clause.html

 

It's water under the bridge and I am not angry, but just want others to know how it is trying to deal with Winwing.

[Dos]

@prestonflying Hopefully they will come to their senses. Thanks for making it happen!

Cheers,

Dos

I just looked on the winwing website and the UFC DDI combos are beginning to sell Oct 8th!

 

Edited September 29, 2022 by Dos
update

[FZG_Immel]

On 9/29/2022 at 6:03 PM, prestonflying said:

@m005106Yeah! Glad to hear its working well. Makes me happy to see others being able to fully use their equipment! 

Unfortunately, I want to share a warning for others who deal with Winwing. This fix was shared after being submitted to Winwing under the promise of coupons/rewards if the fix worked due to how important it was with the upcoming F18 Panels/previous products, may users stated they would not purchase due to the FPS issues. After Winwing added the fix and validated it, they refused any form of coupons/rewards they has promised.

Their Terms of Service really drive home how much they want to avoid working with the community.  For this reason, I will be cautious of sharing fixes again. I caution others who one day find myself in the same boat.   

 

It's water under the bridge and I am not angry, but just want others to know how it is trying to deal with Winwing.

If you fix work, And if winwing refuses to reward you for it, I will.

thanks for your work 

[FZG_Immel]

Are you still in this thread Preston ?

[prestonflying]

@FZG_ImmelYes sir, what's up? Also I appreciate the gesture but I would never expect someone on the internet to do that. Just glad others get to have a better sim experience.

[CrashEd]

On 9/29/2022 at 5:03 PM, prestonflying said:

@m005106Yeah! Glad to hear its working well. Makes me happy to see others being able to fully use their equipment! 

Unfortunately, I want to share a warning for others who deal with Winwing. This fix was shared after being submitted to Winwing under the promise of coupons/rewards if the fix worked due to how important it was with the upcoming F18 Panels/previous products, may users stated they would not purchase due to the FPS issues. After Winwing added the fix and validated it, they refused any form of coupons/rewards they has promised.

Their Terms of Service really drive home how much they want to avoid working with the community.  For this reason, I will be cautious of sharing fixes again. I caution others who one day find myself in the same boat.   

 

It's water under the bridge and I am not angry, but just want others to know how it is trying to deal with Winwing.

That's sad to hear. Hopefully WinWing will come to their senses - they would be mad not to. They are on to a good thing here and need the help of clever folk, like yoursef, who are willing to help them. Shame, I thought they were better than that. Thanks again for sharing your findings.

Edited November 2, 2022 by CrashEd

[FZG_Immel]

again, I will reiterate my offer. If winwing doesnt want to reward you, id be glad to. Sim app Pro made my game stutter like crazy in the past, so that i didnt use it for keeping my devices synced with DCS. Now I can and its great.

I'd be glad to help you purchase something if you want to

Edited October 25, 2022 by FZG_Immel

[Scotia]

@prestonflying I'm sorry to hear this!  I really appreciate the work you've put into the fix!