John Dowson

Those files WILL be in your FSUIPC7 installation folder. If you don't know where that is, use the File -> Open Installation Folder... menu option. FSUIPC7 should not affect your GPU usage at all. Is your system very heavily loaded? If the CPU is being overloaded, it could affect your FPS... John

Hi Andrew, Well, I just looked at this again and it is working for me now...the paths I had used previously weren't correct. I tested with the below script and heard all three sounds: Could you adjust that script to use your local folders and sound files to see if you hear anything with that. Cheers, John

First you posted in an incorrect forum and in an unrelated topic, and then you post again and still do not provide any information, such as your FSUIPC7.log or the crash report from the event viewer... Please see: John

Why are you posting in the 'FSUIPC Client DLL for .NET' forum, and what has your issue got to do with the title of this topic 'Unpause MSFS 2020'? Please take care to post in the appropriate forum and give sufficient information if you would like any help. Are you even using FSUIPC7? If MSFS is crashing, you should check the Asobo forums and report there. If MSFS is crashing, it is not related to DSUIPC7 as this is a separate executable that runs outside of MSFS. If you require any further assistance, please post in the correct forum. Any further incorrect posts will be deleted without response. John

Are you running on Windows 11? If so, please try adding the following to the [General] section of your FSUIPC7.ini (as advised in the provided README.txt): DisableMSFSMonitor=Enum John

Ok, that's good. Maybe you could explain what the solution (and maybe also the actual problem). This may help other users who encounter similar issues. You don't need to understand the ini files. The file(s) are managed via FSUIPC. But you do need to edit these files manually occasionally, for activating certain features (such as running programs or luas automatically) or overloading/adjusting assignments for conditions or other more advanced techniques. But we endeavor to provide details of how to do this in the various manuals included. For support purposes it is easier for me to handle just the one ini file - 2 is not an issue but is generally harder to get hold of from the OP... As a user I also prefer the one file, but thats just my personal preference. Post your solution, if possible, and I will close this topic. Cheers, John

Then why are you using profiles in separate files? There is really no need, unless maybe you have very many complex profiles. I do not understand why people use this option - I think I will remove this from the documentation, so it can still be used if really needed, but not visible to new users... But, as I said, I cannot help you if you do not show me the files where your assignments are held. From your log, you certainly have things assigned. If they are not activating the correct function, it could be due to the mouse macros being misnamed, or the rectangle ids being updated, or other causes, but without seeing what your assignments are (and I may also need to see your macro files), then I cannot help. Maybe not when you look at the log. Nut, if you keep the log open and press a button, you can see what button is pressed and what assignment that is triggering, which you should be able to make sense of. But if not, don't worry, that is why I have asked you yo post them here so that I can take a look. Cordially

If you are talking about my suggestion to your profile name change, of course this would have no change as you are currently using the exact aircraft specified in your FSUIPC profile settings. I only suggested changing this so that it matches more than that aircraft/livery, so if you loadthe sane aircraft with a different livery, the profile will also be assigned to that aircraft. It has no bearing on your current issue, whatever that may be. To be honest, I don't think there is an issue, but I cannot tell until you have shown me the requested files.

FSUIPC7 trial license always avaliable here, and upon request if out of date: No idea. Sounds like a question for SPAD.next support. However, I suspect that SPAD.next can access lvars/hvars, but I have no idea if it uses FSUIPC or has its own mechanism. John

And please, if you still have issues, lets sort this out with one button. i.e. load your aircraft, press one button that you think is assigned incorrectly, then exit and show me the relevant ini files (main + profile) and logs. No point complicating things with so many other button presses for an initial analysis - the simpler the better. The issue is most probably the same for your other assignments. John P.S, Finishing now for the evening, so I will review any further posts tomorrow (maybe...!)

Your assignments, from your log, also seem to be mainly for mouse macros. I cannot help you with those, but you need to check that the rectangle ifs that are used are correct. These can change on aircraft updates. Did you create the mouse macros yourself and test them? Of not, then name may be different to the function that they actually operate. I suggest you review your macros and settings before posting again. Try with logging activated and the console window open, and you can see what is happening and what is being called in real-time. John

As you are using profiles in separate files, I also need to see your FSA320.ini. Probably better to also change your aircraft profile name, so instead of try for a substring match on other aircraft for that profile. John

I have no idea, what did you buy? If you are referring to FSUIPC7, you should have tried before purchasing a license - a trial license is available with full functionality. FSUIPC7 only recognises HID joystick type devices in the assignments panels. If your overhead is not such a device, then it will not be recognised in the assignment panels. However, HID non-joystick type devices can be accessed and assigned using lua and the com library. You could try that way. There is also a program in our downloads section called HIDScanner. You could try tunning that to see if that detects your device, and if so you should be able to program via using lua scripts. John

Images are of no use to me. As I said, I need to see your FSUIPC6.ini and FSUIPC.log files, with the logging activated as recommended (i.e. for Buttons + Switches and Events). John

You should be ok with your current version of WideClient on your client PC's, but you would need a WideFS7 license to activate the WideServer component built into FSUIPC7. All WideClient versions should be compatible with any WideServer version, but as you need FSUIPC7 you would need to activate the WideServer built into FSUIPC7 which requires a WideFS7 license. Hope this is clear. I can provide you with a time-limited license for both FSUIPC7 and WideFS7 if you would like to try this, once you have updated your FS PC to MSFS of course. You should try this before purchasing a WideFS7 license, and before taking the drastic step of updating your client PCs to windows 10/11. John

Yes, it is always unchecked when you enter the page. With button assignments, you can assign to the profile OR to the general section. All general section button assignments also apply to all profiles, unless overridden by a profile specific button assignment. For button assignments in profiles, the general assignments are loaded first and then augmented or overridden with the profile specific ones. This may be because you have a profile specific button for that aircraft. Did you try again checking the profile specific button, then press your joystick button to see what os assigned to that button in the profile? You should be aware the profile specific assignments for buttons and keys work very differently to profile specific axes assignments. The general section for buttons and keys is always loaded in each profile, and then updated from the profile specific assignments. For axes, only the profile specific assignments are used - this is why you have the option of 'importing' your general axes assignments into your profile specific assignments when you create an axes profile. If you are still having issues or do not understand your assignments, activate logging for Events and Buttons + Switches, produce a short log file where you just load the aircraft and activate the button, exit then show me your FSUIPC6.log file as well as your FSUIPC6.ini file and I can tell you what is happening and where you are misunderstanding the assignments, if that is the case. John

No, not necessarily... WideFS7 is 32-bit and should be ok on Windows XP, as WideFS7 is compatible with FSX that can also run on windows XP, no? But I will check with Pete to confirm - such old systems are before my time I'm afraid and have not any experience with such old systems with out products... John

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