Suppressing FS Control

[DaddyBooks]

Greetings...

 

I have a desire to suppress a small number of FS control calls being written by a hardware interface (external .EXE) when first initialized.  The developer of the software is overwriting the desired initial aircraft state using a view of a number of switch positions different than that desired.  I've written a small piece of LUA that uses event.control to trap the events.

 

What I am seeking is to suppress the events a single time from within the processing function and I will then event.cancel the functions so that subsequent calls to those FS controls are not impacted.

 

After much digging, I'm not aware of any mechanism to suppress a FS control in this manner.

 

I also tried event.intercept on an IPC offset of 0x3110 with a type of UD as well as SD thinking I could simply defer the ipc.writeXXX and the event.intercept never triggered.  I suspect that the executable is making an external call outside of FSUIPC's purview and event.intercept is therefore not able to see this offset.  FSUIPC does log the events so perhaps I am not calling it properly.

 

Is what I am trying possible?  The alternative is to write additional functions to set the switch positions back to the desired state which I can do if this approach is not possible.  I was trying to avoid the "repeated switching" that takes place with that approach.

 

I find that I am using FSUIPC all the time and I am grateful.  A very clever piece of software which has solved many interesting challenges.  My foray into LUA is now proving very interesting.

 

Thanks in advance for any insights...

 

...DaddyBooks

[Pete Dowson]

I have a desire to suppress a small number of FS control calls being written by a hardware interface (external .EXE) when first initialized.  The developer of the software is overwriting the desired initial aircraft state using a view of a number of switch positions different than that desired.  I've written a small piece of LUA that uses event.control to trap the events.

 

What I am seeking is to suppress the events a single time from within the processing function and I will then event.cancel the functions so that subsequent calls to those FS controls are not impacted.

 

After much digging, I'm not aware of any mechanism to suppress a FS control in this manner.

 

Correct, it isn't a facility at present. Generally FSUIPC sees the control as it passes through the Windows messaging system, or, in FSX/P3D, if it is notified by SimConnect (I don't recall offhand where the event.control function gets it).

 

I'm not sure how easy it would be to actually stop them reaching FS. It should be possible if they are going through the Windows message queue. I'll take a look and if possible I'll add it to the event.control function. If i did it it would be for FSUIPC4 only, I'm not extending FSUIPC3 any more.

 

I'm too busy this week, but if you've not heard back from me in this thread in a week's time (Weds 25th) please post a reminder here. I have made a note, though, so i shouldn't forget.

 

Pete

[Pete Dowson]

I had a look at this today and it actually isn't possible to suppress controls the way FSUIPC currently intercepts them. I thought it would be reasonably easy, but it isn't.   I would have to change the control interception to use SimConnect event handling, in the same way as happens for axis mapping and calibration, and I'm really not willing to make such drastic changes at this stage.

 

Sorry to disappoint. 

 

The only way I can think of to fix your situation, albeit rather clumsily, would be to use event.control as you are now to see the offending controls being sent, and immediately sent the counter- or reverse control, to undo what it does. This is actually the way FSUIPC implements some of the systems inhibit options it provides via bits in offsets, like stopping flaps and spoiler actuations..

 

Without knowing which controls are causing the problem I can't really help much more.

 

Regards

Pete

[DaddyBooks]

Pete...

 

Many thanks for looking.  No disappointment on my front.  I had a suspicion that there might not be a straightforward way to intercept a control call.

 

My original plan was in alignment with your recommendation to reverse the function.  I was trying to keep the number of calls to FSX as minimal as possible in anticipation I might use this more widely in the future. It will not be a problem for the less than ten (10) controls I need to address at module start-up.

 

Again, my thanks for your software and for the courtesy of looking into this for me.

 

Have a wonderful weekend.

 

...Robert (aka DaddyBooks)