Event registration fires event function

[aua668]

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

 

[John Dowson]

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 

[Pete Dowson]

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

 

[John Dowson]

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

[aua668]

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

 

[John Dowson]

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

[aua668]

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

 

[John Dowson]

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