Matthew Twomey

Yes, this was the point of my post - if you take a look at lua.org, you'll see that os.time() typically returns time in seconds. This indeed appears to be the case in the interpreter you are using in FSUIPC. What I'm looking for is milliseconds. Thank you for the offset pointer, I didn't think to search the offsets doc for it as an alternative. That gives back milliseconds and that will work for me!

Looking through the FSUIPC Lua ref doc. I'd like to be able to get the current time in ms in a script I'm planning out. I believe Lua doesn't have a standard (os-independent) way to do this. Since you have event.timer in your exposed libs (as well as several other ms based functions), I'm guessing you've implemented this in c++ and you're calling something there in your Lua libs. I'm wondering if you'd consider exposing a plain old "get time in ms since the epoch" sort of function in one of your libs?

Note also erjdriver, that depending on your arduino - there are various libraries that can make it present as an HID joystick to your OS. At that point, you can use regular old FSUIPC to map it.

Yep fair enough. I'm really just exploring and getting my feet wet (I'm totally new to the FSUIPC world). I agree that the sim performance is paramount. Yes - it's a very handy feature and most of what I've tried out via Lua worked very well. I was just exploring and figuring out where the limits lay.

Makes sense. However I assume at the end of the day, FSUIPC's joystick scanning also uses a low level HID connection. So it's just weird that the regular scanning interface is able to retrieve the data without delay. --- Side question on bug reporting in general: Completely unrelated to vJoy (I actually completely removed it for now, during the course of testing we followed). Using a plain xbox360 controller, I'm also seeing some strange delays with axis values coming in when using com.gethidvalue. This is actually vaguely similar to the button issue. The reports coming in from com.gethidvalue "lag" behind, about .5 seconds, from the reports coming in via ipc.axis. They also seem to "queue up" - with new data coming in for a second or more after input changes have ceased. Now - I've simply switched to ipx.axis, so this isn't an issue for me. The real question is: Do you "want" bug reports such as these and if so, are forum posts your preferred way to receive them?

I went ahead and did this test. In my case, I only needed to clear one thing out of MSFS. I had actually already created a completely empty (zero assignments) controller profile in MSFS, so I switched back to that and completely wiped my FSUIPC ini and let it recreate fresh and free of any entries. I then just added the start and kill lua keyboard mappings and re-tested. Same results - when fed with my external feeder (UCR in this case) - event.timer+com.readlast picks up the event 350 - 500ms after event.button does. When fed with the vJoy example feeder they both pick up the event nearly immediately. So - yeah, it could be that the feeder I'm using isn't acting in a courteous manner. I don't really know much about the vJoy driver / interface - but maybe this feeder is opening it in some kind of exclusive mode or something along those lines. Or maybe it holds something open too long or neglects to signal something is complete. There must also be some difference in how FSUIPC is implementing event.button compared to what's happening with event.timer+com.readlast (e.g. why event.button is always fast). I probably will end up writing my own feeder for my project anyhow and I'm sure I'll learn plenty abut vJoy at that point. Thanks for the pointer on vjoyOffsets, I had no idea that existed and that should come in very handy. Yep - thank you for your time, I enjoyed our conversation. -Mat

Ok - here are my findings with vJoy so far. I've narrowed the difference down to specifically what is feeding vJoy. Take a look at this analysis: As with the earlier tests, a single button press is listened for by both an event.button and an event.timer (firing every 25ms). Something different happens when I feed vJoy with some external programs I'm working with. When I use the demo feeder for vJoy, the issue does not occur. This, I can work around by writing my own feeder. This leaves one open question though: In the case of the external feeder for vJoy, Why is event.button able to pick up and process the button press quickly, while event.timer is not (as shown in the first three pairs in that chart)? More a curiosity than anything else at this point and perhaps just something for all to be aware of going forward if they use vJoy. I am more than happy to continue exchanging notes and troubleshooting on this (I kind of enjoy mysteries like this). However, it's starting to look like more of a niche issue at this point. So if you want to move past it, I totally understand. I really appreciate you working with me and sharing your findings as well as we went along :-) -Matt

Oh that's a good find / thought about testing without MSFS running. It took me a minute to figure out I could assign a key to start the script instead of relying on [Auto], which won't spin up until it detects a plane. I did this same test - a couple of observations: 1. The event.button event isn't firing at all for me without MSFS running, but the event.timer does fire. This means I can't measure the exact delta between the two. However - I can visually see that event.timer is responding in a similar slow fashion - which does not match your observation. 2. The first time I tried this, I had copied your lua script from your last post and I forgot to change the HID device. So I ran it with an invalid HID device. In this circumstance, it responded quickly with no perceivable delay. However once I put my HID values in there, it returned to responding slowly. -- Important new find! I did some tests with some different devices and this issue appears to present only with the vJoy device. I'm doing further testing here on versions of things, vJoy settings, ...etc. This still doesn't explain why event.button catches a button press (on vJoy) immediately, but event.timer does not... More to come....

First - I'm in no rush, so please enjoy your weekend and time. When you do look back on this, I think I've got the info you mentioned in this post as well as some additional analysis of my own. So I am running a pretty clean / cleared out setup while testing here. I have nothing at all mapped or assigned except a single button to kill Lua. I've attached my ini file here (FSUIPC7.ini). Vendor 0x1234 and device 0xBEAD are the default identifiers for a vJoy virtual joystick. I've also attached a log with your suggested tracing enabled (Example-Event-Timer_Slow.log). This is a log running Example #2 - event.timer approach (Slow) listed in my post above. Timestamp 17922 in this log shows the first time the event is captured. I've also noticed this event.timer is only firing about 9 times per second, but it's unclear to me if it's the debug logging that's slowing it down. I did a second experiment which I find more interesting: Example #5 - event.time AND event.button handle, rd, wrf, wr, init = com.openhid(0x1234, 0xBEAD, 0, 0); function processButton() local data, n = com.readlast(handle, rd); if (n > 0) then local buttonState = com.testhidbutton(handle, 2, data); if ((buttonState == true) and (previousButtonState == false)) then ipc.log("##### Timer Trigger: Button 2"); ipc.control(66300, 0); -- Toggle engine 1 switch end previousButtonState = buttonState; end end function processButton2() ipc.log("##### Button Event Trigger: Button2"); end event.timer(25, "processButton"); event.button("A", 2, "processButton2"); ipc.log("Started up"); I've left the timer functioning as it was from Example #2. I added an ipc.log line to make it even more obvious when it registered button 2 being pressed via event.timer. In addition, I added a button event which triggers on the same button. Button events work as I would expect them to - they process very quickly, with no perceivable delay. I also added a log line for event.button being fired. With this setup, I see the following in the log: In this experiment, I see the first highlighted line in that image is the log message indicating when the event.button was fired. However, we see 5 more full cycles (of event.timer) and 578ms go by before the second highlighted line, which is when event.timer caught the exact same button press. I also attached the full log from this experiment to this post (Example5.log) - this log is a little messy though, there are some other things in it. I can create a clean one if you'd like me to. Also I tried disabling debug logging completely (in case that was affecting it). The significant delay between these two is still present (each pair of entries in this screenshot represent a single button press): Thanks, -Matt

My apologies about the forums misplacement (will go there going forward), I'm a little new to the FSUIPC ecosystem. I didn't realize that parts of FSUIPC were fundamentally different in the V7 Beta (although I suppose I might have guessed that because I had read somewhere that it is "new" that this V7 version runs "stand alone"). Yes, I've done extensive tracing to the extent that I can do so through FSUIPC's logging capabilities as well as logging and timing within my own code and the examples above. I have not attempted to do any tracing of FSUIPC itself, e.g. windows process level snooping and debugging (although I suspect that's not what you mean). As best I can tell, it appears to me that data is delayed on its way to the buffer that services com.read* (or even earlier). In the case of the event.com solution, I'm not even calling com.read - so that leads me to believe that the data is delayed on its way to wherever the implementation of event.com is getting it from (sorry, I don't know the internal architecture of the FSUIPC lua libs).

Incidentally, using the HidDemo.lua the delay is also evident in the FSUIPC UI. If I go in to assign an axis on Joy#16 (which HidDemo maps to), each time I physically push the axis there is about a one second delay before it responds in the FSUIPC axis assignment display:

Hi there and thanks. Yes - I'm starting the plugin via [Auto]. I am new to FSUIPC so I don't have any past experiences to compare with. I am using the beta version against MSFS2020. I'm both a developer and a microelectronics hobbyist - so I'm really just learning the ropes with FSUIPC at this point. I've started working on some hardware projects and have various ideas I'd like to experiment around working with "chorded" controls and combinations of switches + axis values and the processing of these. I was in experimentation mode yesterday and that is how this question came up. I'm more trying to understand what possibilities and / or limitations I might face using the Lua interface. So I've done a little more testing with this. I've included 4 small (but complete) examples below. The only one that responds "quickly" is the event.button based solution (however, I'd really like to get a solution that can act quickly and be constantly monitoring the input data - like the event solution or the timer solution). Each example was loaded (only one at a given time) via the [Auto] section of the ini. Example #1 - event.com approach (Slow) handle, rd, wrf, wr, init = com.openhid(0x1234, 0xBEAD, 0, 0); function processButton(handle, data) local buttonState = com.testhidbutton(handle, 2, data); if ((buttonState == true) and (previousButtonState == false)) then ipc.control(66300, 0); -- Toggle engine 1 switch end previousButtonState = buttonState; end event.com(handle, rd, rd, "processButton"); ipc.log("Started up"); Example #2 - event.timer approach (Slow) handle, rd, wrf, wr, init = com.openhid(0x1234, 0xBEAD, 0, 0); function processButton() local data, n = com.readlast(handle, rd); if (n > 0) then local buttonState = com.testhidbutton(handle, 2, data); if ((buttonState == true) and (previousButtonState == false)) then ipc.control(66300, 0); -- Toggle engine 1 switch end previousButtonState = buttonState; end end event.timer(25, "processButton"); ipc.log("Started up"); Example #3 - Hard Loop approach (Slow) Impractical, but just as a test (it's still slow) (I was quite surprised this one was slow) handle, rd, wrf, wr, init = com.openhid(0x1234, 0xBEAD, 0, 0); function processButton() local data, n = com.readlast(handle, rd); if (n > 0) then local buttonState = com.testhidbutton(handle, 2, data); if ((buttonState == true) and (previousButtonState == false)) then ipc.control(66300, 0); -- Toggle engine 1 switch end previousButtonState = buttonState; end end ipc.log("Started up"); while (true) do processButton(); end Example #4 - event.button approach (Fast) This is the only one that acts quickly handle, rd, wrf, wr, init = com.openhid(0x1234, 0xBEAD, 0, 0); function processButton() -- ### Leaving this code in here to execute just to test if there is anything in here slowing things down ### local data, n = com.readlast(handle, rd); if (n > 0) then local buttonState = com.testhidbutton(handle, 2, data); if ((buttonState == true) and (previousButtonState == false)) then --ipc.control(66300, 0); -- Toggle engine 1 switch end previousButtonState = buttonState; end -- ### End test code ipc.control(66300, 0); end event.button("A", 2, "processButton"); ipc.log("Started up"); As suggested, I also fired up and tested HidDemo.lua with the only modification being to the Vendor and Product IDs (to match mine). This behaved the same as tests 1 - 3, about a one second delay before acting on anything. So I'm both curious what's happening here and willing to do any tests or debugging (I'm happy to go quite deep into it if needed), if that can help or if I can be of any use on this. Thanks, -Matt

This is more of a learning exercise than a problem. I realize there are events specifically for buttons, however in my experimentation today - I became curious why this code is firing so slowly: dev, rd, wrf, wr, init = com.openhid(0x1234, 0xBEAD, 0, 0); previousButtonState = false; -- Track this to prevent repeatedly firing function processButton(handle, data) local buttonState = com.testhidbutton(handle, 2, data); if ((buttonState == true) and (previousButtonState == false)) then previousButtonState = true; ipc.control(66300, 0); -- Toggle engine 1 switch end if ((buttonState == false) and (previousButtonState == true)) then previousButtonState = false; end end event.com(dev, rd, rd, "processButton"); ipc.log("Started up"); When I assign this button directly in the UI, it fires basically immediately. When I instead monitor for the button press with this script, it has nearly a 1 second delay before it fires. I'm just getting my feet wet with FSUIPC, so I'm in learning mode - so I'm curious if I'm misunderstanding something here about how to efficiently process inputs via Lua. Thanks, -Matt

Perfect, thank you.

Just digging into Lua a bit and before I get too far, I wanted to understand how FSUIPC loads these. I'm not concerned at all with the startup time of FSUIPC, but for repeating functions I wanted to understand if they're being re-compiled anew on each execution. If so, no problem - but I may wish to plan on pre-compiling them.

John - confirmed. The wildcard translates to block 0 - 39 and 32-39 are now indeed blocked. Thank you sir! -Matt

Thanks John! I gave this a whirl. The X.* format in the buttons ini section did work as expected, once I launched FSUIPC, it was converted to individual X.0, X.1, X.2... Those buttons were blocked as well. The total range of buttons it converted to was 0 - 31. It still wasn't able to block 32 - 39 though. I manually added 32 - 39 into the ini file, but still no block there.

Thank folks. No worries on this, the workaround is working. However if you do plan to implement something for completeness / convenience and you'll be digging into this area code-wise, I'll also point out that the ignore doesn't appear to work for buttons that are detected as >31. For example see the button in this screenshot, which should be ignored from this line: [Buttons] IgnoreThese=B.32, B.33, B.34, B.35, B.36, B.37, B.38, B.39, B.0, B.1, B.2, B.3, B.4, B.5, B.6, B.7, B.8, B.9, B.10, B.11, B.12, B.13, B.14, B.15, B.16, B.17, B.18, B.19, B.20, B.21, B.22, B.23, B.24, B.25, B.26, B.27, B.28, B.29, B.30, B.31 PollInterval=25 ButtonRepeat=20,10 Button 34 screenshot

What I mean here, is the issue is during the setup / assignment process in FSUIPC. When I'm setting up the assignments, FSUIPC latches on to either the physical or the virtual inputs, it's semi-random which one it's going to take. So for example, I want to assign virtual controller button #8 in FSUIPC. That button (on the virtual controller) gets pushed when I hold down a combination of buttons #6 + button #5 on the physical controller. So when I'm trying to assign button #8 on the virtual controller (in FSUIPC), it's difficult because the "detection" in FSUIPC might "capture" button #6 or button #5 on the physical controller - instead of button #8 on the virtual controller. Once the assignment is correct in FSUIPC, everything works fine - it's just the process of assigning that is difficult. So it's just the assignment process - which I was suggesting would be made easier if I could tell FSUIPC to just ignore the physical controller, or ignore a controller with a given UUID.

The main issue I was having is in the "detection" done by fsuipc. In the case of a physical controller mapping to a virtual controller, both inputs are coming in at (roughly) the same time. So there's basically a race condition on which FSUIPC is "locking on" to. Essentially I am never working with the physical controller in FSUIPC, so it's just getting in the way. The IgnoreThese suggestion works though as a workaround for what I'm trying to do. Basically I can ignore most of the controller with these lines: [Axes] IgnoreThese=A.Y,A.X [Buttons] IgnoreThese=A.0, A.1, A.2, A.3, A.4, A.5, A.6, A.7, A.8, A.9, A.10, A.11, A.12, A.13, A.14, A.15, A.16, A.17, A.18, A.19, A.20, A.21, A.22, A.23, A.24, A.25, A.26, A.27, A.28, A.29, A.30, A.31 So that gets me where I need to be on my end :-) It would be nice to just be able to ignore a designated controller wholesale (feature request) - however, I do understand this may be more of an edge case. Thanks all for the help and input! -Matt

The software that creates the outputs for the virtual controller is taking inputs from a physical controller (among other possible sources), "doing stuff", then creating outputs to a virtual controller. FSUIPC detects two different controllers, one virtual and one physical. However when I hit a button on the physical controller that is mapped to the virtual controller, FSUPIC is seeing both of these and it's unpredictable which one it's going to pick. For this reason, it would be helpful if I could just tell FSUIPC to simply ignore the physical controller. As an example - I might have my physical controller mapped so that when I hold down a combination of two buttons on the physical controller, a single specific button gets pressed on the virtual controller. What I want to map with FSUIPC is the virtual controller, but it's also seeing the two button presses on the physical controller and it's unpredictable.

I'm trying out the FSUIPC7 beta and a question came up: I'm working with a situation where I'm using some virtual controllers in addition to actual physical controllers. In some cases I'd like to map buttons from a virtual controller via FSUIPC. However, in these cases the physical controller is still present and hitting buttons on that physical controller translates to a button press on both the physical controller and the virtual one. This can make it difficult when FSUIPC is detecting button presses. So I'm wondering if there is a way to tell FSUIPC to just completely ignore certain controllers?