John Dowson

@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

The COM_RADIO_SET and COM2_RADIO_SET controls only accept BCD with 4 digits, so it doesn't seem possible to directly set 8.33kHz spaced frequencies via simconnect at the moment. I'll report to Asobo. There are new sim variables which give the frequency spacing used. I have added these at offsets 0x0B47 (COM1) and 0x0B48 (COM2) - available in the next build update/release. These are also settable. 0 indicates 25kHz spacing, and 1 8.33kHz spacing.

Not using key press assignments. You can achieve this using lua scripts, by using ipc.keypress (or ipc.keypressplus) and ipc.sleep for the delay. You would then have to assign a different key press (or button) to activate the lua script.

That's great, thanks Paul. John

I've been thinking about this a bit and it should actually be pretty simple to implement, so I'll add it to my 'to be implemented' list. However, with FSUIPC7 for MSFS being the priority at the moment, it will take some time before I can get around to looking at this in detail. I will implement as a plug-in dll, so I can add extra features not available in the SDK, such as a direct 'control/event' interface, not via offsets. Also, it should be reasonably straightforward to implement as a separate process, using one of the provided SDKs. All that is needed is to add an embedded http/websockets server, and then exposed the FSUIPC SDK functions as endpoints. The most developed/used SDK at the moment seems to be Paul Henty's .net client. Maybe @Paul Henty has already considered this? John

Yes, or at least it is in the Cessna Citation CJ4. I will report this. Later: reported.

Who knows! I could report this and it may get fixed, but if you check offset 060C first this should be valid for all flight sims, so it doesn't have to be specific for MSFS.

@zkiwi Ok, thanks for the update.

Hi Nick, yes, seems that way. However, you can check offset 060C (gear retractable flag), and if that's 0 then you can ignore 0x0BE8. John

The main window of FSUIPC7 is currently empty, and all panels are accessible from the menu bar. For the time being, the main window is just a menu bar really. I am planning to add 'button screen' functionality to the FSUIPC7 main window at some point, as provided by WideFS.