Blake Buhlig

Maybe, sort of. I was really trying to get a rapid spin of the rotary in a given direction to generate a single "fast" virtual button click, and since a single rapid spin of the rotary will generate some number of button clicks happening less than the "FastTimeLimit", I guess it's a matter of detecting a minimum number of those happening, then generating the "fast" event, then ignoring any follow-on clicks until none are received for the duration of some timer. Similarly I want slower turning to generate a slow virtual button for each click, so when I get a button press I'd need to wait for FastTimeLimit to pass before sending the slow virtual button. Before the C++ tangent, I had spent quite a while with a Rotaries.lua like approach and couldn't get it to work well, but maybe I only need to incorporate mods to ignore the button release. In terms of the Rotaries.lua code, it seems "Diff = logic.Xor(Buttons, PrevButtons)" would need to become "Diff = logic.And(Buttons, logic.Not(PrevButtons))" so that it ignores button releases, and then the "FastTimeLimit" would need to be doubled, e.g. default 80 would become 160. 95ms between button presses was the minimum interval I saw, so maybe it could be reduced to something like 120ms to minimize the slow button expiration timer yet still have a range where fast clicks would be reliably detected. I guess I'd just have to try. Since I'd already have the expiration timeouts to deal with, for even the initial button detection I wonder if it would be cleaner to use event.button instead of polling.

For me regular reliable behavior moving the switches slowly is as important as moving them fast so I'll probably need to continue ignoring the release event, and differentiate fast vs slow operation with some sort of compound button assignment. Maybe someday I'll open it up and try to find a DIY mod for processing those switches.

That's what I was expecting to be true but it's not what I'm observing with my C++ program that polls the Bravo button states in a loop with only a 1 microsecond delay each time through the loop. For the Bravo inc/dec, each click is a press and a release. Regardless of how fast the rotary is turned, the release comes around 60-70ms after the button press. When rotating it fast, the next button press comes 20-30ms after the button release. For the trim wheel, I can't discern any tactile or audible feedback about when the presses happen. But the behavior is generally the same in that while rotating the wheel at different speeds will cause the button presses to come at different frequencies, once the button press comes a button release always happens 60-70ms later, with the next button press coming no sooner than 20-30ms after that.

Thanks, I did tweak those parameters but to no effect. I then went down the C++ path and found even that way that I could get neither the inc/dec nor the trim wheel to detect an interval between button presses shorter than 95ms which is about what I was seeing with lua. For the inc/dec I know each audible click corresponds to one button press so when spinning it as fast as I was doing, I was expecting an interval between button presses maybe in the 10-30ms range. So it would seem a more fundamental limitation with the device itself keeps detectable events from being triggered that quickly.

Thanks John. The two rotaries I had in mind are the inc/dec and the trim wheel. As far as performance, what I'm after on the inc/dec is to be able to grab it with my thumb and index finger then roll or cross them as quickly as I can to ideally result in a single "fast" virtual button. In doing this I'm rotating the knob so quickly that it makes a "zzzz" sound where my ear can't distinguish the individual clicks made by the rotary. About where I can distinguish those clicks is where I'd prefer each click to generate a "slow" virtual button. I couldn't get the Lua based code to distinguish between fast and slow in that sense, presumably Lua is just too slow for that As far as SFML, I'm not experienced in development involving Windows USB devices and had run across a post suggesting using basic Windows APIs to do so is a lot more complicated than it needs to be. So I web searched for a free wrapper library with good docs and an apparently active support community, and SFML seems to fit the bill; web searching "SFML Joystick" quickly brings up the relevant API I'm interested in. That's the only thing I'm interested in so certainly possible it's overkill, and I'm open if you have simpler suggestions. Seems my first step is to get some C++ program that can detect my conditions, then hook it up to the FSUIPC SDK as a second step. It will be a while before I get there, but can you clarify that I want the zip file linked under www.fsuipc.com? The description didn't mention FSUIPC7 so at first I overlooked it. Thanks again. -Blake

For my Bravo's two rotary controls, I've tried both a Rotaries.lua type of approach as well as a Lua event-driven approach, finding neither works well enough to my liking. As suggested at https://forum.simflight.com/topic/92381-basic-question-to-start-a-lua-plugin/?do=findComment&comment=560588, it seems like the way to go for this sort of thing is rather some C++ code that runs faster than Lua to sense more rapid changes in the rotaries, and somehow feed that information back into FSUIPC. One thought I had was to write a DLL using something like https://sfml-dev.org that implements a function that would block until a fast-vs.-slow rotation of a rotary switch was detected, then use luacom to interface to that function from Lua. Or I suppose another way would be maybe a .EXE that polls the rotaries and writes appropriate information into an offset accessible by FSUIPC, but I've not yet discovered the details about how one might go about writing an FSUIPC-accessible offset. Any suggestions? Thanks, -Blake

I managed to snag a Bravo this week without paying more than MSRP. Whoo hoo! Anyway, as an aid for hand-editing FSUIPC7.ini for compound button assignments, here's a picture of the button codes showing up for me when running FSUIPC v7.1.0f.

I completely overlooked the Lua Library docs saying you can pass a joyletter to event.button. That's all I need to do and indeed it is working for me. Thanks and sorry for the noise.

In Lua, can I discover what joystick number is associated with a given JoyName? My Honeycomb Alpha will likely always have JoyName "A" but will likely get different joystick numbering as the USB port it gets plugged into varies. I looked through the manuals and searched through forums but didn't see anything. Context is I'm fashioning a Lua plugin similar to TripleUse.lua that turns the trigger button into a shift key. Basically, sending a held keypress for "click-and-hold" but being a compound modifier for "double-click-and-hold, a different compound modifier for triple-click-and-hold, etc. Thanks for the support.

As an aid for hand-editing FSUIPC7.ini for compound button assignments on my Alpha, I looked everywhere I could think of for a concise picture that showed the codes associated with each button, but I couldn't find any so I made my own picture and saved it at this link. These are valid for me as of FSUIPC v7.1.0f.

Thanks, after installing 7.1.0f I now see the R position coded as Btn# 31 regardless from which direction it's transitioned.

I'm a new user for both the Honeycomb Alpha and FSUIPC7, so I downloaded and installed 7.1.0b for support of the mag switch. In the Button & Switch Assignments popup, when I move the mag switch to R from Off, it does display 31 for the Btn# field as expected. But when I move it to R from L (in other words, from the opposite direction), it displays 255. I haven't yet tried actually configuring both 255 and 31 with the "Magneto Right" control -- maybe it would work -- but I wouldn't think this behavior is expected. Here's a link to an animated gif of the popup when I move the switch rightwards, from Off to R then L then Both then Start; then rightwards to Both then L then R. The 255 code for Btn# only shows up when moving from L to R. All the other Btn# codes seem correct to me. FWIW, here is a gif showing the codes returned by all the buttons. Thanks for the support.