Jump to content
The simFlight Network Forums

Blake Buhlig

  • Posts

  • Joined

Everything posted by Blake Buhlig

  1. There are lots of ways to do this probably. Have you tried something like if self:isUp() and GearHandleIsDown:isFalse() then set_gear_led(self._led,GEARIND_OFF) elseif self:isDown() and GearHandleIsDown:isTrue() then set_gear_led(self._led,GEARIND_GREEN) else set_gear_led(self._led,GEARIND_RED) end
  2. My code expects that offset to be non-zero when the gear handle is down, and zero when the gear handle is up. I meant this. If you want, you can just download that version from here.
  3. In the code, everywhere it says "GearIsRetractable:isTrue()" you could change to "true". The downside is that you will get the LED behavior even on fixed gear aircraft. Which drove me crazy on the initial version of this I came up with, hence I added that support. But is does require a functioning offset that reports the aircraft's gear type, looks unsupported in either that aircraft or that FSUIPC .
  4. The function at line 303 should get called on any relevant state change, like moving the gear handle. You could uncomment the logging code at line 304 and monitor the log, to learn what the state variables are at those events.
  5. I'm not sure how you are downloading it, but you could try https://raw.githubusercontent.com/bbuhlig/fsuipc-contrib/main/bravoleds.lua in a browser tab, then right-click "Save As..." to save it to a file. That's the link that comes up when I press "Raw" on the https://github.com/bbuhlig/fsuipc-contrib/blob/main/bravoleds.lua screen.
  6. Maybe add a simple line like ipc.log("Hello") at the beginning of bravoleds.lua then confirm "Hello" shows up in the log file? That way you could at least know if it is running. I'm running FS2020 and FSUIPC7. I'm unfamiliar with FS2004 or FSUIPC 3 so can't attest to whether the offsets my code uses would be compatible.
  7. @John Dowson, I uploaded a new version with which I was able to get it to run quickly from a fresh clone. Let me know any issues. Thanks, -Blake C:\Users\bb-mi\test>git clone https://github.com/bbuhlig/fsuipc-contrib Cloning into 'fsuipc-contrib'... remote: Enumerating objects: 92, done. remote: Counting objects: 100% (92/92), done. remote: Compressing objects: 100% (52/52), done. Receiving objects: 100% (92/92), 89.98 KiB | 1.23 MiB/s, done. remote: Total 92 (delta 51), reused 79 (delta 38), pack-reused 0 Resolving deltas: 100% (51/51), done. C:\Users\bb-mi\test>cd fsuipc-contrib C:\Users\bb-mi\test\fsuipc-contrib>copy "..\..\OneDrive\Documents\FSUIPC7\Controls List for MSFS Build 999.txt" . 1 file(s) copied. C:\Users\bb-mi\test\fsuipc-contrib>python gen_ini.py [Buttons] PollInterval=25 ;a340 ButtonRepeat=20,10 ;a340 IgnoreThese=B.12, B.13, B.21, B.22 ;a340 1=PA,12,C67175,0 ;a380 2=PA,13,C67174,0 ;a381 3=PA,14,C67173,0 ;a382 <snip>
  8. Very well, thank you. I realized I should add the Mobiflight MIT license to the TSV file since it too is a derivative product. Once that is done I will upload both to GitHub.
  9. Hi @John Dowson, thanks for checking this out. I tried to document the background on that file at line 88 of gen_ini.py. The file is supposed to be a mapping between control IDs and names for custom MobiFlight events, generally formatted like what you provide for the standard controls in Controls List for MSFS Build 999.txt. The python library function I wrote tries to parse files of that general columnar format into enums, such that whatever python button mapping code one might write can easily reference the controls by name. For the purposes of demoing this, I attached the version I came up with. I created it by a couple of scripts. First, cip_to_evt.py converts the full MobiFlight CIP file to a set of custom *.evt files. Second, gen_custom_ctrls_info.py parses those *.evt files, along with the resulting FSUIPC7.ini EventFiles section , to derive the corresponding custom control IDs that would need to appear in FSUIPC7.ini button mappings. Additionally, I noticed the CIP file had the controls organized into "groups", and I thought that was just useful information to have in a third column in the info file, therefore the gen_custom_ctrls_info.py file also reparses the CIP file to extract the group info. In wanting to keep it easy to import into a spreadsheet even with a third column, I delimited the columns with tabs rather than spaces, which is why it has .tsv -- tab-separated values -- in the filename. Note the attachment should only be considered a demo as it is based on my own setup. Specifically for the assignments it generates to actually work properly for anyone, they would need to have setup a proper custom control config (e.g. WASM module installation), account for any other custom *.evt files they might have installed, add in various lua modules I reference that e.g. map fast rotary encoder spins to virtual button presses, etc. Once the attachment is copied in, gen_ini.py will probably get past that point then die at line 117 looking for file fsuipc_controls.txt. This one is intended to be a parsable file of similar format as the other two txt files, to generate enums for all the special controls documented in the Advanced Users Guide, pp.26-32. I generated that file by manually copy/pasting the PDF text, manually removing page numbers that were embedded in the copy, and manually replacing various copied Unicode characters that Python was bombing out on e.g. the curly quotes. Unlike the custom controls file, I wouldn't expect this file to differ between users so I could distribute it, but it is a direct derivative from the documentation so I wanted to get your permission first. I wasn't planning on a config file as such. The essential contribution I'm offering is the library under the fsuipcini directory, to be used by a python coder in generating sections of the FSUIPC ini. The gen_ini.py is my attempt in using the library to generate button mappings for my own setup, and I contributed it only as a demo usage of the library. Certainly one could adapt it for different file locations, paths etc., extend it to take a config file etc., but even after dealing with the file path issues I expected someone else would want to tweak the btnmap() calls throughout to map whatever control to button mappings particular to their own setup. Your attempt to use this does make me recognize I need to provide more out of the box to get gen_ini.py to run even as a demo, which in my original post I incorrectly suggested it would. So especially if you give me permission to add fsuipc_controls.txt, I can do so to lower the entry barrier for people to do that. As far as other general usage instructions, at this point I can only offer the code itself such as it is, but over time and if enough interest I can add more documentation. On that note this is definitely still under development and likely will continue to be until I ultimately come up with button assignments for my Alpha/Bravo-based setup that I'm satisfied with. I contributed it early both trying to get a feeler from people whether a framework like it could be useful -- e.g. are there python coders out there with complex button assignment needs? -- or even more fundamentally get feedback whether what this is trying to do might already exist in some other form. Another thing occurring to me is, maybe people could be interested in the actual assignments I come up with tailored to the Alpha and Bravo hardware. I'm happy to contribute that once I have it but as mentioned, I'm very much still working on it. I expect that contribution would mainly be in the form of output from whatever my final gen_ini.py is, though maybe with the source also included as a reference. Appreciate comments, thanks!
  10. Testing a bit more, I found and fixed a few issues and uploaded another version. I don't have plans to touch it again unless someone finds something wrong with it. Happy father's day!
  11. Sorry about that, I think I added the GearIsRetractable support because the gear LEDs were lit in some fixed gear aircraft I was using and I was annoyed by that. And then I don't think I've been in any retractables lately to notice the bug. In fixing it, I also took the opportunity to refresh the code with some new OO ideas as my Lua knowledge is growing, and uploaded it to the same link. It's working fine for me so far albeit I still need to test the autopilot LEDs.
  12. A while back, I had written my own version of code controlling the Bravo LEDs, ref below. Given that I know controlling the Bravo LEDs should just be a matter of sending the proper strings to the USB HID interface through com.openhid and com.writefeature. Assuming your version of FSUIPC supports those Lua calls, it should work. ,
  13. Similar to what CoolDanLuke had provided, some time back I wrote a Lua plugin that controls the Bravo LEDs, though in my case I hooked it up to various FS2020 offsets so that the LEDs more reflect the simulator state. https://github.com/bbuhlig/fsuipc-contrib/blob/main/bravoleds.lua Though, my attention is presently focused more on VR flight simming, and as such I can't see the LEDs to care much about them. But the code could at least be a reasonable place for interested others to start.
  14. I wrote a Python module to generate FSUIPC button mappings, once I realized the complexity of them that I was moving toward was going to make it hard to directly look at/manipulate the INI. For example usage and details, see https://github.com/bbuhlig/fsuipc-contrib/blob/main/gen_ini.py . Actually using it would require a suitable Python >=3.7 environment. The Python module consists of a number of files in my https://github.com/bbuhlig/fsuipc-contrib repo, so I recommend downloading or cloning the entire repo. Once setup just run gen_ini.py without arguments to print out an example Buttons and Buttons.twin section suitable for copy/pasting into an FSUIPC7.ini file.
  15. 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","") end end return nil end ipc.log("JoyLetter B is JoyNum " .. _convert_joy_letter_to_num('B')) Output: 16422 LUA.4: JoyLetter B is JoyNum 2
  16. 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>
  17. 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.
  18. event.cancel("vlc") executed inside the vlc() function should do it.
  19. 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 the corresponding actions below right. - single click and release : reset view - single click and hold : transmit voice while held - double click and release : toggle view zoom - double click and hold : enable 2nd use of other buttons while held - triple click and release : toggle internal/external view - triple click and hold : enable 3rd use of other buttons while held Each click and release sequence toggles a different virtual button, to which you can assign in the INI file like any physical button. Similarly each click and hold sequence will press a virtual button during the hold and will release the virtual button once the overloaded joystick button is released. Upon detecting a particular sequence, the module will play a short audio WAV file as feedback to you about what it detected. As an example, in my setup I generated generate morse code WAV files from https://www.meridianoutpost.com/resources/etools/calculators/calculator-morse-code.php per the below table, so that the dit's and dah's correspond to the sequence of clicks and holds. Letter Morse Code Representing === ===== ====================== E . single click T - single click-and-hold I .. double click A .- double click-and-hold S ... triple click U ..- triple click-and-hold H .... 4x click V ...- 4x click-and-hold 5 ..... 5x click 4 ....- 5x click-and-hold Then, one final sound: the WAV file "ovrldbtn.wav" is played on startup of the framework, as an indicator the framework is ready and as a test of the sound system. For my 'ovrldbtn.wav', I used the aforementioned website to generate a morse code WAV file that plays the word "ready".
  20. 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
  21. 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 virtual button is sent and successive button events are ignored. Otherwise a slow virtual button is sent for each button event if consecutive events are not received within the threshold. If your device is "glitchy" and regularly generates spurious fast events even when turning the rotary slowly, you can tell the module to treat a configurable number of fast events received within a time period as slow events. Each virtual button can be assigned in the .ini to send FS control commands and keypresses, such as variable rates for trim adjustments on an elevator trim wheel, ref p.25 of the Advanced User's Guide. This module provides a generally similar concept to the Rotaries.lua approach but takes advantage of buttons that are directly detected by FSUIPC and is primarily event-based rather than poll-based. Thus it should be more efficient/performant. Define the desired buttons according to the array passed to the init() function at the bottom of the file.
  22. 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 release on these rotaries gives no meaningfully new information. By that I mean, when a button press happens I'd just as well send a control/virtual keypress, then start a 60ms timer to send it again -- all the while completely ignoring the button release. And then why would I want the 60ms delay at all, versus just sending two control/virtual keypresses on the button press, or a single control/virtual keypress that has twice the normal impact? But yes, I'll share updates and my code as I can.
  23. 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 considered opening it up to learn more about why it behaves that way, see if any reasonable mods are possible, etc. Though I'd be taking a risk if I broke it given how hard these are to find. I don't know. I'm at least glad I managed not to overpay a scalper for it.
  24. 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.
  25. 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.
  • 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.