PMDG 737 NGX - trouble with event "EVT_EFIS_CPT_MODE_CTR"

[shorthauler]

Hi folks,

Who else has trouble with the event "EVT_EFIS_CPT_MODE_CTR" from the 737 NGX SDK? I am sending a joystick pulse to FSUIPC, custom control 69992, parameter 1. This pushes the button, but it remains pushed. I also tried On/Off instead of Pulse, to send the parameter 0 when the button is released, but this will yield two no pushes instead of none.

Anyone had the same problem and solved it?

Best,

Holger

[ckovoor]

For my own home-built hardware EFIS+MCP for the PMDG B737 NGX (SP1c) I use a FSUIPC mouse macro for this and it works:

Capt EFIS Ctr=RX19770*X8bcc

I don't remember if I tried the control and reverted to using a mouse macro because it didn't work.

[shorthauler]

I just found out something that I cannot explain. But maybe someone here can:

I looked at a Lua script (I am not familiar with Lua, I am using EPIC), and I noticed something called "endfunction".

So I took the parameters from the Lua script and an On/Off combination for the buttons, and now I have "69992" for the customs control and "536870912" as a parameter when the button is pressed and "131072" when it is released.

This works but I have no idea why. For the PMDG 744 I only used a pulse for the button and one parameter ("1").

 

Can anyone explain to me what I just did?

Best,

Holger

[Pete Dowson]

4 hours ago, shorthauler said:

So I took the parameters from the Lua script and an On/Off combination for the buttons, and now I have "69992" for the customs control and "536870912" as a parameter when the button is pressed and "131072" when it is released.

This works but I have no idea why.

PMDG in their wisdom designed their custom control interface to use mouse type flags, giving the same mouse action for the switch as you would use for direct mouse use on the switch.

The parameters look odd by they are just simple flags: 

131072 is x00020000 and
536870912  is x20000000

Those are rather easier numbers, and have just one flag bit set which is meaningful. The mouse values SHOULD be documented in the SDK's .h document where the controls are listed. are they not? (Otherwise you can certainly find them on Microsoft programming reference sites for the WM_MOUSE message group).

FSUIPC will accept hexadecimal values like this, just precede them with an x.

Pete

 

[Pete Dowson]

Following on from my previous reply, I just located the mouse actions list in the PMDG .h file. Here it is:

/* Mouse flags for mouse click simulation

#define MOUSE_FLAG_RIGHTSINGLE		0x80000000
#define MOUSE_FLAG_MIDDLESINGLE		0x40000000
#define MOUSE_FLAG_LEFTSINGLE		0x20000000
#define MOUSE_FLAG_RIGHTDOUBLE		0x10000000
#define MOUSE_FLAG_MIDDLEDOUBLE		0x08000000
#define MOUSE_FLAG_LEFTDOUBLE		0x04000000
#define MOUSE_FLAG_RIGHTDRAG		0x02000000
#define MOUSE_FLAG_MIDDLEDRAG		0x01000000
#define MOUSE_FLAG_LEFTDRAG		0x00800000
#define MOUSE_FLAG_MOVE			0x00400000
#define MOUSE_FLAG_DOWN_REPEAT		0x00200000
#define MOUSE_FLAG_RIGHTRELEASE		0x00080000
#define MOUSE_FLAG_MIDDLERELEASE	0x00040000
#define MOUSE_FLAG_LEFTRELEASE		0x00020000
#define MOUSE_FLAG_WHEEL_FLIP		0x00010000		// invert direction of mouse wheel
#define MOUSE_FLAG_WHEEL_SKIP		0x00008000		// look at next 2 rect for mouse wheel commands
#define MOUSE_FLAG_WHEEL_UP		0x00004000
#define MOUSE_FLAG_WHEEL_DOWN		0x00002000

You'll see that the x20000000 value means "Left Single Click, and the x00020000 one means "Left release". The latter is a bit puzzling though.

Pete

 

[shorthauler]

Thanks so much. This explains a lot. It also provides a workaround for the lack of writeable offsets for all those who are using EPIC. I need some time to experiment with my scripts and then will come back with a description of the workaround.

 

Best,

Holger

[shorthauler]

OK, coming out of the test lab:

With generic FSX aircraft, a value would be generated inside EPIC and sent via an offset to FSX. If I understand correctly, PMDG only has readable offsets but no offsets one could write to.

I adapted my script - instead of generating values it now sends virtual button pulses. These buttons show up inside FSUIPC. For example, turning the course selector knob to the left will generate a pulse by a virtual button. The button is assigned via FSUIPC to the course selector (custom control 7008), with a respective mouse flag as parameter (I tried clicks and whell up / down - does not seem to make a difference).

This works for increments in steps of one. However, my script recognizes the speed a t which a button is turned. With a script that sends values to offsets, these values will increase or decrease exponentially (i.e. first turn notch on the heading knob = +-/1, second = +/-2, third = +/-4 etc.). Eventually, this will stop at +/-30 (the 12th part of a circle). While the button is still turned quickly, every knotch wil generate an increase or decrease of 30 degrees of heading. Once the button is turned slower, the increments will decrease. If you leave it still for the fracion of a second, it will revert to +/-1.

I adapted my script so that instead of increasingly higher values it sends multiple pulses.

However, it seems that PMDG cannot digest a "fusilade" of button pulses (i.e. a high number of pulses within a unit of time). I had to put a delay of 0.2 seconds between the pulses, so they would be recognized by PMDG. With a smaller spacing than 0.2 s, they would be counted as one pulse, maximum as two. Whether I used the flag for clicks or the wheel did not make a difference.

Plus, with a spacing of 0.2 seconds, PMDG would actually receive all pulses but bank them and change the value in the course selector much slower (about 3 increments of 1 within one second).

This came as a surprise, as by turning the mouse wheel, you can increase or decrease the values pretty quickly. By mouseclick, you actually cannot. Even if you keep the mouse button pressed, the changes are slow.

Unfortunately, this makes it unfeasable to use buttons for selectors such as Heading, Altitude, Speed, Course selectors, VS ... that need high changes in short time.

So it seems I am back to my quest of how to send values to PMDG without there being writeable offsets ...

If anyone has any advice, please let me know (change of hardware does not count as advice ;-)) I know that Peter is not using PMDG, but maybe someone else has been confronted with the same conundrum.

Best,

Holger

 

[Pete Dowson]

10 hours ago, shorthauler said:

However, it seems that PMDG cannot digest a "fusilade" of button pulses (i.e. a high number of pulses within a unit of time).

Yes, a lot of folks has said that mouse clicks on some more sophisticated add-on aircraft appear to be rather slow in activation. By reports I've seen I think it is with P3D this is so rather than FSX, though it probably applies to both. Sending what are effectively mouse clicks you are emulating the user with a real mouse, so you need to insert delays to bring it down to human times.

Have you tried using the facility to hold the button down for a time? You'd either have to measure the time for a certain larger increment, or read back the value and rorrect overshoots afterwards. Or measure the overshoot and correct with a shorter time.

Since PMDG have not provided any way off writing values directly, as you could with default aircraft, I don't know of any other ways really.

10 hours ago, shorthauler said:

This came as a surprise, as by turning the mouse wheel

Not holding the button down? Have you tried using the mousewheel? I thought I saw a Mouse code for that.

The Lua plug-in Mouse library provides for wheel turning, but you'd probably need to move the mouse to the right position first, rather than just end the PMDG control with a mouse code.

You could try posting on the PMDG forum too -- they'll all be PMDG users there!

Pete

 

[shorthauler]

Pete - thanks for your reply. Some findings that might also be of interest for you:

- As long as you use the correct number for the custom control and the right parameter within this, it does not matter where your mouse pointer is. A button command will do what it is told.

- Holding the mouse button (actually doing this, not by a button command) yields an increase which is much too slow to be practical for sim operations. Using the wheel will get you closer to reality.

- I was posting here since I expect that in a PMDG forum everyone will tell me to go the Lua way and to forget about FSUIPC. But FSUIPC for me is still the way to go. I will now post in other fora and come back with what I learn

Best,

Holger

 

P.S.: Can you positively confirm that values cannot be written directly with PMDG aircraft? Doesn't this make all those expensive plug-&-play MCPs useless?

[Pete Dowson]

7 minutes ago, shorthauler said:

As long as you use the correct number for the custom control and the right parameter within this, it does not matter where your mouse pointer is. A button command will do what it is told.

Yes, I realise this in any case. It is simply their routine functioning as if it had been called by a mouse click.  I was thinking that the wheel codes, supplied the same way, would do it too. Have you tried? 

i.e. these:

#define MOUSE_FLAG_WHEEL_UP		0x00004000
#define MOUSE_FLAG_WHEEL_DOWN		0x00002000

The thing with those though, is what increment or decrement (wheel clicks) their function assumes. With the real mouse they can be accumulated and arrive in a separate parameter. 

Still, it may accept them faster, if necessary.

11 minutes ago, shorthauler said:

everyone will tell me to go the Lua way and to forget about FSUIPC. But FSUIPC for me is still the way to go.

Er, Lua without FSUIPC? How?

12 minutes ago, shorthauler said:

P.S.: Can you positively confirm that values cannot be written directly with PMDG aircraft? Doesn't this make all those expensive plug-&-play MCPs useless?

Unless they accept L:Vars (Local panel variables) then I think there's no way. Have you tried using the L:var logging facilities in FSUIPC, or the supplied Lua plug-in to check?. Modern gauges written in XML tend to use L:Vars a lot, but I think the PMDG ones may be the older style C/C++ ones, which don't so much.

Pete

 

[shorthauler]

Interesting comment on the mouse wheel. It makes for fast changes when you use it manually. When you "roll" the mousewheel via flag commands and virtual buttons, it is as slow as the clicks. As if there is a buffer in PMDG which, when filled, only sends one increment while the other input is disregarded - until the buffer is empty again.

 

So Lua goes via FSUIPC? I guess I will have to read up on Lua, then.

 

Somebody must have found a way to send quick value changes to PMDG, however. I guess that otherwise it would be difficult to sell the expensive plug & play MCPs. The whole point of this hardware is to get as real as possible, and that's not the case when you keep your eyes glued at the MCP watching the values change at glacial speed ...

 

I will also write to some manufacturers, let's see what I come back with.

Best,

Holger

[Pete Dowson]

4 minutes ago, shorthauler said:

Somebody must have found a way to send quick value changes to PMDG, however. I guess that otherwise it would be difficult to sell the expensive plug & play MCPs.

The PMDG aircraft don't suite cockpit builders at all for all these reasons. I think the iFly models have a slightly more cockpit-oriented attitude, but I like many others use external aircraft systems like Prosim, SimAvionics and Project Magenta. The flight model in the sim is then cockpit-less and relatively simple, with only the flight characteristics (and outside views of the aircraft) then being important.

In the past the manufacturers of the MCP units have often supplied their own drivers, and I think they probably could do (and may already have done it) it with PMDG's assistance, but I bet they pay for this.

Pete

 

[shorthauler]

Do you think it is worthwhile trying LINDA? I installed it yesterday, but I got stock here "LINDA:: ---> ERROR:: Main system config not found! Run GUI and check configs!"

I might attempt to solve this, but if LINDA is only a graphical interface for FSUIPC I can probably save myself this trouble?

Best,

Holger

[Pete Dowson]

3 minutes ago, shorthauler said:

Do you think it is worthwhile trying LINDA? I installed it yesterday, but I got stock here "LINDA:: ---> ERROR:: Main system config not found! Run GUI and check configs!"

Other LINDA users will need to answer this for you. Why not also check their website?

Pete