Jump to content
The simFlight Network Forums

Henrik Bergvin

  • Content Count

  • Joined

  • Last visited

Everything posted by Henrik Bergvin

  1. 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
  2. Perfect, so event.button shouldn't miss any presses even if the script is busy. Thank you for your help!
  3. 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.Reverse
  4. 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 🙂
  5. 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.
  6. I was on 6.0.9, I'm now updating to 6.0.12 to give it a try. I'll report back!
  7. 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
  8. 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.
  9. 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 proce
  10. 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.
  11. 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, c
  12. 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?).
  13. 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. H
  14. 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.
  15. 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?
  16. 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.
  17. Alright, I will see if I have time to do some tests today on one of the default aircraft 🙂
  18. 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
  19. 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 +
  20. 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.dom
  21. 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.
  22. 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 una
  23. 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
  24. 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 :)
  25. 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
  • 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.