prestonflying

Can you attach this file "Saved Games\DCS.openbeta\Logs\dcs.log" it might help explain why

One idea is to try quantifying the stutter you are seeing. Kinda related to ^^ above post. I like to use: https://www.capframex.com/ Run DCS with the full F18 MIP setup., then run capframex, and look at the cpu frame times. It'll break down if there is stutter in the cpu frame time or if this might a result of different screen refresh rates like you linked above. Try repeating this test with no MFD screens being exported (disconnect usb and reboot DCS) If the frames look smooth and flat, this indicates a display issue. If the frames look jitter and spikey, this indicates an external process/SimApp Pro/etc effecting performance of the machine.

All the needed fps changes are standard in Winwing scripts now, no need to manually tweak/edit! I would delete the wwt folder folder from Scripts, run the "SimAppPro->settings->repair lua" to get the fresh ones (that perhaps have new logic to handle the UFC?)

UFC probably uses the export lua scripts, double check those are not commented out or old (you can use the settings->repair lua script I think to get fresh ones from WW). I do not have that issue with devices loading slowly in SimApp. Do you have powered USB hubs? I ran into an issue where I had a 7 port usb hub, but one of my MFDs didn't work when all the usbs were plugged into a single hub. I fixed by reducing the load on the single usb hub. Perhaps this is related? But just a guess

UFC does work for me.null Did you bind your buttons on the UFC, this is needed to get the input recognized? You can also try clicking a button in-game and see if you get data on your WW UFC.

Ya, it arrived this afternoon. Did a test flight with it this evening.

@FZG_ImmelThis link worked for me: https://www.synaptics.com/products/displaylink-graphics/downloads/windows-10.2-m0-public, there is also a 10.3 version but have not tried that yet.

Congrats on getting it! Looks awesome

@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.

@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.

Check to see if the export luas are in place so DCS can pump out the data to Simapp Pro. You can check this by going to /<USER>/Saved Games/<DCS_INSTALL>/Scripts and ensure `Export.lua` has some Winwing lines and there is a wwt folder with some more luas. If these are missing or in the wrong directory then DCS can not send game data to Simapp Pro. There is also a button in SimappPro labelled `Repair Lua`, also there is a DCS World Configuration box in settings, ensure that is set to the Saved Games folder for DCS.

I really had to tighten the black knurled collar. My first few attempts being gentle yet firm, I was about 1/4 of inch from the locking hole being at the 12'oclock with the flat part of the joystick. But then reallllyyy tightened it and it lined up!

I was searching for the source of those files! That helps a lot, now the fixes won’t get override each time SimApp Pro boots up!!!! Nice find

OhI interesting! Mind sharing what you had to change incase others also run into?

In the name of curiosity I found a way to best replicate the course and heading knobs and it works in game. Goal One turn left or right “holds” the switch in the F18 for course/heading. One turn left or right and back to center to mimic a click once for small course/heading change. I did so by reading the USB data of the throttle base in a stand-alone python script, then send a UDP packet to DCS to set the switch for crs/hdg to a given state. Main take away is that by creating a wrapper around the Throttle, extra customization can be gained. Cons, requires extra work to adapt to different aircraft or switches. And it’s not a great long term solution. Pros, cool seeing something work and it was my first time doing something like this. Also shows there does exist a way to fed the desired effect, or the ability to override how Winwing handles certain USB events Video link showing in action

Is there a way to access button/switch/axis state of USB devices from within a lua export script? Perhaps this already exists and seeking a nice clean way to read the data. I was able to read switch data from `clickable.lua` (gear_handle = GetDevice("0")::get_argument_value(foo)) but the goal is to get the values from the USB device directly

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

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.

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 Comment out the `Export.lua` in Saved Games/<DCS>/Scripts` Yes, this does work and fixes all FPS issues, but you lose one of the best features of Winwing products, lights and vibration Turn on VSYNC 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

@MorrisTheCatHere is a cross-posted fix to keep the functionality of the export lua scripts and fix the FPS issues. Video Here Steps 1. Open this file in text editor (eg notepad++ , visual code etc) C:/Users/YOUR_USERNAME/Saved Games/DCS.openbeta/Scripts/wwt/wwtNetwork.lua 2. Edit line 18: w_net.net:settimeout(.001) (By passing a value other than 0, the existing call is blocking the main CPU thread which causes the stutters + CPU spikes). 3. Change line 18 to: w_net.net:settimeout(0) (This makes the network call non-blocking, which is what solves the CPU spikes) 4. Save file and ensure the date modified reflects the change. Sometimes Winwing will override this file which undoes the fix, keep an eye out and re-add until this is officially implemented by Winwing. 5. Test DCS by loading up a mission and hitting RCTRL + Pause to see FPS. Ensure it is relatively smooth, or use any other program to track performance and confirm the fix. Your vibration, apu lights, etc will also remain functional with this fix.

Thanks @MustangSallyfor sharing the video of the fix. For others battling this issue I think you will find great success with the outlined steps in the video, its a small 1 line change to a lua file that differs from existing known solutions such as commenting out the lua file. This fix address the issue in the lua file and allows the vibration, apu lights, etc to work while taking no impact to FPS. I have contacted Winwing Support about this in hopes their Tech Team can validate the solution and implement on their end. In the meantime, here is the fix: Video Here Steps 1. Open this file in text editor (eg notepad++ , visual code etc) C:/Users/YOUR_USERNAME/Saved Games/DCS.openbeta/Scripts/wwt/wwtNetwork.lua 2. Edit line 18: w_net.net:settimeout(.001) (By passing a value other than 0, the existing call is blocking the main CPU thread which causes the stutters + CPU spikes). 3. Change line 18 to: w_net.net:settimeout(0) (This makes the network call non-blocking, which is what solves the CPU spikes) 4. Also the current export rate of 30ms or 33Hz is way too fast. You can modify the `_winwing.interval=.1` which is 10Hz and more practical. This is done in /Scripts/wwt/wwtExport.lua 4. SimApp Pro will continue to overwrite these anytime you reboot or run SimApp Pro so until Winwing adds these, then you must do each time. 5. Test DCS by loading up a mission and hitting RCTRL + Pause to see FPS. Ensure it is relatively smooth, or use any other program to track performance and confirm the fix. Your vibration, apu lights, etc will also remain functional with this fix. If you find it works please leave a comment or reply so others can see!