Blake Buhlig

I'm doubling down on my memory and betting orange. The red probably overbears the green to make orange. It could be fun to try producing yellow by pulsing the red LED on and off with green solid on, though lua might not be able to pulse it fast enough.

I found the red and green LEDs for each gear can be turned on simultaneously which makes the gear indicator look orange, so I uploaded a new bravoleds.lua version with definitions for GEARIND_ORANGE, GEAR_LEFT_ORANGE, GEAR_CNTR_ORANGE, and GEAR_RIGHT_ORANGE. Nothing uses those definitions presently but they're available for anyone tweaking the logic. (Edit: at least I think they were orange, they could be yellow based on what I just found on the web regarding what green and red light mixed should look like. My setup has been down for some weeks now and my color memory isn't the best; I'll get around to reconfirming but if anyone tests this before then and finds they are yellow, I can push another update).

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

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.

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 .

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.

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.

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.

@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>

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.

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!

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!

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.

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. ,

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.