John Dowson

But, with this update, that document is now out-of-date and I need to update. I would just like to check this is still working for the latest 777 update. Once that is confirmed, I will update the documentation. I would like to know if the (old) 777 data area is still ok (i.e. has the correct spacing for the different data points) and if the new data segment (from 6C00) is also spaced correctly. Luke - if you could check this, that would be great. Attached is another dll with the structure packing changed to 4 bytes, as was previously. I would like to know if the data in the PMDG offset area conforms to this version or the previous (or maybe both!). : FSUIPC6.dll Thanks, John

This is not correct. For the correct vendor/product ids, look for this line in your FSUIPC7.log for that device: Note that is an example for my Bravo throttle quadrant. The vendor/product for you will be different, but still logged. Use those. DO NOT adjust the [LuaFiles] section of your FSUIPC7.ini. This is generated and maintained by FSUIPC. Changing this can screw up your assignments - NEVER change this. Sorry, you didn't do that yourself - that is correct. The [LuaFiles] section will list the luas found in your installation folder, ready for assignment or auto-running. To auto-start luas, you add them to the [Auto] section, or the profile specific [Auto.xxx] section (where xxx is the profile name). Please read the provided documentation. John

Sorry, I'm not familiar with the TBM 930. I thought CAS was Calibrated Air Speed, but I see that in the TBM this is the Crew Alerting System, no? If so, I've no idea on how to control this, sorry.

@Jason Fayre There was a minor problem in the previous dll I posted - 737NGX offsets were disabled. This has been corrected in the attached version. Also, I'm not sure the packing for the general data offsets is correct. Could you check the general 777 data is correct from offset 0x6420 as well as the new data from 0x6C00. If it doesn't look correct, I will need to adjust the packing in the header. FSUIPC6.dll Thanks, John

Should be possible (and you don't need a full license for this). There is an SDK for python included in the SDK folder. Om fact, that topic you linked to shows you how to do this via offset 3100. There is also a facility to send keystrokes via offset 3200.

That MF event uses a hvar: AS1000_MFD_CRS_PUSH#(>H:AS1000_MFD_CRS_PUSH) You can try using that hvar directly. You will need to add it to a hvar file and place in the FSUIPC WASM modules folder (there should already be one there for the A320). Or you can try in lua using ipc.execCalcCode("(>H:AS1000_MFD_CRS_PUSH)") Or maybe that hvar is not available in the C172?

That doesn't surprise me. Hvars are only know to FSUIPC7 if you provide a *.hvar file, placed in the WASM's modules folder. This is explained in the Announcement. I have only included a hvar file for the A320, so no other aircraft will have any hvars available unless you add a file for them to the WASM. I also can't see that event listed in the MobiFlight WASM events document: https://docs.google.com/spreadsheets/d/1jTXlcHaJWx0B7TB63Pmma7bKwpxsxXJO6EJ3ECt7zpc/edit#gid=172455454 ...but it is in the events.txt: AS3000_MFD_SOFTKEYS_1#(>H:AS3000_MFD_SOFTKEYS_1) Maybe that hvar is not available in theTBM930, I don't know. You could try activating it using the Add-ons->WASM->Execute Calculator Code function to see if it works, and if so, then add to an hvar file for it to be recognised as a hvar by FSUIPC7.

It could be a faulty button that is continually firing. You can try the IngnoreThese ini parameter, from the Advanced User Guide:

There i the following additional data in the PMDG_777X_Data data structure. This is now written to the 2nd PMDG data offset area, from 0x6C00

Yes

Can you try the attached version please - its untested as I don't have any PMDG aircraft: FSUIPC6.dll

Does that hvar exist in the TBM 930? Have you added it by adding a hvar file for the TBM 930? What does FSUIPC7 show when you list hvars (from the WASM-> Lisy Hvars menu entry)? Not that, up to now, FSUIPC7 only installs a hvar file for the A320, although there is also one available for the DA40-NG (although I haven't tried this). If you have an hvar file available for the TBM 930, maybe you could share it? Oh - and there are no values associated with hvars (as far as I know). You just activate or trigger them (which is what the Set command does).

Here's a reasonable description on the various varialbe types on the Asobo forums (https://forums.flightsimulator.com/t/demo-lvar-write-access-for-any-aircraft-control/353443/19?u=impolitegem5317😞 H variables can be used via the Panels execute_calculator_code function (which is what is used by FSUIPC7 for these variable types), so it may also be possible to do this with O: variables. However, as there is no direct support for O: variables in FSUIPC7 (as there is for H: and L: type variables), the only way to try would be to use the ipc.execCalcCode() function.

To use the lvars you have to use lua or a macro file. You can then assign to the macro (or lua, if not auto-running). As for the AS 1000 MFD RANGE INC control, maybe it takes a parameter (other than 0)? But it puzzles me why you are shoeing this as you were asking about master caution/warning...

Ah, you are using MobiFlight events... Presumably you have the MobiFlight WASM installed, no? Which FBW mod are you using? Maybe try switching mods, otherwise, as these are MobiFlight events, you will need MobiFlight support for this. However, most MobiFlight just trigger lvars or hvars. You could look at the available lvars/hvars for the A320 and see if there are any you can use instead of the MF events. And, BTW, the log you attached was a continuation log, so doesn't tell me much (not even the aircraft you were using). In future, when I ask for logs, please attach the full log.

This was an error in my config - I had updates turned off in both the WASM and the Client (LvarUpdateFrequency ini parameter). Working fine now.

Just tried these and they seem to work, setting 1 to activate and 0 to clear. However, when reading the values back, I am only getting 0 for each lvar. Not sure why at the moment - I will look into it.

Have you tried the following lvars: Generic_Master_Caution_Active Generic_Master_Warning_Active ? Here's the full list of lvars that FSUIPC7 finds for the TBM 930:

This is the complete list of event for the G3000 from the latest cip file (https://bitbucket.org/mobiflight/mobiflightfc/src/master/Presets/msfs2020_eventids.cip😞 If the events aren't working, you could ask over on the Mobiflight discord channel (https://discord.com/channels/608690978081210392/804777121255915562).

You can just attach it here.

I'm not sure what you mean... Do you mean the assignments to your buttons 162-179 are not working? Or that you cannot assign to those in MSFS? (and by keys, I presume you mean buttons, no? If the former (assignments not working), please activate logging for Buttons & Keys as well as Events, and produce a short log file where you press those buttons, then show me your FSUIPC7.log file as well as your FSUIPC7.ini file. If its the latter, then thats more a question for Asobo, but why do you need to assign in MSFS if they can be seen and assigned in FSUIPC7?

Has the SDK been updated for this? When was this update released? Could you send me the header file and I'll check it against the one we are using, to see if an update is needed. Thanks, John

Is FSUIPC running? If so, check your FSUIPC7.log file to see if /linda is being started, or post it here. If Linda is starting but can't find FSUIPC7 (and FSUIPC7 is running), then you need the Linda support forums.

The mapping from joy letters to joystick IDs is held in your FSUIPC7.ini file, in the [JoyNames] section. However, you should prefer to use letters over ids, as shown by Roman, as these will be fixed but the joystick IDs may change. If the IDs do change, its easy to update the mapping section to re-enable your assignments when using the Joy Letters facility. There is a section on Joy Letters in the User Guide (P20). This facility was also made active by default in FSUIPC7 - in previous versions it was off by default.

The first EXE.xml file is corrupt and is not even an xml file! It looks like it was updated by AFC Bridge, which I think is something to do with the Honeycomb Bravo (to fix the lights?). Do you use this? The second EXE.xml you posted looks fine, and should auto-start FSUIPC7. Is it now working for you? Is PACX now able to connect? If you want to add AFC Bridge back to your EXE.xml, you can try replacing its contents with the following: