PMDG 744 event ids

[the.gamer112]

Once again...

Is there a limit to the event ids that are being watched by event.control?

I'm specifically interested in the range from 70442 up to 70841.

 

this is my code for testing right now:

 

print("Running")

function test(evnt,par)
  print("gotem")
end

event.control(70442,"test")

[Pete Dowson]

4 hours ago, the.gamer112 said:

Is there a limit to the event ids that are being watched by event.control?

No. It merely traps the events passing through the P3D windows procedure or being sent via SimConnect. Of course it is possible that programs might intercept them and handle them before FSUIPC sees them.

The FSUIC "event" logging logs the same things. If your intent is merely to log or display evens as they occur it would be easier to just use the existing logging facilities. If you want to see them in real time, run P3D is Windowed mode and enable FSUIPC's Console Log (or use full screen but move the console to a different screen).

Pete

 

[the.gamer112]

Problem is, the print function is just for testing, since I'm kinda lazy I wanted to see if I can even intercept the event before writing the rest of my code...

Is there any other way to intercept those events before they get processed by something else?

[Pete Dowson]

2 hours ago, the.gamer112 said:

Is there any other way to intercept those events before they get processed by something else?

Not in FSUIPC for a user chosen event, no. FSUIPC does intercept certain events so that they can be altered before sending on -- axis events which are assigned to FS axis controls (in the sim or in FSUIPC) -- so they can be calibrated. But this is internal to FSUIPC for very specific events (axes and those controls needing a following "select code", such as Pushback, Engine, and Toggle Aircraft Exit).

With the Lua event.control function you can take action when the control event occurs -- eg to counter what it is requesting by sending another to contradict it, or by sending a different control, eg, to a different engine. But you can't stop it being passed on.

With PMDG added "custom controls" I have my doubts whether even the sort of interception and forwarding FSUIPC does for those it needs to change will work. PMDG tend to do their own thing, taking the events at the same priority level as my own . This is why it is not always goode to use FSUIPC calibration for all PMDG flight controls, for fear of multiple conflicting events being sent to the sim.

Currently, if you really need to intercept those events and stop them going though I'm afraid you'll need to interface direct to SimConnect. Even then, for PMDG, it isn't guaranteed that you'll be able to do it.

Pete

 

[the.gamer112]

On 5/28/2019 at 4:54 PM, Pete Dowson said:

Currently, if you really need to intercept those events and stop them going though I'm afraid you'll need to interface direct to SimConnect. Even then, for PMDG, it isn't guaranteed that you'll be able to do it.

I don't need them to be stopped from going through, but I need to see when one of the events are happening (Every event triggers or gets triggered by a button press inside the cockpit)

On 5/28/2019 at 4:54 PM, Pete Dowson said:

PMDG tend to do their own thing, taking the events at the same priority level as my own .

Would it be possible to increase the priority for IPC to handle these events first? That way IPC would intercept the event, make it possible for me to process it extrnally, and then send it on...

I'm using FSUIPC 4.974b btw

 

Fabian

[Pete Dowson]

10 hours ago, the.gamer112 said:

I don't need them to be stopped from going through, but I need to see when one of the events are happening (Every event triggers or gets triggered by a button press inside the cockpit)

Logging events using the FSUIPC logging facilities should do that for you. You can also log button presses if you want.

10 hours ago, the.gamer112 said:

Would it be possible to increase the priority for IPC to handle these events first?

It may already do, or it may not, I don't know. but thst isn't the point. I can't stop the PMDG code getting it at that priority. This is why having FSUIPC intercepting and calibrating axes can lead to conflicts, with FSUIPC sending one value whilst the PMDG code it using the original.

Pete