aurel42

Hello, I recently purchased P3Dv5 and FSUIPC6. After installing FSUIPC6 6.0.10, P3Dv5 (w/ Hotfix 2, 5.0.31.35253) becomes unresponsive after the main window opens and aircraft and scenery are fully loaded. When trying to interact with the window, Windows stops the process. When I remove the FSUIPC6 folder from the Add-ons folder, P3Dv5 does not become unresponsive. When I move the FSUIPC6 folder back, the issue is back. Aircraft and departure location don't appear to matter. Event viewer: Faulting application name: Prepar3D.exe, version: 5.0.31.35253, time stamp: 0x5eebf566 Faulting module name: KERNELBASE.dll, version: 10.0.19041.488, time stamp: 0x5b4a3325 Exception code: 0xc0020001 Fault offset: 0x0000000000023e49 Faulting process id: 0x3350 Faulting application start time: 0x01d68e78895632ec Faulting application path: C:\Program Files\Lockheed Martin\Prepar3D v5\Prepar3D.exe Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll Report Id: 00c09f5d-770f-42c2-bab1-b01b42ef033b Faulting package full name: Faulting package-relative application ID: FSUIPC6.log ends abruptly after "Starting everything now". Deleting the FSUIPC6.ini to let FSUIPC create a fresh one does not help. So far, the only additional content I installed are OrbX scenery and a couple of A2A aircraft. I would be grateful for any steps that could help to isolate the problem. Thanks, Marc FSUIPC6.log

Wish me luck. :) In the past couple of weeks I provided detailed information (of course including which version of P3D I'm using) and description, examples, CLS2Sim profiles, even video of the issue, and the only response I got was that they can't reproduce it in X-Plane (sic!). I can't even…

Thank you very much, Thomas! I ended up with a file with over half a million lines of raw SimConnect log data. Just glancing over the data, I found this when (and only when) the CLS2Sim software was "connected": < 494.85144 [63] >>>>> EXCEPTION=2, SendID=199484, Index=0 <<<<< Unrecognized Data Received. [63, 199484] While this seems fishy, it doesn't seem to be related to my problem. But it could be an indicator that Brunner's SimConnect code has... well... issues. 😄 I think I also found the actual culprit: Line 14377: > 72.63441 [63, 19]MapClientEventToSimEvent:EventID=9002, EventName="TOGGLE_FLIGHT_DIRECTOR" Line 14378: > 72.63443 [63, 20]AddClientEventToNotificationGroup:GroupID=2, EventID=9002, bMaskable=0 Line 318595: > 324.31639 [63, 119422]TransmitClientEvent:ObjectID=0, EventID=9002, dwData=1, GroupID=2, Flags=0 Line 319814: > 325.31732 [63, 119898]TransmitClientEvent:ObjectID=0, EventID=9002, dwData=1, GroupID=2, Flags=0 Line 321003: > 326.31440 [63, 120369]TransmitClientEvent:ObjectID=0, EventID=9002, dwData=1, GroupID=2, Flags=0 Line 322239: > 327.31735 [63, 120845]TransmitClientEvent:ObjectID=0, EventID=9002, dwData=1, GroupID=2, Flags=0 Line 323525: > 328.33978 [63, 121321]TransmitClientEvent:ObjectID=0, EventID=9002, dwData=1, GroupID=2, Flags=0 ... This matches exactly what I'm seeing: about once per second the FD is toggled off. "Client" 63 is called "SimConnectWrapper" and it's clearly the CLS2Sim software. Armed with this, maybe I can get Brunner to finally acknowledge and maybe even fix the issue. FSUIPC really is the swiss army knife of ESP flight simming. Thanks again, Marc

Hello there! I use this fancy force-feedback yoke (Brunner CLS-E NG) with P3D v4.5 and the latest FSUIPC. The yoke needs a software ("CLS2Sim") which is constantly running to talk to P3D. When this software is running and I'm using an aircraft that has a Flight Director that can be toggled on and off (examples: Aerosoft Twotter, xTreme Prototypes LJ25D, RealAir Turbine Duke), the FD is constantly toggled on, off, on, off, about once per second. When I "disconnect" the Brunner software from the sim, this behaviour stops immediately. I reconnect the software and it starts again. I am not sure whether it is a button, keyboard, or SimConnect event that toggles the FD. I don't have the FD control assigned in FSUIPC, so I suspect it's a SimConnect event, but I cannot be certain. Is it possible (and, if so, how) to debug the issue using the FSUIPC logging feature, so I can tell the software developer what exactly is happening on my system? I appreciate any advice! Cheers, Marc

Yeah, in your mail you suggested 10ms and I started with that value. When I saw that 10ms solved the problem, I figured I would try to find the highest possible value by going from 20 to 10 (instead of the other way around), simply because I expected that with every step the result would become better and I like saving the best for last. To be honest, by the time I got to 15ms, I thought I would be able to stop testing before even getting to 10ms again, I did not expect that "anomaly" from 14ms down to 11ms and I have no clue at all what's happening there.

I know I said I would leave you alone for the day, but I think you will forgive me, because you were spot on. With the test version of the dll you provided, I tested by decreasing ComReadLoopTime from 20ms in steps of 1ms. I learned that only values divisible by 5 are worth trying: at 19-20ms, about half the events were lost, at 18-16ms, about a third of the events were lost, at 15ms, only about 10% (!) of the events were lost, at 13-14ms, about a quarter of the events were lost, at 11-12ms, about a third (!) of the events were lost, and, finally, at 10ms, suddenly no events were lost at all. I guess that means there's rhythm to the music, and somehow it helps to clap on the "multiple of 5ms" beat. 🙂 On my system, there is no noticeable performance impact whatsoever at the 10ms setting compared to the 20ms setting. I say "noticeable", because I'm not sure how to benchmark P3D reliably. Thank you so much for turning my stupid hardware from half a brick into something that works as exactly as I imagined! Marc

OMG, now I feel so bad for being such a nuisance. Happy birthday, dear Pete. Please enjoy your day knowing we love you and are so grateful for everything you're doing for the FS community. Thanks for the explanation of the quirks, or rather flaws of the MJOY16 controller. Now it all makes sense, and, yeah, I fully agree with your analysis that its behaviour is braindead. I will test the dll tonight and get back to you by tomorrow! THANK YOU! Marc

I am not saying that com.read doesn't see everything COMread sees. I apologize if that's the impression I gave you. I am saying that, after looking at the log, I am positive that COMread doesn't see about half of the button events generated by my rotary encoders (at least according to the log and the behaviour of the lua script), even though the Windows HID system picks them up reliably and other applications (e.g. X-Plane) can see all of them just fine. So if it's not a hardware issue (which would affect X-Plane as well) or a "driver" issue (because the device uses the default Windows thingie for HID devices, there is no special magic at work), and something happens between the Windows HID thingie and my LUA script which makes half of the events disappear, I think that's worth investigating. You say that's unlikely because it works for you. All I can respond is that this problem might not be visible with manually operated buttons because they're pressed long enough. It might not be visible with those "phase-alternating" rotary encoders because they keep that alternating state long enough for COMread to pick it up. I don't know the internals of how Windows handles joysticks. Maybe the issue only happens when a LUA script is running and some other special FSUIPC setting or feature is in use, what do I know. All I can say is that I think I can prove that there is in fact a real issue if you indulge me and look at two pieces of the log file and then do your "search and count" after you've seen the context. Let me try to make my point as digestible and concise as I can. In the 102nd second covered in the log, I turned the rotary encoder and it clicked once. // SV Mapper has registered the click and sends a key combination 102000 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=2 102000 .. Key not programmed -- passed on to FS 102000 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=3 102000 .. Key not programmed -- passed on to FS 102015 KEYDOWN: VK=54, Waiting=0, Repeat=N, Shifts=3 // FSUIPC turns the heading bug by one degree 102015 FS Control Sent: Ctrl=65879, Param=0 HEADING_BUG_INC 102015 .. This key is programmed in FSUIPC4 'Keys' options 102015 KEYUP: VK=54, Waiting=0 102015 KEYUP: VK=16, Waiting=0 102015 KEYUP: VK=17, Waiting=0 // If we remove all COMread lines that don't start with 03, for your convenience, // all that is left are lines with this payload: 102015 COMread: 8 bytes: 03 00 02 08 60 7D 00 00 // There is not a single line that ends with "20 00", // which means COMread does not see this button event. Why not? At this point we've waited for a second and COMread did not see the button state change. This is not behaving as expected. Since a second has passed, I turn the encoder again until it clicks once. This time we get the result we would like to see every time the encoder clicks: // just like in the previous second, "SV Mapper" sends the key combination after noticing the click 103187 KEYDOWN: VK=17, Waiting=0, Repeat=N, Shifts=2 103187 .. Key not programmed -- passed on to FS 103203 KEYDOWN: VK=16, Waiting=0, Repeat=N, Shifts=3 103203 .. Key not programmed -- passed on to FS 103203 KEYDOWN: VK=54, Waiting=0, Repeat=N, Shifts=3 // FSUIPC turns the heading bug by one degree 103203 FS Control Sent: Ctrl=65879, Param=0 HEADING_BUG_INC 103203 .. This key is programmed in FSUIPC4 'Keys' options 103203 KEYUP: VK=54, Waiting=0 103203 KEYUP: VK=16, Waiting=0 103203 KEYUP: VK=17, Waiting=0 // I removed all COMread lines not starting with "03" 103265 COMread: 8 bytes: 03 00 02 08 60 7D 00 00 103297 COMread: 8 bytes: 03 00 02 08 60 7D 00 00 103312 COMread: 8 bytes: 03 00 02 08 60 7D 00 00 103406 COMread: 8 bytes: 03 00 02 08 60 7D 00 00 103437 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 // here we are, "20" found, this is the button press 103453 Button changed: bRef=0, Joy=68, Btn=5, Pressed 103453 [Buttons] 182=P68,5,C65879,0 // FSUIPC turns the heading bug by another degree, because the virtual button has been "pressed" 103468 FS Control Sent: Ctrl=65879, Param=0 HEADING_BUG_INC 103468 LUA.0: last button state: 20 103468 Button changed: bRef=0, Joy=68, Btn=5, Released 103468 [Buttons] 209=U68,5,C65879,0 // FSUIPC turns the heading bug again, because the virtual button has been "released" 103468 FS Control Sent: Ctrl=65879, Param=0 HEADING_BUG_INC 103468 LUA.0: last button state: 0 // We increased the heading bug twice (once for pressed, once for released) which is a just mistake in my FSUIPC configuration. // I realize this is a distraction, but I simply forgot to remove the "release" setting in FSUIPC after verifying that my // encoders don't need it. // All in all, the heading bug moved by three degrees for one click which has been seen by "SV Mapper" *and* the LUA script So if COMread could see all the events and the radial encoder clicked 32 times, we should see HEADING_BUG_INC 96 times in the log file. We don't. If you're following me so far, you're probably going to say that "SV Mapper" is the culprit. But: I only ran "SV Mapper" so all the "clicks" of the rotary encoder would somehow manifest in the FSUIPC log. If I don't run "SV Mapper", the behaviour of FSUIPC and my LUA script is exactly the same. But then you would only have my word -- I would say "it should show 32 events because the rotary encoder clicked 32 times" and you would say "there were only 19 events". If you use your search and count to look for KEYDOWN: VK=54 you will find exactly 32 matches. And only for 17 of those 32 events will you be able to find a matching COMread/LUA stanza. Again: if "SV Mapper" had not been running, COMread would still only have seen 17 of the 32 button presses. And this seems to be a bug. Somewhere. (Note how this is still consistent with my first post, before I even used "SV Mapper".) [addition: Why 17/34 and not 19/38? Because the rotary encoder sent two spurious events ("20 20" instead of "20 00", probably because of a hardware flaw, this happens rarely (2 in 32 is an outlier)). They resulted in button 5 being pressed, button 13 being pressed, button 5 being pressed a second time (without being released!) and then all "three" buttons are released in the same order. See timestamps 112375 and 121875. These are the two "extra" events that I ignored because they don't seem relevant for the issue at hand, and the two "5 pressed" and two "5 released" events were caused by the same encoder click.] To verify that "SV Mapper" is not the culprit and is a valid way to show the actual encoder clicks in the FSUIPC log, I ran "SV Mapper" together with X-Plane. Every single click of the rotary encoders resulted in the appropriate button being highlighted simultaneously in "SV Mapper" as well as X-Plane. X-Plane didn't lose a single click, let alone half of them. If this is about trust and you doubt that I turned the rotary encoder 32 times and not just 17 or 19 times, I can try to make a video that shows me turning the knob, X-Plane and "SV Mapper" blinking for every click, and then I can reboot (to make sure nothing interferes) and launch P3D and demonstrate how COMread only sees about half of them, at least according to the log and the lua script...? If you want me to shut up and go away, I can shut up and go away. it might just not be worth it if I'm the only person affected by this issue. But I would appreciate if you would at least acknowledge that, based on the log I provided and the argument I made, there is an issue -- at least with my hardware, on my system. [What if this is the reason why Alaxus and other users couldn't make their rotary encoders work either?] Thanks, Marc

Yes, well, no, the keystrokes are mapped in FSUIPC. Quoting myself: I was counting 17 out of 32 by looking closely at the changed button states and the keystrokes sent by "SV Mapper", and comparing that with the time when I actually manipulated the rotary encoder. I know that I turned the knob for half a minute at a pace of roughly one click per second. This resulted in 32 events in "SV Mapper" which were mapped to keystrokes. FSUIPC picked them up and turned them into HEADING BUG INC. If you check the log, you will find that 32 of the 66 HEADING BUG INC controls follow a KEYDOWN event. That's the correct number of clicks (1 per sec for "about 30s"). Since I followed your advice to assign press and release events to the virtual buttons in FSUIPC for the lua script, we would now expect 64 more HEADING BUG INC controls. I forgot to change this for the test, but in a previous post I explained that the rotary encoders of my device do not need an event on release. Every click results in a button being pressed and released, they don't alternate states between pressed and released as other encoders do. Because of this setup the heading bug should turn by three degrees for every click, one degree because the SV Mapper sends a keystroke, and one degree for the press and release events as seen by the LUA script. So we should see 96 HEADING BUG INC. Instead we see 32 by "SV Mapper" und 34 by the lua script, and if we discard the dupes caused by the release, we end up with 17 of 32. To see the difference between a lost event and one that got picked up, please look at the first two timestamps I provided, second 102 and second 103 in the log. In second 102, only "SV Mapper" caused the heading bug to move by one degree. In second 103, "SV Mapper" moves the heading bug by one degree, the lua script moves it by another two degrees. I don't understand this. Is this a problem? I don't believe in an overrun, either. There are no extraordinary amounts of data coming from the device, as you can see from the frame rates documented in the log, there were no performance issues during the test. Since my analysis points to a cointoss situation -- about half of the data is lost, but not every second piece of data -- my gut feeling is that somehow in my case two "entities" are polling from the same buffer and for every poll, it's a race between the two entities who gets the data. That's why I asked those questions in that follow-up post, because I wanted to make sure that my lua script had exclusive access to its copy of the buffer, and didn't have to share it with something else. I hope I was successful sharing my confusion with you now. Yes, and in my previous post I provided time stamps for every time the button was seen as pressed by COMread. Attached below are the matching lines from the log. There are 21 lines. Four times, the button was logged twice before the LUA script got to com.read it (two lines within the same fraction of a second). This leaves 17 times that the button has been seen as pressed down, while it should have been seen 32 times. Thanks for sticking with me on this, Marc $ grep ": 03 .* 20" FSUIPC5.log # showing all COMread lines from log that start with "03" and contain "20" 103437 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 106390 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 108375 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 108406 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 111375 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 112343 COMread: 8 bytes: 03 00 02 08 60 7D 20 20 114312 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 115187 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 116156 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 116172 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 119015 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 119968 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 120000 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 120984 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 121859 COMread: 8 bytes: 03 00 02 08 60 7D 20 20 122953 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 125922 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 126937 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 126953 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 127937 COMread: 8 bytes: 03 00 02 08 60 7D 20 00 129922 COMread: 8 bytes: 03 00 02 08 60 7D 20 00

Hi Pete, I've attached the log. What I did: I launched P3D and "SV Mapper", I confirmed the default scenario in the scenario dialog, I opened the FSUIPC dialog and set up logging, I started a new log file, then I started my "HidTRTL.lua" script and I turned one of the rotary encoders for about half a minute, about one click per second. [For clarification: I would normally never run "SV Mapper" and the lua script simultaneously, because both are currently mapped in FSUIPC and that would obviously send duplicated controls to the sim. This is just for testing purposes.] Here are the timestamps for the clicks, first column: when FSUIPC sees the keystrokes "SV Mapper" generated as response to the rotary encoder "clicking", second column (only if present): HidTRTL.lua notices the "click", additional colums: timestamps of "60 7D 20" showing up in the COMread dump, this appears to be the "signature" of the event during this test. 102000 103187 103453 103437 104109 105093 106125 106406 106390 107062 108156 108406 108375 108406 109203 110203 111156 111406 111375 112109 112375 112343* 113031 114062 114343 114312 114968 115218 115187 115937 116172 116156 116172 116843 117828 118797 119015 119015 119750 120000 119968 120000 120734 121000 120984 121625 121875 121859* 122687 122968 122953 123656 124625 125656 125953 125922 126687 126968 126937 126953 127718 127953 127937 128547 129687 129968 129922 130718 131859 132875 [* Two times, the radial encoder sent a spurious "fast" event in addition to the correct event. This happens occasionally, I have no idea why. Probably a bug of the "MJOY16" homebrew board. It registers in the LUA script as two buttons being pressed simultaneously (0x2020 instead of 0x0020). If we can make the lua work, I could filter out these buggy events.] So COMread sees 17 of the 32 events. Pretty much half of what it should see. As if someone else [Snow White?!] was stealing half of the events from the buffer before my lua script (or even com.read) could get to them. Where do we go from here? More confused than ever, Marc FSUIPC5.log

Questioning my assumptions... com.openhid creates a queue which should receive a copy of all state changes of the device, correct? This queue is exclusive to the com.openhid handle, only the process holding the handle can read from this queue, correct? Is it weird that I feel like one of the seven dwarfs... "Who has been reading from my queue?"

I didn't realize that, thanks for the clarification. I've played around with the LUA code. I stripped everything out except the handling of the buttons I'm interested in. The core loop looks sorta like this: function Poll repeat com.read if queue was not empty then com.GetHidButtons if button state changed then ipc.writeUD end end until queue is empty I added some logging and what I found is that com.read does not see all the rotary encoder events, while other applications do. I had the FSUIPC console log and the "SV Mapper" tool (that's the tool to map MJ16 events to keystrokes) open side-by-side. Whenever "SV Mapper" sees a button event, it highlights the button. Slowly turning one of the radials, I could see the matching button blink-blink-blink in the same rhythm as the radial encoder was clicking. I expected to see one or two lines of output in the FSUIPC window per click: one line per click if the radial encoder alternates between press and release; two lines per click, if the radial encoder presses and releases the button for each click. It turned out that the latter is the case, so I saw two lines whenever a click registered. [I guess that means, at least in theory, that I should not have to assign "release" actions for the rotary encoder events.] I found that many of the clicks did not lead to a changed button state as seen by com.read. About half of the clicks are lost and never seem to end up in the queue that com.read reads from. And there's no rhythm to it, it's not every second click that gets lost. It's as if a coin was tossed for each click and if head comes up, the LUA script gets to see it, if tails comes up, the event is lost or invisible. I also checked with X-Plane (to make sure that "SV Mapper" isn't doing anything magic specific to the MJOY16 board), and it also registers every single click without fail. For reference, this is the code I used to test (so you can see I'm not the one throwing half of the events away, or maybe I am and you can point out my mistake)... function Poll(time) -- counters for logging cntread = 0 cntrad = 0 -- the radial encoder events are limited to button[4], so I got rid of the loop over all buttons, but I kept the index for convenience i = 4 repeat CurrentData, n = com.read(dev, rd) if n ~= 0 then buttons[1], buttons[2], buttons[3], buttons[4], buttons[5], buttons[6], buttons[7], buttons[8] = com.GetHidButtons(dev, CurrentData) if buttons[i] ~= prevbuttons[i] then prevbuttons[i] = buttons[i] ipc.writeUD(0x3344 + ((i-1) * 4), buttons[i]) cntrad = cntrad + 1 ipc.log(string.format("last button state: %4X", buttons[4])) end end cntread = cntread + 1 until n == 0 -- ipc.log(string.format("com.read called %d times, radial events sent %d, last button state: %4X", -- cntread, cntrad, buttons[4])) end Unless there's something wrong with my code, something appears to be wrong with com.read...? Confused as hell, Marc

This makes a major difference, the rotary encoders work more reliably this way, especially single "clicks", but they're still not "smooth". Every ipc.write is a distinct SimConnect call? I'll look into this. So the idea is, at a lower poll rate, to com.read (possibly repeatedly until the queue is empty), cumulate the deltas, read the current values of the FS controls, and then write them back once after applying the cumulated changes, to reduce the number of interactions with SimConnect? My device uses a rather obscure board ("MJOY16"), not Arduino. The Arduino solution you pointed to doesn't seem to be Open Source (and even if it was, it would probably outside my expertise to adapt it). There's a "buttons to keyboard events" mapper program (called "SV Mapper") for the MJOY16 board (of course not Open Source, bummer). After mapping the rotary encoder events to key combinations, I can assign those keys to FS functions using FSUIPC just fine, and pretty reliable and almost smooth. This could be indicating that, when using hiddemo.lua, the number of SimConnect calls is the remaining issue for me, as Pete suggested. Thanks for your help, I'm off to do some more experimentation! *puts on rubber gloves and protective goggles* Thanks, Marc

Hi Pete & everybody else, a few days ago, I had a weird issue accessing my controller with a couple of axes, a couple of buttons, and a set of rotary encoders from hiddemo.lua. Pete graciously fixed that issue for me in the latest FSUIPC release. Now I've hit the next obstacle: while the rotary encoders work in principle -- FSUIPC can see them, I can assign FS functions to them, and when I turn a rotary encoder to the left, the assigned thingie often moves to the left -- they don't work reliably and smoothly. I'm still experimenting with a stripped down version of hiddemo.lua; I removed the support for axes, but left the button logic mostly untouched. I only use the script for the rotary encoders of my controller (everything else is mapped directly in FSUIPC). I have to use LUA, because the rotary encoder events are mapped to button events beyond the first 32 buttons (in my case, buttons 96 to 111 - and those are the only events I'm interested in handling with LUA). My controller uses two kinds of rotary encoder hardware, "normal" rotary encoders and "wedding cake"-style dual rotary encoders. For both types of hardware, the output of my device provides four events when turning the rotary encoders: cw slow, cw fast, ccw slow, ccw fast. So I am not using the rotaries.lua script which "emulates" the "fast" events for devices that don't provide them. All the rotary encoders work in principle, I have assigned all the events to sim actions in FSUIPC's Button dialog. I'm having trouble making the rotaries behave as they should, though. This is what I expect: When I turn the rotary encoder assigned to the heading bug so it clicks once, I expect the heading bug to move by one degree. When I turn the same rotary encoder slowly so it clicks four times, I expect the heading bug to move by four degrees. When I turn the same rotary encoder fast so it clicks many times, I expect the heading bug to move quickly (using the "incr/decr fast" actions, skipping several degrees per action). This is what I'm experiencing instead: When I turn the rotary encoder assigned to the heading bug so it clicks once, most of the time the heading bug will not move, rarely will it move by one degree. When I turn the encoder so it clicks twice, most of the time the heading bug will move by one degree, sometimes by two degrees. When I turn the same rotary encoder slowly so it clicks four times, it will indeed move by three to four degrees if I find the correct turning speed. If I rotate the encoder too slow, it will move less than four degrees (sometimes not at all), if I turn too fast, it will start sending "fast" events and move more degrees than I intended. When I turn the same rotary encoder fast so it clicks many times, it works mostly as expected, the heading bug is moving quickly, but it doesn't seem to move as smooth as it should. I think this means I'm "losing" rotary encoder events, especially when turning the encoders slowly (let's define "slowly" as one to four "clicks per second"). The responsiveness of the rotary encoders is affected a lot by the Pollrate variable, I've tried a range of values from 10 (100ms) to 500 (2ms), I believe I'm seeing best results with 100 (10ms) or 200 (5ms), but pollrates that high seem like major overkill when the goal is to read 10 to 20 state changes per second. I tried using com.read instead of com.readlast. The number of lost events seems to decrease, but com.reads needs high pollrates (100 or higher) or it introduces major delays (ie. I turn the encoder and it can take a second or longer until something happens in the sim). But even with com.read, single "clicks" are often lost. The "wedding cake" dual encoders seem to lose more events than the "simple" encoders, not sure what that means. If I understand the docs for the com library, com.read reads fifo-style from a queue of events, while com.readlast reads the last value and discards the rest of the queue. And I assume that the queue is blowing up with all kinds of events from the controller, probably mainly axis events? If so, perhaps there a way to tell com.openhid or com.read to ignore controls I'm not interested in to keep the queue from filling up with their events? Caveat: At this point, I cannot be sure that the issues aren't at least partially caused by the hardware -- I have only tried the controller with P3D/FSUIPC so far, I should probably see if I can get it to work with X-Plane to check whether it has similar issues there. I would appreciate any wisdom you could share! Perhaps I should be using a different lua script? I searched the forum and read quite a few threads about issues with rotary encoders, but none seemed pertinent to my issue. Maybe someone can point me to the right thread? Thanks, Marc

Thanks, Pete, I appreciate it!

I understand why you would think that, but, in my case, the two devices (actually it's one physical device with two controller boards and two USB connections) really have two different PIDs (see log below). The wonders of homebrew devices. 🙂 Yes, I'm sure, I did not install any drivers or software for the devices. I plugged them in and they immediately showed up as "TRTL" and "MJ16" in Win's "USB game controller" dialog. They are handled by the default HID drivers that come with Windows. The only possible source for the identifiers "TRTL" and "MJ16" is the devices. Here's the log excerpt: 109 ---------------------- Joystick Device Scan ----------------------- 125 Product= Joystick - HOTAS Warthog 125 Manufacturer= Thustmaster 125 Vendor=044F, Product=0402 (Version 1.0) 172 GUIDs returned for product: VID_044F&PID_0402: 172 GUID= {5BBFA880-8594-11E6-8001-444553540000} 172 Details: Btns=19, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U0,V0,X65535,Y65535,Z0 172 Product= Control Manager ID #00 172 Manufacturer= Control Manager ID #00 172 Serial Number= Control Manager ID #00 172 Vendor=068E, Product=C0F2 (Version 0.0) 172 GUIDs returned for product: VID_068E&PID_C0F2: 172 GUID= {2B876BE0-E803-11E6-8001-444553540000} 172 Details: Btns=0, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U0,V0,X255,Y255,Z255 172 Product= 172 Vendor=0000, Product=0002 (Version 1.3) 172 GUIDs returned for product: VID_0000&PID_0002: 172 GUID= {B309EF20-A4C7-11E8-8001-444553540000} 172 Details: Btns=112, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R511,U511,V511,X511,Y511,Z511 187 Product= 187 Vendor=0000, Product=0003 (Version 1.3) 187 GUIDs returned for product: VID_0000&PID_0003: 187 GUID= {A82A1320-A4AC-11E8-8001-444553540000} 187 Details: Btns=112, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R511,U511,V511,X511,Y511,Z511 187 Product= Throttle - HOTAS Warthog 187 Manufacturer= Thrustmaster 187 Vendor=044F, Product=0404 (Version 1.0) 187 GUIDs returned for product: VID_044F&PID_0404: 187 GUID= {DF43BF50-8591-11E6-800A-444553540000} 187 Details: Btns=32, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R16383,U1023,V0,X1023,Y1023,Z16383 187 ------------------------------------------------------------------- 187 Device acquired for use: 187 Joystick ID = 3 (Registry okay) 187 3=Joystick - HOTAS Warthog 187 3.GUID={5BBFA880-8594-11E6-8001-444553540000} 187 Device acquired for use: 187 Joystick ID = 0 (Registry okay) 187 0=CH Pro Pedals USB 187 0.GUID={2B876BE0-E803-11E6-8001-444553540000} 187 Device acquired for use: 187 Joystick ID = 2 (Registry okay) 187 2=MJ16 187 2.GUID={B309EF20-A4C7-11E8-8001-444553540000} 187 Device acquired for use: 187 Joystick ID = 1 (Registry okay) 187 1=TRTL 187 1.GUID={A82A1320-A4AC-11E8-8001-444553540000} 187 Device acquired for use: 187 Joystick ID = 4 (Registry okay) 187 4=Throttle - HOTAS Warthog 187 4.GUID={DF43BF50-8591-11E6-800A-444553540000} 187 ------------------------------------------------------------------- In case you're curious, this is the device in question: I really appreciate your help, I understand that the trouble is caused by the unconventional approach the designers took with their homebrew solution and that I'm asking you to make FSUIPC work around their flaws. 😞 Thanks, Marc

Oh, one more thing: Windows displays unique names for the devices (in my case: "TRTL" and "MJ16"). The names indicate that they're indeed provided by the controllers ("TRTL" being shorthand for "throttle", "MJ16" for "MJOY16"). I have no idea whether there are additional information fields in the USB protocol which are ignored by hidscanner.exe while Windows can use them for device naming, or whether the creator of the MJOY16 board does something non-standard for the "Product" field which results in the field being parsed somehow by Windows while at the same time appearing empty to hidscanner.exe. Maybe those device names ("TRTL", "MJ16") could be used to identify the devices? I would be happy to provide debug information or a dump of the USB handshake or something like that; if you consider that useful, please just let me know what to do. Marc

Thanks for the advice (null string), I will try that tonight. I won't get my hopes up just yet, I do need the numeric PID, because I actually have two of those MJOY16 devices; and it seems likely that "" would match any of the other game controllers. Maybe VID='' and PID=2 (or PID=3, for the second device) will work to identify the device. I would appreciate a fix in FSUIPC5, I am indeed using the latest and greatest P3D. Thank you very much for your help, Marc

Hi, I'm using a controller based on some obscure (well, it seems more popular in Eastern Europe) homebrew board called "MJOY16". While it doesn't actually have more than 32 physical buttons, it does spread out the button events over the modern DirectInput range, so there are events that FSUIPC can't see without help. As I understand it, the way to go is to adapt hiddemo.lua to my needs, but I've immediately hit a snag. According to hidscanner.exe, the device appears to use a "fake" Vendor ID (0x0000) and empty informational strings: Device at "\\?\HID#VID_0000&PID_0002#7&8a8d5bc&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=0000, Product=0002 (Version 1.3) Manufacturer= Product= Serial Number= Usage Page: 1 Input Report Byte Length: 8 Output Report Byte Length: 0 Feature Report Byte Length: 0 Number of Link Collection Nodes: 1 Number of Input Button Caps: 3 Number of InputValue Caps: 10 Number of InputData Indices: 122 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 0 Number of Feature Value Caps: 0 Number of Feature Data Indices: 0 Buttons range 57 -> 96 at indices 56 -> 95 Buttons range 97 -> 112 at indices 102 -> 117 Value POV at index 96, range 0 -> 7, using 4 bits Value 0x01 at index 97, range 0 -> 7, using 4 bits Value U/RX at index 98, range -512 -> 511, using 10 bits Value Z at index 99, range -512 -> 511, using 10 bits When I try to open this device from hiddemo.lua, I get the message "Could not open HID": 1208422 LUA.0: beginning "C:\Lockheed Martin\P3Dv42\Modules\HidDemo.lua" 1208422 LUA.0: Global: ipcPARAM = 0 1208422 LUA.0: Global: Vendor = 0 1208422 LUA.0: Global: Product = 2 1208422 LUA.0: Global: Device = 0 1208437 LUA.0: Global: Logging = true 1208437 LUA.0: Global: Pollrate = 25 1208437 LUA.0: Global: Report = 0 1208437 LUA.0: Global: dev = 0 1208437 LUA.0: Could not open HID I'm not sure what I could be doing wrong this early in the process, so I wonder whether that com.* library might refuse to open the device because of the "special" Vendor ID or something like that? Is there anything I can do about that? Thanks, Marc