Button Anomoly

[JoeB]

Hi Pete

I have been using FSUIPC with FS9, version 3.98a for some time without any problems until recently when I downloaded and installed the Level-D B767-300ER winglet version. Since fsuipc.ini was becoming really messy, I decided to rebuild it from scratch. Reading the manual, I found that to start with a clean file one should remove it in the “modules” folder, and FSUIPC will recreate a clean copy on the next invocation of FS9. I did so, but the “old” assignments were still active although the file could not be found in the “modules” folder.

Since Vista x64 is such a persnickety beast, I wondered if the OS had somehow moved the file elsewhere and created a hidden link. Thus, I turned on “Display Hidden Files” and performed an entire search of drive C:. Sure enough, the fsuipc.ini file was found in the, “C:\Users\Flight\AppData\Roaming\Microsoft\Windows\Recent” folder and a link file in the “C:\Users\Flight\AppData\Roaming\Microsoft\Windows” folder. Thinking this must be the problem; I deleted both, performed another search of C: without finding fsuipc.ini, and invoked FS9. The assignments were still active.

My next step was to wonder if the fsuipc.ini had been memory cached by the OS. I rebooted the computer, performed a search for the file once again without it being found, and invoked FS9. All assignments, except one were reset/cleared, and only for the Level-D winglet version. This is yoke button 0, aircraft specific (the general assignment for the button is clear), which has the following message in the “status” window of the Button + Switches tab, “This has multiple actions already! Please edit it in FSUIPC.INI.”

Well, I am now officially at a loss to explain this anomaly. Any suggestions that you have will be greatly appreciated.

Thanks, Joe

[Pete Dowson]

Since fsuipc.ini was becoming really messy, I decided to rebuild it from scratch. Reading the manual, I found that to start with a clean file one should remove it in the “modules” folder, and FSUIPC will recreate a clean copy on the next invocation of FS9. I did so, but the “old” assignments were still active although the file could not be found in the “modules” folder.

Since all of Your user settings are stored in the INI file and no where else at all, you couldn't have deleted the file in use.

Since Vista x64 is such a persnickety beast, I wondered if the OS had somehow moved the file elsewhere and created a hidden link. Thus, I turned on “Display Hidden Files” and performed an entire search of drive C:. Sure enough, the fsuipc.ini file was found in the, “C:\Users\Flight\AppData\Roaming\Microsoft\Windows\ Recent” folder and a link file in the “C:\Users\Flight\AppData\Roaming\Microsoft\Windows” folder.

Neither of those are placed by FSUIPC nor will they be read by FSUIPC.

Well, I am now officially at a loss to explain this anomaly. Any suggestions that you have will be greatly appreciated.

Are you running FS with the compatibility mode set to XP, or is it off or set to Vista? If it isn't set to XP mode it is possible that the INI, LOG and KEY files are kept in the Flight Simulator Files folder, in your Documents folder. This is a Vista thing.

However, I would have thought you would have found them there using search. So:

Alternatively, assuming you let FS install in its default location, in Program Files, then please see the explanation in a thread near here -- one explanation which unfortunately seems to have confused that user completely, as he appears not to be running Explorer "as administrator" in order to see and access the real folders as I suggested. The link is http://forum.simflig...installing-fs9/

Regards

Pete

[JoeB]

Good Day Peter And Everyone Who Have Read This Post,

I have discovered the reason for my problem. And, it is not only with regard to fsuipc.ini exclusively, but other files as well. It is how Vista (and in all probability Windows 7) handles file utilization.

Mea Culpa. When I performed the file search for fsuipc.ini, I did so using the standard file search. I should have searched using the Advanced search feature and checked the Include non-indexed, hidden, and system files (might be slow) box. Using this search, I found an additional copy of the fsuipc.ini file in the following folder: C:\Users\Flight\AppData\Local\VirtualStore\Program Files (x86)\Microsoft Games\Flight Simulator 9\Modules. It is this file the OS uses when FS9 references the fsuipc.ini file (and most likely other applications referencing other files). By editing this file the problem was solved. I also copied the edited file to the C:\Program Files (x86)\Microsoft Games\Flight Simulator 9\Modules location to ensure both files are in sync assuming that by preference the OS updates the normal file location with the VirtualStore file should a mismatch between the two occur at log off, although this was not investigated. Verifying the fix during the same session and then through a reboot confirmed the fix held.

Although I am a retired software engineer, I know little of the inner workings of Microsoft's operating systems. Having said that, I believe that Microsoft uses the VirtualStore file exclusively until the normal file location is updated when it also updates the VirtualStore file. I am assuming the root cause of the problem was a corruption of the normal file's location or some other attribute in the file swap table. Thus, when the normal file location was updated or deleted, the VirtualStore (read: virtual memory) file was not. Why a dual definition of the button and a swap table corruption occurred at the same time is a mystery. But then so is life.

Best Regards To All,

JoeB

Edited January 14, 2011 by JoeB

[Pete Dowson]

Using this search, I found an additional copy of the fsuipc.ini file in the following folder: C:\Users\Flight\AppData\Local\VirtualStore\Program Files (x86)\Microsoft Games\Flight Simulator 9\Modules. It is this file the OS uses when FS9 references the fsuipc.ini file (and most likely other applications referencing other files). By editing this file the problem was solved.

That set of FS9 folders will be the REAL ones FS9 is actually running from. When you install into "Program Files", Vista (and win7) protect the real folders for being written to (even by the program itself), and the ones it presents to you are just aliasses.

An easier way to see and edit the real folders is to run Explorer "as administrator" (a right-click option), as this gives it Elevated Administrative privileges. This is what I explained in the other thread I referenced for you.

The best solution, however, is simply never to install anything in "Program Files" if you can help it!

Regards

Pete