John Dowson

Hi Andrew, yes, I have just tested this and found the same. Not sure what has happened, I will look into this over the weekend. John

I have no idea, sorry. What changed on your system? Where is that error produced? You can attach your FSUIPC log files - both the FSUIPC3.log an d installation log file and I can take a look to see if i can see anything. But FSUIPC3 is no longer supported - I have never used this product (or FS2004), but @Pete Dowson may be able to help if you provide further information. John

There is no 'newest Beta' - this topic is over 8 months old! FSUIPC7 has native support for up to 128 buttons since the release of v7.1.0 back in May But that should have been resolved by the Beta I do not understand what you mean by this... Could you please clarify what your issue actually is and provide the necessary files. Are you saying that your button number 33 is not recognised by FSUIPC? If not, can you check that you have the following parameter in the [General] section of your FSUIPC7.ini file: EnableExtraButtons=Yes Any further issues, please explain what the issue is and also show me you FSUIPC7.ini and FSUIPC7.log files. John

No, you need WideFS7 for FSUIPC7. Note that it is also possible to run FSUIPC7 on a client machine, but that only runs on Windows 10/11.

Sounds like you need to increase the null zone to stop the 'slightly left' when at rest, but the right rudder does sound like its not working properly. You could try recalibrating them - this will also show you the range of values the rudder is sending. Also maybe try windows calibration. John

Again, sorry for the delay. Please see: John

It is now possible to run FSUIPC7 (v7.2.13 and later) on a client PC, that is, a 2nd PC where MSFS is not installed. This should allow FSUIPC clients to be ran on the client PC and allow them to communicate to the FS without the need for WideFS/WideClient. Note that this DOES NOT replace or duplicate the functionality provided by WideFS. When FSUIPC7 runs on a client PC, it will maintain its own offset area distinct from that of the offset area used by FSUIPC7 on the FS machine. However, most offsets should contain the same data, as they are populated by the data received from the FS, but be aware of this if/when writing to user offsets (e.g. using lua). Note also that you do not have to have FSUIPC7 running on the FS machine to run FSUIPC7 in the client machine. The following functionality in FSUIPC7 will not work (or is not available) in FSUIPC7 when ran in a client machine: - no installer - you need to manually install/copy FSUIPC7 to the client machine - no possibility of sending key presses to the FS (key presses CAN be received) - no auto-start or auto-connection - .... To have FSUIPC7 running on a client machine, please follow the steps indicated below. 1. Configuring SimConnect on the MSFS computer Locate your MSFS2020 SimConnect.xml file. For steam installs, this should be under <Your User Account>\AppData\Roaming\Microsoft Flight Simulator and for MS Store installs under: <Your User Account>\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache Open the file in an editor, and add a Global (remote) IPv4 port by adding the the following entry: where Your Local MSFS PC Address is your 'internal' network IP address, not your outward-facing IP. To find this, open Command Prompt on the MSFS Computer, type "ipconfig" and look for the "IPv4 Address" listed under your active internet connections. You can also change the port number, but this MUST match the port number defined in the SimConnect.cfg in your client PC (see below). Note that you also may need to open this port in any firewalls that you may use (although I did not have to do this when I configured in my LAN). 2. Install FSUIPC7 in the client machine To install FSUIPC7 on a client machine, create an DSUIPC7 folder (preferably not under Documents, Program Files, or any other windows-protected folder) and copy across the following files from your MSFS computer: FSUIPC7.exe FSUIPC7.key (if using a registered version) You can also copy across your FSUIPC7.ini file, but it may be better to start afresh with this in your client PC. 3. Configuring SimConnect on the Client computer To configure SimConnect on the client PC, create a file called SimConnect.cfg in your FSUIPC7 folder on the client machine with the following contents: where Your Local MSFS PC Address is the same address as used in the client configuration (and the port also must, of course, be the same as the one used there). 4. Configure FSUIPC7 to run on the Client computer If you have copied across your FSUIPC7.ini, open this in an editor and removed any unwanted assignments/profiles. If you have not copied across your FSUIPC7.ini, run FSUIPC7 once and exit - this will create a default FSUIPC7.ini file for you. Open this file in an editor (e.g. Notepad++). Under the [General] section, add the following ini parameters: RunningOnClientPC=Yes UseSimConnection=0 and under the [WAPI] section (if using the FSUIPC7 WASM module on the MSFS computer) - create if necessary, also add the following: UseSimConnection=0 And that is all! To use FSUIPC7 on the client machine, you must manually connect once MSFS is up and running. For any issues or questions, please use/comment on this topic. John

Ok, just wanted to confirm this starts with offset 0x64BB, and that the preceding offset 0x64B7 contains the correct 4 bytes. From what you say, I assume so. We will have to wait for PMDG's response on this I'm afraid, as if there is a problem it resides with them, and not FSUIPC. Cheers, John

Ok, thanks - good to know. Note that the Advanced User guide does advise this: John

Btw, are you 100% sure that the 4 bytes/booleans for ENG_annunALTN at offset 0x64B7 are correct? The only thing I can see that could possibly cause issues is the ENG_AutoIginition_Selector variable at offset 0x64AE. As this is an int, it may need to be on a 4-byte boundary (i.e. at offset 0x64B0), but this should not be necessary with 1-byte packing, and if it is an issue then this would only shift the data by 2 bytes, not 4. Lets wait until we hear what PMDG have to say, but if you can re-confirm that the above for offset 0x64B7 that would be useful. Thanks, John

From PMDG:

I have tried this now and it seems to work fine here with Linda 3.2.6.1111 - the Linda GUI starts as expected....

A while ago I noticed a similar issue (i.e. the log reported the program ran with no errors, but the program itself did run) with VoiceAttack. But this only happened when the executable that the FSUIPC Run command was using was a link. Could it be that your F:\FS Programs\FSUIPC\linda.exe is actually a link/shortcut? If so, try changing to the actual executable. I will download linda to see if I can reproduce. John

The data held from offset 0x6420 (512 bytes) is bulk copied from the data received from the PMDG aircraft, so it must be a problem with the data being received. I will contact PMDG about this issue. I will let you know what they say if/when I get a response. Regards, John

I have done various tests here and do not notice any FPS drop when using FPS, so I think something else may be going on. Are you using any FSUIPC clients? If so, try disabling them and re-test. And are you starting any other programs via FSUIPC? I can't see your images too clearly but it seems that the thread loads were also very different in the screenshots. Could you do further tests, again just sitting on the runway and exiting then starting FSUIPC a few times - leaving it running for a few minutes and then exiting FSUIPC, wait for a few minutes and then restart FSUIPC and check again. Do that a few times to see if there really is such a drastic frame drop. If so, show me you FSUIPC7.ini and FSUIPC7.log files and I can check them, but I can't think of anything that FSUIPC can be doing to cause this... Btw, what monitor/FPS counter are you using? John

As your program path contains spaces, its better to enclose in quotes - try: RunIf1=CLOSE,"F:\FS Programs\FSUIPC\linda.exe" However, your log shows that the program was started without error: 203 Run: "F:\FS Programs\FSUIPC\linda.exe" Are you sure it isn't running, or could it be running but not displayed - did you check for the process in the task manager? John

As I have said, please show me the relevant files, the FSUIPC6.ini and FSUIPC6.log files. I need to see these files to investigae. There was a change to running programs from the [Programs] section in V6.1.6 for running programs that need arguments. Looks like this has affected existing run program entries, but I need to see those entries to diagnose this issue. John

Ok, thanks. So 0x64BB is FUEL_CrossFeed_Sw, so you are saying that ENG_annunALTN at offset 0x64B7 is correct, but the following values are shifted by 4 bytes? This is very strange! The header you attached is the same one I have, and this is the relevant part: which shows these values being consecutive in the PMDG_747QOTSII_Data structure, which is the data block copied to the offsets. So if ENG_annunALTN is 4 bytes at offset 0x64B7, the 4 bytes for FUEL_CrossFeed_Sw should start at offset 0x64BB. So I'm not sure what is going on at the moment. I'll take a look at this further to see if I can see anything in the code, and check the validation/history of the last PMDG 747 header update and get back to you. John

You are trying to install in your Documents folder which can cause issues, especially if using OneDrive which it looks like you are using. Try selecting a different installation location, e.g. under C:\FSUIPC6 or C:\P3Dv5 Add-ons\FSUIPC6. Best to uninstall first, using the Windows App management panel, if you can see an entry for FSUIPC6 there. If not, just re-run the installer and select an appropriate folder rather than accepting the default location (which will be your documents folder). John

First, you posted in the FAQ sub-forum, where it explicitly states NOT for support requests. I have moved your post to the main support forum. Please take care to post in the appropriate support forum. Also, please give your posts an appropriate tile, relating to what your issue is. A plea for help is not an appropriate title - it says nothing about your issue. I will update. As for your issue, I have no idea as I do not use ProSim or sioc (whatever that is), and you have not included any information as to what is actually driving your trim wheel. Is this configured/assigned in FSUIPC6, and if so, how? Maybe you can start by showing me your FSUIPC6.ini and FSUIPC6.log files. John

No problem. Thanks got reporting. John

Yes, it should be possible with a lua script. You can send the axis value to an offset, and then process that value how you like. The script would also listen for button press event, and if the last axis value received was within a certain (Idle) range, a button press would change how the following axis values are processed. When in 'forward thrust' mode, the script would send the "Axis ThrottleN Set" controls with the appropriate axis value as a parameter. In 'reverse thrust' mode, you would send the Thrust Decrement control. As the CRJ reversers seem to have 4 fixed positions (when set-up with a reverse zone, haven't tried with no reverse zone and using a reverser axis, will also try that), and not be on a continuous axis, you would need to maintain 4 ranges and send a Throttle Decrement control when entering a range and the axis value is greater than the previous one, and send a Throttle Increment control when leaving a range and the axis value is less than the previous one. I would need to check (again) the way the CRJ thrust works when the throttle in the EFB is configured for no reverse zone to confirm. I can take a look maybe at the weekend, and maybe provide you with a lua that you could use to customize to your needs.

Hi @light_blue_yonder, just checked this again and if I assign to "Axis ThrottleN Set" and 'Send to FS as normal axis' (no calibration), and you calibrate for 'hardware has reverser axis' and set the positions in the CRJ EFB (in options, second page), then the reversers activate in the lower part (that defined in the EFB) of each throttle axis. Have you tried this? Or is this not what you are trying to achieve? If you are trying to set this up as a type of 'reverse thrust toggle', i.e. to use the full throttle range for reversers, then this isn't going to work with this aircraft. John

Sorry for the delay in this... As Reinhard has said, your right brake calibration for the FSLabs profile looks strange (and very different from your general calibration). And it is always better to disable Linda, even if you think its not being used, as I cannot tell from the logs. You can try to calibrate in windows first (to check the range of the brake axes), but I think this is difficult/nit possible due to the need to 'press a button' to start the calibration, that normally isn't available from pedals (as far as I remember!). You could try with a stock/default aircraft. to see if your brakes work there - you can attach a log and I will take a look. Otherwise, some complex 3rd party add-ons sometimes don't work correctly when using FSUIPC's calibration facilities due to priority levels. You could try deleting the calibration for your brakes in the FSLabs profile, and re-assigning to the FS control, as opposed to 'Direct to FSUIPC Calibration'. Also, your logs show that controllers are ON in P3D. This may be ok, but we recommend that you disable controllers as P3D has a tendency to automatically re-assign your axes. As controllers are on, double check that you don't have also have assignments in P3D. John

Corrected in the attached version. FSUIPC6.dll All 3 of your attempts should work with this version. John