Jump to content
The simFlight Network Forums

Blake Buhlig

Members
  • Content Count

    22
  • Joined

Community Reputation

2 Neutral

About Blake Buhlig

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Location
    US

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. After making Line 42 of LIP.lua look like... local param, value = line:match('^([%w|_%.]+)%s-=%s-(.+)$'); -- Added "%." to the line:match() argument ...the below function seems to work for me. function _convert_joy_letter_to_num(ltr) local LIP = require 'LIP' local ini = LIP.load('FSUIPC7.ini') local guid, key, value for key,value in pairs(ini.JoyNames) do if key == ltr .. ".GUID" then guid = value end end for key,value in pairs(ini.JoyNames) do if value == guid and key ~= ltr .. ".GUID" then return key:gsub(".GUID","") en
  2. I found https://github.com/Dynodzzo/Lua_INI_Parser which seems could be a start. Not completely working, but hopefully won't take too much more work. local LIP = require 'LIP' local ini = LIP.load('FSUIPC7.ini') ipc.log('DEBUG ini.JoyNames.B:') ipc.log(ini.JoyNames.B) ipc.log('DEBUG ini.JoyNames.B.GUID:') ipc.log(ini.JoyNames.B.GUID) 15562 LUA.4: DEBUG ini.JoyNames.B: 15578 LUA.4: Bravo Throttle Quadrant 15594 LUA.4: DEBUG ini.JoyNames.B.GUID: 15594 LUA.4: <bad string>
  3. This has come up for me in a couple other contexts, for instance I want to set/clear the button flags on one of my buttons in certain circumstances when a different button is pressed. The C1003 and C1004 controls are there for this but I can't pass in a JoyLetter based parameter. I appreciate the getJoyNum code suggestion and can probably figure a way to ensure some other button on the joystick gets pushed first. But I wonder if parsing the INI in Lua wouldn't be all that difficult, or if it hasn't already been done maybe for some other purpose.
  4. event.cancel("vlc") executed inside the vlc() function should do it.
  5. I just noticed, User Contributions - The simFlight Network Forums now says "Topic was moved to forum FSUIPC Support Pete Dowson Modules". But I intended it as a contribution to Honeycomb Bravo FSUIPC users, not as anything related to a support request.
  6. I wanted something like TripleUse.lua to overload the trigger button on my Alpha, but not finding that it or anything else I ran across did what I wanted, I wrote my own. https://raw.githubusercontent.com/bbuhlig/fsuipc-contrib/main/ovrldbtn.lua The basic supported pattern is a train of consecutive button clicks, and a variant is the train of clicks except with the final click continuing to be held down. Different actions are signaled by changing the length of consecutive clicks or click-and-holds. For example, the actions on the overloaded button as noted below left, could trigger th
  7. Below is the post with the code I wrote for managing these two controls. I'm not entirely happy with it and may tweak it later, but I've shifted my attention elsewhere at least for now. lua event-based fast/slow button generator for rotary switches - User Contributions - The simFlight Network Forums
  8. https://raw.githubusercontent.com/bbuhlig/fsuipc-contrib/main/rotfsev.lua The above is what I wrote to manage slow vs. fast rotation of the inc/dec and trim wheel on my Honeycomb Bravo. While not perfect, it's the best I've been able to manage so far given the apparent inability of these rotaries to detect button presses faster than ~95ms. This module monitors a set of rotary switches for fast vs. slow toggling based on a user provided threshold between successive button events. If the rotary is moved fast enough that consecutive button events are received within a threshold, a fast
  9. I filed a support request with Honeycomb. Who knows, maybe they'll say the 60ms-70ms delay is from a conservative debounce algorithm implemented in their firmware, and could be tweaked with a firmware upgrade. Why do you suggest that? Especially for the inc/dec, I'm sending different controls depending on the position of the Alt/VS/Hdg/Crs/IAS selector, that I expect will need to vary depending on selected aircraft. All manageable with virtual buttons and different profiles, not so much if I have to do it all in lua. I don't understand this either? Logically the button r
  10. Thanks, yes, you are describing what I see. That long fixed delay before rotary button release is really frustrating. I saw no difference with C++ polling the button state every microsecond, so I'm convinced that delay is a result of the device's hardware or firmware. I'm still playing around with lua code that does what I suggested in my last message, and includes things along the lines of what you suggest. While so far it does make it somewhat more usable, it's not yet enough for me. The rotaries are one of the main reasons I bought the Bravo, and given my electronics background I've co
  11. 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 F
  12. 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.
  13. 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 w
  14. 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
  15. 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 betwe
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.