John Dowson

No, as the ini has nothing to do with registration, its the .key file that you need to update. Well, thats because there is no installer for FSUIPC7 at the moment! Instructions on how to register your WideFS key are included in the release note and also the provided README.txt file (included in the downloadable zip file). Please see one of those for details.

Yes, it looks like the route isn't updated in the MFD when you load a new flight plan. Its not an FSUIPC7 issue though, so you should raise this directly with MSFS via their support forums. Btw, I have also noticed that you can't seem to load/change a flight plan directly in MSFS without going back to the main menus and restarting. The Load/Save option seems to be restricted to flights (.FLT) and doesn't allow for changing the flight plan...

By the way, it seems pretty pointless using the offset condition on a toggle control on the same button. If the bit is set, it will send the toggle using one assignment, and if it's not set, it will send the same toggle control using the other assignment. So the same toggle control gets sent either way. Its the same as only having one assignment with no offset condition!

0D0C is 2 bytes, so you need 4 hex digits for the mask. Also, Beacon is the 2nd bit in the first byte, so the offset condition would be ...W0D0C&0002=0 and ...W0D0C&0002!0... (or just ...W0D0C&0002...) You can (probably) use as a byte, by using ....B0D0C&02=0 and ...B0D0C&02 Btw, you should delete lines 449 and 451. Looks like these were assigned to controls that no longer exist.

Ah, the luacom.dll! Sorry, I know nothing about that - its a 3rd party lua library. I thought you were referring to the lua com library, built in to FSUIPC. It seems that the luacom.dll is 32-bit and won't work in a 64-bit process. You could maybe try a workaround for UDP sockets posted here:

@LarryD Just noticed that you posted in the main support forum. There is a separate sub-forum for FSUIPC7-Beta/MSFS. Please use that sub-forum for future posts in FSUIPC7-Beta. I'll move this post to that sub-forum. John

Hi Bernd, First, you posted in the FAQ sub-forum, where it states 'NOT for support requests'. Please post support requests in the correct forum, which is usually the main support forum. How are you assigning the throttles? For PMDG Boeings, you should assign to FS controls and not calibrate in FSUIPC. The PMDG aircraft intercept the FS controls, in the same way as FSUIPC does for calibration, and use them directly. If you use “Direct to ...” (or even FS controls and then calibrate in FSUIPC) then after calibration FSUIPC sends the controls on to the sim at a lower priority level (to avoid the infinite loop). This results in two, probably different, values arriving in the sim and maybe at slightly different times, causing issues. Therefore please check your axes assignments and use 'Send to FS as normal axis' and do not calibrate in FSUIPC. You may also want to check the calibration of the two throttles in the windows game controllers panel to make sure they are calibrated the same. Regards, John Later: also check that you don't have throttle axes assigned in the sim. Best to disable controllers completely in the sim if you are assigning everything in FSUIPC.

Sounds like an MSFS issue, but I'll look into it and get back to you.

What do you mean by this? I thought it was/is working....

@pilotjohn I'll add this to my list and look into it when time permits.

That image shows that you don't have anything assigned to the axis. You need to assign the axis to a throttle control - check the first checkbox and select the Axis Throttle Set or Throttle Set (or the throttle control you want to use). Maybe you previously assigned it in a different aircraft in a profile specific assignment? Anyway, try assigning without a profile and try again. If you still have issues, please attach your .ini and I'll take a look.

Just checked the 747-10 for comparison. The master battery offset and toggle control work for that aircraft, but the fuel valves have the same issue.

I can confirm that, for the 747-8, the Toggle Fuel Valve 1/2/3/4 controls do not work, and the value of the simvar GENERAL ENGINE FUEL VALVE, used in offsets x3590, x3594, x3598 and x359C do not report the correct state of the valves. They are not updated. For the master battery in the 747-8, it looks like the Toggle Master Battery control works, but only for turning off and not on. This seems to be related to the ELECTRICAL MASTER BATTERY simvar (offset x281C) - this always seems to be 1. When you try to toggle this using the control, or update it directly via the offset, it changes to 0 then back to 1 almost straight away, even when the update works (and turns the battery off). Its probably the fact that the simvar is 1/on even when the battery is off which is preventing it from turning on. I will report this to Asobo.

If there is no Assignments menu, then it is running in 'unregistered' mode. This means that it could not find the FSUIPC7.key file in the folder from where it was started. Are you starting FSUIPC7 from the same folder each time? The next time you don't see the Assignments menu, try opening the installation folder (option available from the File menu) and see if the FSUIPC7.key file is there.

I'll take a look, but will have to be tomorrow...

Read the provided README.txt file, or the release note - they both contain details and solutions for this problem (under Issues). There are also various other posts on the same topic. Before posting again, please - read or search the provided documentation - check for existing posts for the same or similar issues Thanks, John

I have added those controls in the attached version if you would like to try them - they should now be in the controls drop-down in the assignment panels. FSUIPC7.exe

It's the wrapper that's slow. I'm not sure exactly what speeds you should be getting (Pete would know, but he's away until Tuesday), but I would have thought, as a minimum, you should be seeing updates through at > 10 Hz or more. Python would be interpreted which will slow things down. For faster speeds, you will be better off using the provided C SDK (UIPC_SDK_C) directly. I guess that the Python SDK is using this under the covers.

These events work, with BCD16 format (2 bytes), with the leading 1 removed. These are the same controls used by offsets 0x034E (COM1) and 0x3118 (COM2). With BCD16 format, you can set 25kHz spaced frequencies but not 8.33kHz spaced ones. For 25kHx frequencies, you don't need the 5 digit (or 3rd dp), as, for example, setting this to 0x1802 would set the frequency to 118.025, as can be seen by reading offset 0x05C4. The 8.33kHz spaced frequencies were previously settable via the 32bit int offsets (e.g. 0x05C4 for COM1 active, etc). These used additional controls (e.g. COM1 Radio Hz Set) imported from the guages that no longer exist in MSFS. It therefore does not seem possible to directly set 8.33kHz spaced frequencies at the moment. I will raise this with Asobo. Writing to an offset either triggers a control or can update a sim variable, depending upon the offset (and is distinguished by Ok-SimC and Ok-SimE in the offset documentation). Using lua, sending the control directly rather than going via offsets would be slightly faster as it sends the control directly and by-passes the offset monitoring, but they would result in the same action (i.e. control being sent) when that offset uses events/controls to update. John

Ah, sorry - there's also COM1/2 Radio Hz Set, which uses a 4 byte integer. That's what the offsets actually use. I'll do some more tests.

No, you need the 1 - that's why it's 5 BCD digits rather than 4. Later: not correct. its BCD with 4 digits, leading 1 removed.

How are you extracting them?

Are you sure? This was working in MSFS, but I think it is/was only showing AI traffic and not also multi-player traffic. Most, if not all, FSUIPC/WideClient client programs should work with MSFS, assuming the offsets/controls they are using are working in MSFS. I think some clients might have (had) issues due to the FS version reported though, but that should be trivial update. LittleNaMap doesn't use FSUIPC/WideClient. I think it uses the 32-bit SimConnect.

Ok, thanks for the update.

I think I've found the issue. Can you try the attached build please. Using this, I no longer get the TransmitClientEvent failures, even when using Track-IR: FSUIPC7.exe