aua668 Posted August 28, 2021 Report Share Posted August 28, 2021 Hi, A question for Pete and John: Is it by intention, that the registration of an event immediately fires the related function, although the event didn't occur? I made a small sample module for easy testing. I just monitored the COM1 offset for changes and traced the firing of the related function. In my function I also tracked, if the function is called the first time or if it has already be run. Here is the simple module: -- Test event.offset function with COM1 offset ipc.log("---------------------------------") local vFirstRun = 0 ipc.log("vFirstRun = 0") function LogCOM1(offset, value) -- react on FSX Input ipc.log("Start LogCOM1") if vFirstRun == 1 then ipc.log( string.format( "1%02X.%02X", math.floor( ipc.readUW(0x034E)/256 ) , ipc.readUW(0x034E) % 256 ) ) else -- first run due to event registration done - now code can be activated vFirstRun = 1 ipc.log("vFirstRun = 1") end ipc.log("Leave LogCOM1") end -- track every change of the COM1 offset ipc.log("Define event") event.offset( 0x034E, "UW", "LogCOM1" ) ipc.log("Event defined") That's what i find in the log: ********* FSUIPC6, Version 6.1.4 (28th July 2021) by Pete & John Dowson ********* Prepar3D.exe version = 5.2.22.27615 Running inside Prepar3D v5 Module base=7FFE660E0000 Windows 10 Home 64 Bit reported as Build 19043, Release ID: 2009 (OS 10.0) Reading options from "C:\Users\Reinhard\Documents\Prepar3D v5 Add-ons\FSUIPC6\FSUIPC6.ini" Checking the Registrations now ... User Name="xxx" User Addr="xxx" FSUIPC6 Key is provided WideFS7 Key is provided 0 System time = 28/08/2021 18:34:39 0 FLT UNC path = "\\PC-P3D\P3D_Files\" 0 NOTE: configuring for no weather reads or writes! 0 Using DialogMode 16 FS UNC path = "\\PC-P3D\P3Dv5\" 79 Finished: 0 Profile files created 79 ---------------------- Joystick Device Scan ----------------------- 94 Product= JoyWarrior A8-8 94 Manufacturer= Code Mercenaries 94 Vendor=07C0, Product=1104 (Version 16.48) 110 GUIDs returned for product: VID_07C0&PID_1104: 110 GUID= {BABB2690-FB55-11E9-8001-444553540000} 110 Details: Btns=8, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U0,V0,X241,Y127,Z127 110 Product= TQ6 125 Manufacturer= GoFlight 125 Serial Number= 00080 7 125 Vendor=09F3, Product=0200 (Version 2.0) 125 GUIDs returned for product: VID_09F3&PID_0200: 125 GUID= {CE023EC0-9A8D-11E8-800E-444553540000} 125 Details: Btns=4, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R221,U216,V221,X220,Y221,Z214 125 Product= Saitek Pro Flight Yoke 125 Manufacturer= Saitek 125 Vendor=06A3, Product=0BAC (Version 3.2) 125 GUIDs returned for product: VID_06A3&PID_0BAC: 125 GUID= {CDFBFD30-9A8D-11E8-800C-444553540000} 125 Details: Btns=23, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U255,V255,X1023,Y1023,Z255 125 Product= Saitek Pro Flight Rudder Pedals 125 Manufacturer= Saitek 125 Vendor=06A3, Product=0763 (Version 1.0) 125 GUIDs returned for product: VID_06A3&PID_0763: 125 GUID= {CDFBFD30-9A8D-11E8-800B-444553540000} 125 Details: Btns=0, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R511,U0,V0,X127,Y127,Z0 125 ------------------------------------------------------------------- 125 Device acquired for use: 125 Joystick ID = 3 (Registry okay) 125 3=JoyWarrior A8-8 125 3.GUID={BABB2690-FB55-11E9-8001-444553540000} 125 Device acquired for use: 125 Joystick ID = 2 (Registry okay) 125 2=TQ6 125 2.GUID={CE023EC0-9A8D-11E8-800E-444553540000} 125 Device acquired for use: 125 Joystick ID = 0 (Registry okay) 125 0=Flight Yoke System 125 0.GUID={CDFBFD30-9A8D-11E8-800C-444553540000} 125 Device acquired for use: 125 Joystick ID = 1 (Registry okay) 125 1=Saitek Pro Flight Rudder Pedals (USB) 125 1.GUID={CDFBFD30-9A8D-11E8-800B-444553540000} 125 ------------------------------------------------------------------- 438 Controllers are set to ON, using RawInput within P3D 438 LogOptions=00000000 00000001 438 ------------------------------------------------------------------- 438 SimConnect_Open succeeded: waiting to check version okay 438 Opened separate AI Traffic client okay 8891 Running in "Lockheed Martin® Prepar3D® v5", Version: 5.2.22.27615 (SimConnect: 5.2.0.0) 8891 Initialising SimConnect data requests now 8891 FSUIPC Menu entry added 8907 ... Using Prepar3D with Professional License 8922 \\PC-P3D\P3D_Files\P3D.fxml 8922 \\PC-P3D\P3D_SimObj\Airplanes\mjc8q400\MJC8Q4.air 9219 ### The user object is 'MJC8Q400_AUA_OE-LGM' 9219 ### Mode: FREEZE_ATT on FREEZE_ALT on FREEZE_LATLON on 14563 Monitor IPC:311E (U16) = 0 14579 ### Mode: PAUSE on 116422 Loading Complete ... 116438 ### Mode: PAUSE off 116922 User Aircraft ID 1 supplied, now being used 116922 Aircraft loaded: running normally now ... 116969 Monitor IPC:311E (U16) = 5664 116969 SimRead: 311E="NAV STANDBY FREQUENCY:1" INT32: 5664 (0x00001620) 117000 Exception 3 "UNRECOGNIZED_ID", Ref 2898, Index param 1 on write SetData for "RECIP ENG FUEL FLOW:1" 117000 Exception 3 "UNRECOGNIZED_ID", Ref 2899, Index param 1 on write SetData for "RECIP ENG FUEL FLOW:2" 117000 Exception 3 "UNRECOGNIZED_ID", Ref 2900, Index param 1 on write SetData for "RECIP ENG FUEL FLOW:3" 117532 System time = 28/08/2021 18:36:37, Simulator time = 10:00:02 (08:00Z) 117766 Aircraft="MJC8Q400_AUA_OE-LGM" 123547 -------------------- Starting everything now ---------------------- 123547 Starting WideServer now ... 123563 Using "C:\Program Files (x86)\GoFlight\GFDEV64.DLL", version 2.2.8.0 123563 GoFlight GFT8 detected: 1 device 123563 GoFlight GF166 detected: 5 devices 123563 GoFlight GFRP48 detected: 2 devices 123563 GoFlight GF46 detected: 1 device 123563 GoFlight GFTQ6 detected: 1 device 123563 GoFlight GFLGT2 detected: 1 device 123563 GoFlight GFMCPPRO detected: 1 device 123563 GoFlight GFEFIS detected: 2 devices 123563 GoFlight GFWP6 detected: 2 devices 123625 Run: ""C:\Users\Reinhard\AppData\Local\vPilot\vPilot.exe" "-host"" 123625 Affinity Mask set to 20 [x14], "vPilot.exe" 123625 ASN active function link set 123625 Ready for ActiveSky WX radar with additional data : : Here comes the debug log with logging on for offset 0x034E (=COM1) : 8030250 LUA.74: --------------------------------- 8030250 LUA.74: vFirstRun = 0 8030250 LUA.74: Define event 8030266 LUA.74: Event defined 8030266 LUA.74: Start LogCOM1 8030266 LUA.74: vFirstRun = 1 8030266 LUA.74: Leave LogCOM1 8035625 Monitor IPC:034E (U16) = 13376 8035625 SimRead: 034E="COM ACTIVE FREQUENCY:1" INT32: 13376 (0x00003440) 8035625 LUA.74: Start LogCOM1 8035625 LUA.74: 134.40 8035641 LUA.74: Leave LogCOM1 So as you can see, the function is fired immediately, when I register the offset, although frequencydid not change. I would have expected, that it fires, if the frequency changes for the first time. Later I switched frequencies and then it fires the second time and by that logs the frequency. As a consequence I would have now to add similar code to all my event functions, to avoid firing during the event registration process. Maybe you can check, if this behaviour is by intention. I had already in the past the feeling, that this happens, but did not consequently trace it down. As I currently have massive problems, where events are not registered although they are defined in the same way since many years, I try to nail my problem down. During these investigations (see thread: https://forum.simflight.com/topic/92801-p3d-52-lua-event-handling-not-reliable/ ) I came across this issue. If this is always working for all type of events in that way, I can add code to my modules, to avoid this firing. But before doing this, I want to be sure, if this behaviour is planned. Thanks in advance. Reinhard Link to comment Share on other sites More sharing options...
John Dowson Posted August 29, 2021 Report Share Posted August 29, 2021 13 hours ago, aua668 said: Maybe you can check, if this behaviour is by intention. I'm not sure its by intent, and if it is it should be documented as such. I'll take a look at this later and get back to you. John Link to comment Share on other sites More sharing options...
Pete Dowson Posted August 29, 2021 Report Share Posted August 29, 2021 17 hours ago, aua668 said: So as you can see, the function is fired immediately, when I register the offset, although frequencydid not change But effectively it did change from the zero or null which would have been assumed it started with. In the case of a radio frequency I would have though it useful for you to react to the initial value, as if it had changed. Most of my Lua plug-ins use the fact that you get the initial value to, er, get the initial value. Quote As a consequence I would have now to add similar code to all my event functions, to avoid firing during the event registration process. I don't understand why you need to ignore the initial values? Quote As I currently have massive problems, where events are not registered although they are defined in the same way since many years, I try to nail my problem down. I don't see why event registration could fail just because it fires initially? Also I doubt whether it applies to all events -- some are due to a true event, like those joystick ones detected by scanning, like button presses (though possibly a latched button press will fire initially to show that the switch is 'on'. I don't recall without checking the code (which I'm not doing today)). Aha, I see John has found that it is specific to Offset events. Pete 1 Link to comment Share on other sites More sharing options...
John Dowson Posted August 29, 2021 Report Share Posted August 29, 2021 3 hours ago, John Dowson said: I'm not sure its by intent, and if it is it should be documented as such. I'll take a look at this later and get back to you. The event.offset function is documented as such in the FSUIPC Lua Library.pdf: Quote The function is also executed initially, when the plugin is first run, in order to initialise things. This saves using an explicit call to do the same. So this is intended behavior. John 1 Link to comment Share on other sites More sharing options...
aua668 Posted August 29, 2021 Author Report Share Posted August 29, 2021 Hi, Thanks for looking at this issue. I am fine, if it is always the case., that it fires during registration. In that case I could take care for it in my code. In fact I didn't care in the past 😉 For events, delivering some values (like COM frequency etc.) it's fine and useful to get the initial value, as you wrote. Therefore also for most of my plugins this was not a problem. For button events, this is more problematic, as this could produce unwanted effects (e.g. increasing the COM frequency), although the button was not pressed, just because I started my LUA plugin. Therefore I wanted to know, if this is always th case, as I then have to ignore the first button press. If you register increase and decrease frequency in the same plugin, they compensate even if they are fired. For the event not registering I did also some investigation as John proposed. I will give an example and explanation in the other thread. During writing this reply, I saw, that John answered, that it's by intention and that it's documented. Shame on me - I overlooked this obviously. I will go back to documentation and check, if this is also the case for the other types of events. Best regards Reinhard Link to comment Share on other sites More sharing options...
John Dowson Posted August 29, 2021 Report Share Posted August 29, 2021 2 minutes ago, aua668 said: For button events, this is more problematic, as this could produce unwanted effects (e.g. increasing the COM frequency), although the button was not pressed, just because I started my LUA plugin. Therefore I wanted to know, if this is always th case, as I then have to ignore the first button press. But this should not happen with event.button, only event.offset. 3 minutes ago, aua668 said: For the event not registering I did also some investigation as John proposed. I will give an example and explanation in the other thread. Not sure what you mean by this...I will wait for your post in the other thread... 4 minutes ago, aua668 said: if this is also the case for the other types of events. If it is, it should be documented as such. event.button should not initialise, I haven't checked the others. Cheers, John Link to comment Share on other sites More sharing options...
aua668 Posted August 29, 2021 Author Report Share Posted August 29, 2021 Hi, I did the same test as above with event.button. It's not firing ast stated by you. event.Lvar is triggering the function when registering the event (same as with event.offset). Rgds Reinhard Link to comment Share on other sites More sharing options...
John Dowson Posted August 29, 2021 Report Share Posted August 29, 2021 3 minutes ago, aua668 said: event.Lvar is triggering the function when registering the event (same as with event.offset). Yes, that makes sense as it also needs to initialise with the current value, as with event.offset, although it isn't mentioned in the documentation. I will update when I get a chance. Cheers, John Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now