John Dowson

@aua668 Could you try the attach dll please. 6.1.1e: FSUIPC6.dll

Found another issue - FIRE_EngineHandleIlluminated and FIRE_APUHandleIsUnlocked are arrays of 2 bools not just single bools. Updated document attached, and the offset to check for COMM_ReceiverSwitches[0] is 0x6C5A. Offset Mapping for PMDG 777X.pdf

It is MSFS that starts FSUIPC7, not the other way around. Try starting FSUIPC7 manually (by double clicking the FSUIPC7.exe) to see if it runs. If so, show me your InstallFSUIPC7.log file. If it doesn't run, tell me what error you see. Its also in the system tray, not the task bar. When FSUIPC7 starts it displays a splash screen. If you see that, it should be in your system tray, if not, it has not been started.

Sorry, thats also wrong! Attached is hopefully correct, and COMM_ReceiverSwitches[0] should be at offset 0x6C58. Offset Mapping for PMDG 777X.pdf

This was reported as working a couple of weeks ago, after the last but one update. I haven't tried it with the latest version but should be ok - why don't you just try it (and report back!).

It shouldn't hang P3D. But you have errors in the script you should address first: Also, as I said, could you please activate logging for 'Extras' for such issues, as the thread id is useful. If you correct those errors and still have the same problem, show me the log again (with the Extras logging enabled) as well as the script.

Looks like OneDrive is screwing things up - this is strange: InstallDocumentsLocation=C:\Users\k7890\OneDrive\??\FSUIPC6 What is the '??'? You can try disabling OneDrive and re-install. Also you have installed FSUIPC in your Documents folder: Better to install in a directory outside of your Documents folder, somewhere like C:\FSUIPC6 or C:\P3Dv5 Add-ons\FSUIPC6. Re-run the installer (it will uninstall your current installation) and choose a different folder. If all else fails, I could help you to manually switch the the add-on.xml method, but there is not a problem if you just continue to use the DLL.xml method to auto-start FSUIPC6. If its installed via the add-on.xml method, you should be prompted to enable the first time you run P3D after installation, or ir can be activate/deactivated from the Options ->Add-ons menu. FSUIPC6 also appears there, but only when installed via the add-on.xml method. For issues getting GSX installed and running, you will need there support. I don't have GSX.

That is your FSUIPC6.log file (which shows its running ok), not your InstallFSUIPC6.log file.

What is add-on manager? It will be in your installation folder, and also in the folder where you ran the installer.

You don't need it - if that is not selected, the DLL.xml method will be used to auto-start FSUIPC. However, the add-on.xml method is preferable. Could you show me your iInstallFSUIPC6.log file please.

Ok. Try running the installer again, and this time uncheck 'add-on.xml' to see if that helps. If it still crashes, try again but also disable FSUIPC Documents. Are you installing for P3Dv4, P3Dv5, or both?

There is a time-limited license valid until 5th May that you can use here: This is normal in prop planes - see https://www.boldmethod.com/learn-to-fly/aerodynamics/why-you-need-right-rudder-on-takeoff-to-stay-on-the-centerline/. You could try logging axis events to see if any controls are being sent to the sim. You can also try assigning your ailerons in FSUIPC (direct to calibration) and calibrate there with a decent null zone.

When did it crash? What did you see? Is there an InstallFSUIPC6.log file? if so, please show it to me. Also, check the windows event viewer and show me the crash log.

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