Help with PMDG 777

[monithi]

Hi Pete,

 

Where can i get PMDG 777 offset value? I already tried searching the internet but could not find them anywhere please help.

[Pete Dowson]

Where can i get PMDG 777 offset value? I already tried searching the internet but could not find them anywhere please help.

 

There are no offsets for the PMDG 777. It doesn't use FSUIPC and there's no implementation similar to the 737NGX to map the values from its Client Data, if indeed it supports that option.

 

Pete

[monithi]

i'm trying to get the value for mcp and lighting any suggestion please

[Pete Dowson]

i'm trying to get the value for mcp and lighting any suggestion please

 

Don't PMDG provide any information to help?  I'm afraid any aircraft which is programmed to do all these things outside of the standard FS systems is only usually accessible through devious means -- FSUIPC does provide ways of finding out and maybe accessing things differently. For information OUT of the aircraft (as opposed to control of parts of the aircraft), really the only likely area is the use of the facilities in the Lua plug-in functions to obtain the values of "L:Vars" (local panel variables). You could investigate those using the FSUIPC assignable control to log lvars, or the more comprehensive sample Lua plug-in installed for you which also logs them, but in real time, i.e. as they change.

 

However, not all aircraft implementations use local variables. It depends on how they are implemented.

 

Pete

[Dirk98]

Pete, in case with iFly's 737ng, why does it need some iflytofsuipc.exe to talk to FSUIPC, whereas PMDG's 737ngx understands controls sent from FSUIPC directly? And the both use L:vars in their programming if I articulate it right (at all). Does this mean PMDG had coded their lvars so that they could be handled by FSUIPC directly and iFly had not? Sorry, if I'm having trouble even with the terminology.  

 

Thanks,

Dirk.

[Pete Dowson]

Pete, in case with iFly's 737ng, why does it need some iflytofsuipc.exe to talk to FSUIPC, whereas PMDG's 737ngx understands controls sent from FSUIPC directly? And the both use L:vars in their programming if I articulate it right (at all). Does this mean PMDG had coded their lvars so that they could be handled by FSUIPC directly and iFly had not? Sorry, if I'm having trouble even with the terminology.  

 

Actually most of the sub-systems in the NGX are dealt with by additional FS controls which PMDG added.  I don't think you need to use the L:Vars for anything, though many were discovered before PMDG released their update with the SDK. The SDK lists all the extra (non-FS) controls added to the normal FS range -- and accessed in FSUIPC by the <custom control> assignment and the control number -- as well as mapping all the read-outs so cockpit builders can show them on their hardware displays.

 

iFly went a different way and provided the values and controls by a different interface. iFly2FSUIPC maps all those inputs and outputs to some FSUIPC offsets allocated for that purpose. I don't really know much about iFly, so I couldn't say whether they used L:Vars too or not.

 

Pete

[Dirk98]

Actually most of the sub-systems in the NGX are dealt with by additional FS controls which PMDG added...

 

The SDK lists all the extra (non-FS) controls added to the normal FS range -- and accessed in FSUIPC by the <custom control> assignment and the control number -- as well as mapping all the read-outs so cockpit builders can show them on their hardware displays.

 

Are those "additional FS controls" by PMDG that you mentioned are the same "The SDK lists all the extra (non-FS) controls added to the normal FS range" in context?

 

Thanks,

Dirk. 

 

PS: In PMDG I use those controls with FSUIPC actually, just trying to get a general notion, thanks!

[Pete Dowson]

Are those "additional FS controls" by PMDG that you mentioned are the same "The SDK lists all the extra (non-FS) controls added to the normal FS range" in context?

 

Yes, they added additional controls to the normal FS list, numbering them beyond those pre-assigned in FS. So they are "non-FS" controls in the sense that FS doesn't know those numbers, but they use the same mechanism, posting via message queues using Windows WM_COMMAND messages.

 

Pete

[Dirk98]

Yes, they added additional controls to the normal FS list, numbering them beyond those pre-assigned in FS. So they are "non-FS" controls in the sense that FS doesn't know those numbers, but they use the same mechanism, posting via message queues using Windows WM_COMMAND messages.

 

Pete

 

Thank you very much, Pete.

 

Dirk.

[Dirk98]

Alas, I fail to understand the difference yet. See, If I can use mouse click macros facility in FSUIPC to control most of the functions in iFly why do I necesserily need iFly2fsuipc.exe running in the background to be able to manipulate the same controls via FSUIPC? Any exe running in the background is such a nuisance, and there's nobody who's come up with a direct solution but iFly2fsuipc...

 

 

Thanks,

Dirk.

[Dirk98]

I'll try to answer myself by quoting this from GIT User Guide:

 

 

Mouse Click Events are available when a developer has created an aircraft gauge or gauges using the C++ programming language.

 

The gauges will have areas that respond to various types of mouse clicks and in turn trigger events or custom code to execute.