John Dowson

There was an error in that version. Please find the corrected version attached:. Could someone check the data at offset 6C53 (COMM_ReceiverSwitches[3]) is correct as this would verify that we have the correct packing. Thanks. Offset Mapping for PMDG 777X.pdf

What are the button numbers for your rotary? This line should just contain the rotary button numbers: Rotaries = { 0, 1, } Are 0 & 1 the button number you see when you turn the rotary left/right? If so, thats ok. However, when you assign in FSUIPC, you need to assign to the virtual button flag. If you are using offset 0x3340, this should show as joystick# 64, with different button numbers for slow and fast om each direction. You should assign your slow inc/dec to the slow buttons, and the fast inc/dec to the fast buttons. You should not assign to the physical rotary buttons, but the virtual flags the the lua sets. It will set one flag for slow left, another for fast left, another for slow right and a 4th for fast right. If you see the physical buttons being registered, you can ignore these by using the IgnoreThese ini parameter in your [Buttons] section.

I'll take a look in detail tomorrow, but on first glance you are only assigning to the HEADING BUG INC/DEC. and not the fast options. Try with: Rotaries = { 0, 11, 1, 10 }

Here is the updated PMDG 777X document: Offset Mapping for PMDG 777X.pdf

Yes, sorry, there was previously data populated in the offset are starting at 0x6C00. However, this now has additional data which will be added at the end. This is the following: I need to update the documentation and add those. Also, of course, the CDU data is now available for the 777, so I need to add that to the document. I'll take a look at this over the weekend and release with the updated documentation sometime next week. John

The 6.1.0 release has support for up to 128 buttons. Buttons 32-39 are reserved for the POV buttons. To revert to previous behavior in 6.1.0, you can set the following parameter in the [General] section of your FSUIPC6.ini: EnableExtraButtons=No You could try this. However, event.button should certainly still work for the POV buttons 32-29. I will look into why this is no longer working. Another option to try (while I look into this) would be to switch to using event.offsetmask using the extended button flag area at offsets 0x7F00 - 0x7FFF. John

That looks like an interesting tool - thanks for the link Reinhard. John

I'm surprised thats running as your [Auto] section is not correct! If its running, its because its assigned to button 6 on your BU0836 Interface device, and it runs when you press that button. To auto-run your Rotaries.lua, change your [Auto] section to: See P36 of the Advanced User Guide.

This is not correct. For the correct vendor/product ids, look for this line in your FSUIPC7.ini 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. Sorry, that's not correct. You can use the strings for product and vendor - I just never use them this way and forgot about that, sorry! What does you ipcReady.lua contain? Note that this is a special lua and is ran automatically, so doesn't need to be in the [Auto] section to be started, thats why its running and the the rotaries lua not. What does the log say for this? This isn't listed in your [LuaFiles] section you posted - is it in the correct location? Having lua plugins logged is good, but best to de-activate the option to log separately - only needed for long complex luas. For simple luas, its better to have them logged in the main FSUIPC log file. So, please try again with that option disabled, and if you have issues attach your .log, .ini and the .lua files you are using.

I can release once I've updated the documentation. I'll take a look at this next week, so maybe release later next week, but I don't think there is any need to rush (as the updated dll is available). Ok. Maybe @Paul Henty could advise if an update for this would be needed for his .net client dll, and if so we can coinside the releases.

Yes, or to link them maybe...however it works in the actual aircraft...

Ok, that's exactly what I needed to know, thanks. I don't think there is any need for further checks - if they are in the correct position, so should be the rest of the data. No, they both look fine, just different timings.... The 6.1.1.d one does look a bit strange though, as it looks to be trying to kill the DevCom thread prematurely, before its given time for any luas to close rgus down themselves - although this seems to happen later, which is strange! One thing you could do to make the log a bit easier to understand would be to also activate logging for 'Extras'. As well as a few extra log messages, this also adds the thread id sending the message, so its a bit easier to understand which thread each message is coming from. Just FYI. Cheers, John

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.