John Dowson

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.

@bertranda I've checked the code and the request for the 'IS USER SIM' variable on AI traffic was commented out, as it didn't exist in earlier versions of the SDK. It looks like this is now available, so I've added it back. Could you try the attached exe to see if this solves your issue, thanks John FSUIPC7.exe

Actually, I'll put this on my list to investigate at some point. i.e add a http (or maybe websockets) interface to FSUIPC. However, I don't expect to have time to look into this for quite some time. Any such interface would only expose reading and writing to the offset data area, as is supported by the current SDK. John

Yes, I'm afraid so. That's the 'Active Pause' which still can't be detected. You should switch to using one of the other pause controls - either Pause On/Pause Off, or Pause Set. John

@StefanGA Thanks for reporting back. Glad its now working ok (and wasn't an FSUIPC issue!). Regards, John