ipc.control limit?

[Scotfleiger]

Hi Pete

I am analysing the Control values used by FSLabs A320X to operate various switches for LINDA. For most they use FSX Control ROTOR_BRAKE (66587) but for others they use control 196881. I am using the LUA function ipc.control(value, param) to send commands into the simulator. The value of 66587 (ROTOR_BRAKE) is no problem but I am not sure that control values outside the normal range (e.g. 196881) are transmitted. Under FSUIPC Options and Settings users can set a custom control value from 65536 to 131070 (x10000 to x1FFFE). Does this upper limit apply to the LUA ipc.control(value, param)? I need to send params in the range 0x00010000 to 0x00FF0000.

When I do send the control ipc.control(196881, xxxxxxx), I see in fsuipc4.log the line "FS Control Sent: Ctrl=196881. param:xxxxxxx" which suggests the control is sent but I am not seeing the expected effect. Any comments would be welcome.

I am currently, using FSUIPC4 4.968 and P3Dv3.4 but the question equally applies to FSUIPC5.

[Pete Dowson]

1 minute ago, Scotfleiger said:

For most they use FSX Control ROTOR_BRAKE (66587) but for others they use control 196881

I think 196881 (0x30111) is part of a system of internal messages.  I've seen events logged by FSUIPC like 0x30110, and this is without any FSLabs or other such addons running. In the next updates to FSUIPC I am filtering those out of the logging.

How have you identified it as operating a function in the FSLabs aircraft?

6 minutes ago, Scotfleiger said:

When I do send the control ipc.control(196881, xxxxxxx), I see in fsuipc4.log the line "FS Control Sent: Ctrl=196881. param:xxxxxxx" which suggests the control is sent but I am not seeing the expected effect.

I would be a bit worried if FSL are using controls in such a range. They could be affecting other things in the simulator.

And I can confirm that FSUIPC does send them on.  It cannot send them as a Simconnect Event, as it does for all named controls (SimConnect uses names which FSUIPC has to link to the numbers we use -- the same numbers as actually used in FS9 and before and internally by FSX and P3D).

So it sends them, as it does with <custom> controls, using "SendMessage", with Windows message WM_COMMAND,  the control number as wParam and the parameter as lParam. This is just as FSX/P3D does internally in any case.  You could probably detect these with SpyXX set to log WM_COMMAND messages on the main FSX/P3D window (class "FS98main").

Pete

 

 

[Scotfleiger]

Thanks for the prompt reply.

FSLabs appear to be using the 196880 and 196881 controls for their 'flat' buttons in the A320X virtual cockpit. Operating the mouse over these buttons (left/right and wheel) returns these control values and various params depending on the button state. The same technique can be used for 'normal' switches, buttons and knobs but these return values for control 66587. At present I would not like to see the higher values being filtered out until I work out what is happening.

FSLabs has a big problem with their Enigma anti-piracy software if it detects any alternation to its memory. So far using pic.control(196881,xxxx) has not caused this problem. At present, FSUIPC4 is reporting the control EVENTS for 196880 and 196881 so I can see what is happening.

Hopefully, soon FSLabs will be releasing a SDK to allow me to circumvent this detective exercise.

[Pete Dowson]

3 minutes ago, Scotfleiger said:

At present I would not like to see the higher values being filtered out until I work out what is happening.

I'm not filtering them from being sent, only their logging on receipt. There's no change there in what you are seeing except the log entries like this:

*** EVENT: Cntrl= 65732 (0x000100c4), Param= 0 (0x00000000) EXIT

You'll still see the 

FS Control Sent: Ctrl=196881, Param=12345 

and that means FSUIPC has sent it,  in this case using SendMessage as I explained.

Maybe that rather suspicious WM_COMMAND value you are seeing is a result rather than an instigator.

9 minutes ago, Scotfleiger said:

At present, FSUIPC4 is reporting the control EVENTS for 196880 and 196881 so I can see what is happening.

You mean the "*** EVENT" entry?

I'd rather not log those values (0x20000 and above) normally, as they are rather misleading when they occur as internal communications. (At least they've been misleading me ;-)).  But if you wish I'll keep them optional via a LogExtras or TestOptions bit. Let me know -- I'd rather do any such changes before my next full releases, 4.969 and 5.103, hopefully tomorrow.

Pete

 

[Scotfleiger]

I do mean *** EVENT entries. A LogExtras/TestOptions bit would be most welcome for our purposes please. I can see the logic of removing any confusing log information for the normal user.

[Pete Dowson]

Ok. There are flag bits already for logging more "event" information. It'll be one of those, so you'll get other stuff too. More details next ...

Pete

 

 

[Pete Dowson]

To get them logged in the next versions you'll need these in the [General] section:

Debug=Please
LogExtras=x10

Or, with just Debug=Please there, you can edit the LogExtras value in the Logging tab.

The sorts of lines in the log you'll get then are like these (for one being SENT by or through FSUIPC, as opposed to being received -- you won't get so many for an interception only:

   432248 ExSendEvent(196881, 12345, 0)
   432248 ... evnum mask=0, preval=0
   432248 ... not intercepted or in options
   432248 Sending "????" 196881 [0x30111], Param 12345
   432279 *** Intercepted EVENT (direct): Cntrl= 196881 (0x00030111), Param= 12345 (0x00003039) <unknown>
   432279 *** EVENT: Cntrl= 196881 (0x00030111), Param= 12345 (0x00003039) <unknown>
   432279 FS Control Sent: Ctrl=196881, Param=12345 

Pete

 

[Scotfleiger]

That's great. Thank you Pete.