Henrik Bergvin

This I fully get behind, there's no reason to operate a queue for an IPCparam since it's not really supposed to handle rapid presses. On the reverser levers on my Honeycomb Bravo, I just place my hands behind and pull them both simultaneously. It is most probably not simultaneous by millisecond, but their status is most probably handled by the same poll of the hid device, and as such it will appear as if they were triggered simultaneously. That could work, but that would mean two identical files with different names, doing the same thing... I'll stick to event.button, it seems robust 🙂

Perfect, so event.button shouldn't miss any presses even if the script is busy. Thank you for your help!

Cheers! Are there any drawbacks for using event.button? I quite like having as much as possible in lua files (since I can work on them without the sim running and do logic based on which buttons are held etc), and it wouldn't be a big matter for me to make some form of system where I define button presses like this: left_reverser_activate = { button = { 4, 9, 1 }, -- button 4,9 is pressed action = { "B777.ReverserLever", "left", "activate" }, -- B777.ReverserLever("left", "activate") }, left_reverser_off = { button = { 4, 9, 0 }, -- button 4,9 is released action = { "B777.ReverserLever", "left", "off" }, -- B777.ReverserLever("left", "off") } Using the above, I could just loop through all the actions and register events for the presses. I know the binding facility built into FSUIPC is nice and all, but once you start doing something more complex (like, tracking several variables), Lua is really the way to go. Oh! If a lua script is running something and a button press happens, will event.button be queued and run when the script is "awake" again?

Correct, the problem is that there are two LuaValue params sent to the same script at the same time, and only one is captured. By using event.param, it's simply not able to capture both if they are immediate/simultaneous. Unless you have a better suggestion, I'll use event.button, since it seems fast enough to capture the buttons rapidly. Speed isn't the issue here at all 🙂

I tried on .12, but didn't get any particular better LuaValue/event.param triggers. I did, however, get a lot better result using event.button, those would trigger almost at the same time and the script would capture them even faster than event.param.

I was on 6.0.9, I'm now updating to 6.0.12 to give it a try. I'll report back!

Maybe @Pete Dowson can shed some light on this: 32283172 Button changed: bRef=0, Joy=4 (E), Btn=9, Pressed 32283172 [Buttons.PMDG 777F Arctic Air] 104=PE,9,C65820,-1 32283172 FS Control Sent: Ctrl=65820, Param=-1 THROTTLE1_SET 32283172 Button changed: bRef=0, Joy=4 (E), Btn=10, Pressed 32283172 [Buttons.PMDG 777F Arctic Air] 108=PE,10,C65821,-1 32283172 FS Control Sent: Ctrl=65821, Param=-1 THROTTLE2_SET 32283172 Button changed: bRef=0, Joy=4 (E), Btn=9, Pressed 32283172 Button changed: bRef=0, Joy=4 (E), Btn=10, Pressed 32486672 Button changed: bRef=0, Joy=4 (E), Btn=9, Pressed 32486672 [Buttons.PMDG 777F Arctic Air] 104=PE,9,CL41:V,406 32486672 Button changed: bRef=0, Joy=4 (E), Btn=10, Pressed 32486672 [Buttons.PMDG 777F Arctic Air] 108=PE,10,CL41:V,409 32486672 Button changed: bRef=0, Joy=4 (E), Btn=9, Pressed 32486672 Button changed: bRef=0, Joy=4 (E), Btn=10, Pressed 32486672 LUA.3: Param: 409 Above are two log excerpts - one where I am sending FS Controls, and one where I'm sending a LuaValue change. As you can see, only param 409 comes through on the LuaValue example... Can Lua capture changes faster somehow? The buttons are definitely caught.

so, I changed to a poll rate of 10, and it still wouldn’t update the lua script enough. However, I can do normal controls and standard Fs actions at near simultaneous trigger. So it lies in the communication with the Lua script. I’ll keep digging. Maybe event.button might be a thing here.

Honeycomb Bravo for the reversers, so each reverse lever is a button push/release. While it would work setting the controls directly (throttle set to -1 to activate rev, throttle cut or set to 0 to cancel reverse), I have other logic I want to run (such as moving the thrust levers I to their bottom detent to command max reverse, but only if I have already flipped reverse levers...) What I have found in today’s testing is that the LuaValue and LuaToggle functionality isn’t being processed fast enough. Button presses and binds work fine but the lua script isn’t receiving and processing the events fast enough on near simultaneous presses.

I'll give that a shot, see if a 15ms interval helps. I've dabbled a bit with hid reading through the com library, and in that I could always capture all the buttons changed even with 40ms polling.. It's not as simple though for the bravo, since it seems to be sending some "ghost" presses now and then that I can't just filter - therefore I went for the standard binding and passing params via LuaValue.

I've picked up the Honeycomb Bravo throttle, which is a really amazing piece of software. Not before having had something that can do reversers properly, I set about programming it. I have a LUA script with an event.param listening for LuaValue (ipcParam) changes. I then have a function as described below to handle the reverser states (for further logic that is not relevant for this support question). -- this is in pmdg_b777_functions.lua B777 = { engines = { [1] = { name = "left", rev = false, rev_fraction_offset = 0x207C, control = 65820 }, [2] = { name = "right", rev = false, rev_fraction_offset = 0x217C, control = 65821 }, function B777.Reverser(engine, mode) if mode == "off" then -- reversers to off ipc.control(B777.engines[engine].control, 0) elseif mode == "activate" then -- reversers from off to idle ipc.control(B777.engines[engine].control, -1) end end return B777 -- The following is in the main script B777 = require('pmdg_b777_functions') param_table = { [406] = function() B777.Reverser(1, "activate") end, [407] = function() B777.Reverser(1, "off") end, [409] = function() B777.Reverser(2, "activate") end, [410] = function() B777.Reverser(2, "off") end, } function b777_param(param) ipc.log("Param: " .. param) if param_table[param] ~= nil then param_table[param]() return end end event.param("b777_param") Now, individually each reverser lever works exactly as they should. I set it to reverse, it sets the axis to -1 (which is basically reverser idle), and when I release the button it sets it to idle (axis to 0). Now to my issue - when landing you tend to flip the reverse levers more or less simultaneously. This does not always seem to trigger both of them. If I flip both left and right engine reverser levers at the same time, I tend to get param 406, but not 409. Sometimes it is the other way around and I get 409, but not 406. Note - I'm using a table for parameter lookup here, but it isn't exclusive to this script. I'm also using the hidAlphaButtons and hidBravoButtons scripts (from here https://forum.simflight.com/topic/91599-lua-scripts-for-honeycomb-bravo-quadrant-and-alpha-flight-controls-buttons-32/) Is there a good way to catch multiple button presses that are nigh on simultaneous? This goes for both press and releases in this case..

Yeah, I'll do that. While I have you here, I'm doing polling at a rate of 25 per second. Right now it's on 2 devices, but will that be safe to do on 3-4 devices without causing any issues? I have absolutely no issues with delays using the COM library, but as with everything, as you increase the amount of devices... yeah. I was also considering a faster poll rate to accommodate for a 20ms delay, 10ms repeat on held buttons (that's default in FSUIPC isn't it?).

Since I like to do things the hard way around, I have written a "generic" HID device handler for advanced button functionality, using the COM library. I've got tracking of button presses and releases right now, and events firing based on what button is pressed (B1_Press, B1_Release, etc), and fairly simple handling for this from lua scripts. Next up for me is to implement repeats and double presses. Right now, I'm polling the devices using an event.timer call on a poll rate of 1000/25 (that should be every 40ms?), and it feels very stable and I never seem to "miss" any events. However, I'm at a bit of a loss here regarding what event.timer is sending to the poll function. In the documentation it says "The time provided is NOT the same as the one returned by the ipc.elapsedtime function", but it actually doesn't say what time is provided. This information is rather vital for me if I'm to track double clicks or repeats in the script. Is it elapsed time, or is it time since last time the timer fired?

Understood. I do find using LuaValue a bit faster than Lua for param based scripts, so I'll stick to that in the future. I'll bind a push button to kill and restart the script for testing purposes.

It seems that using that method is a little better, I haven't had any issues with focus after trying those. As for Lua scripts, is it better to call scripts using "Lua ScriptName" and a param, or do you recommend using the param event and passing LuaValue? I imagine events are queued and read one by one, so if two fire rapidly the script will run for the second once it is done with the first?

I should mention that I am currently performing a flight in the 747, and have not had it happen at all. Only difference from my previous attempts were that I have installed the binding utility (and, I guess, driver package) for the Honeycomb Yoke. The yoke has more buttons than windows can detect (35) and the utility exposes those to the sim. I don't have anything bound to the last few buttons, but this *might* have been the issue. I'll test your methods still, and let you know if they work out.

Alright, I will see if I have time to do some tests today on one of the default aircraft 🙂

I am using custom controls like these in those aircraft too, and I wasn't aware I could check offset statuses with direct assignemts - I'll have to give that a try and see if it can work. The event names are declared and imported usin the default LUA way: require "pmdg_777_offsets" I have it for the PMDG birds because of the sheer number of controls, and I like names instead of number, and they work, just sometimes it locks up the clickability for some reason. I have as of yet not managed to find a specific culprit... I've attached the two lua files I use for the 747, as well as my profile, maybe you can see something in it. Also, i should mention that i have UseProfiles=Files set in FSUIPC6.ini. As for default aircraft, I haven't seen the need to do any form of LUA scripting for those, since they're so basic I don't really touch them at all.. PMDG 747.lua pmdg_747_offsets.lua 747.ini FSUIPC6.ini

Hello, I am using FSUIPC6 on P3D v4.5, and quite often use LUA scripts to control my buttons - especially for functionality where I want to be able to do stuff like notifications or deal with two way buttons on my controllers. I'm using the Thrustmaster Hotas Warthog (throttle and stick) and the Honeycomb Alpha Yoke. Those are the only USB game controllers attached to my system. I'll show you a sample from one of my scripts: -- I have these in a separate file (pmdg_777_offsets.lua) THIRD_PARTY_EVENT_ID_MIN = 69632 EVT_OH_ELEC_GRD_PWR_PRIM_SWITCH = THIRD_PARTY_EVENT_ID_MIN + 8 EVT_OH_ELEC_GRD_PWR_SEC_SWITCH = THIRD_PARTY_EVENT_ID_MIN + 7 -- My main script, called by button presses -- External power if ipcPARAM == 305 then -- Check if the ground power is off for each control, since button is a one-shot. if ipc.readSB(0x644C) == 1 then ipc.control(EVT_OH_ELEC_GRD_PWR_PRIM_SWITCH,1) end if ipc.readSB(0x644B) == 1 then ipc.control(EVT_OH_ELEC_GRD_PWR_SEC_SWITCH,1) end end if ipcPARAM == 306 then -- Check if the ground power is on for each control, since button is a one-shot. if ipc.readSB(0x644A) == 1 then ipc.control(EVT_OH_ELEC_GRD_PWR_PRIM_SWITCH,1) end if ipc.readSB(0x6449) == 1 then ipc.control(EVT_OH_ELEC_GRD_PWR_SEC_SWITCH,1) end end -- Button assignments on the Honeycomb Yoke 39=PD,16,CL41:R,305 -{Lua PMDG 777}- 40=PD,17,CL41:R,306 -{Lua PMDG 777}- Quite often when I am running scripts like this, I lose "focus" in the simulator where I have to click outside the sim and back again for anything to register, sometimes multiple times. This is not exclusive to PMDG aircraft, I use it on the RealAir Turbine Duke and the Milviz King Air 350i, and have the same issue. If I alt tab to a program and press escape, it is as if P3D has focus still, and escape brings up the "end scenario" screen, but no switches or in simulator buttons are working. Any idea why this might be?

Hello, The after landing flow was not something I made myself, but was already there from the original script. However, to find these values, you'll have to look up the corresponding function. There is an excel document containing these, if you look in Prepare3D\SimObjects\Airplanes\mjc8q400\doc\ExtInterfaces\. In addition, in the XML folder is the tool you need to get the CRC value to call. The value passed in the SetQ400Value and GetQ400Value methods is the resulting CRC from the tool. So for instance, if I want to set the domelight switch, I'd put in electricsData_->control.domelight_sw in the tool to get 68081 as the result, and as such I'd use that in the SetQ400Value method. Hope this helps you out :)

Ok, thank you so much for the answer. I'll keep on testing to see if I can figure out whether or not there's a hardware event that triggers it. It has happened to me on two different (Carenado) aircraft, and on two similar flight plans.

Is it at all possible to track the origin of an event? Today, I was happily flying along in my Citation CJ2 (Carenado) when my engines cut out. I quickly scrambled to restart the engines, and got the plane flying again. After landing, I checked the FSUIPC log which was set to capture events, and I found these two lines as the engines shut down: 4719188 *** EVENT: Cntrl= 66495 (0x000103bf), Param= 0 (0x00000000) TOGGLE_FUEL_VALVE_ENG2 4719672 *** EVENT: Cntrl= 66494 (0x000103be), Param= 0 (0x00000000) TOGGLE_FUEL_VALVE_ENG1 Unfortunately, I was not logging button presses, so I am unable to track down if i have some faulty hardware trying to send the events. So this brought me to wonder if it is possible at all to find out the origin of that event, so I can track and possibly catch it? I'd rather not toggle my fuel valves :D

I mostly fly the Q400 with FS2Crew, so I tend to not use the scripts so often - though the vspeed one is definitely one I use repeatedly - too much twisting of knobs :P

Not at all, thank you :) The scripts are there to be used! If there's anything else you need, let me know and I'll take a look at it :)

This is a 3 year and some necro of an old post, but first I would like to say thank you very much to Chris Warner for this script. Secondly, I did a few changes to make it work a little bit better. Updated version (and other script as I make them) can be found here: https://www.dropbox.com/sh/nof8k0k3m8juqzs/AAC5pulYtgMzdl5HyndcQhV4a?dl=0 /Henrik Bergvin