DaddyBooks

%PROFILE% doesn't exist but the referenced Personal HKCU key value did the trick as it was, indeed, set to the original (undesired) account name. Quite curious that Microsoft doesn't dynamically allocate those Shell Folders when the user logs in and starts the Windows shell. That original account name must persist somewhere in the internals of Windows but this got it sorted. I still may go for the new install as I lack confidence that my "hack" is sustainable. Other software may suffer as your's did. I had been doing this all along to try to start clean each time and even re-installed P3D numerous times. Your uninstaller did indeed remove out all traces of FSUIPC6 but, in this instance, appears that the HKCU value had precedence. Thanks for enduring my question. This was not an issue of your making and FSUIPC6 works as always. I must say you have one of the most tidy installation and de-installation protocols I have seen in Flight Simulation. Have a wonderful evening and stay safe and healthy... ...DaddyBooks

Thanks. I first consulted the documentation on all of this and appreciate you reinforcing what I had already read. I believe this is a circumstance ascribed to me having changed the Windows Documents location in the registry after changing the account name. It appears correct as the shell value for %USERPROFILE% resolves to the correct value of C:\Users\737NG which is the correct new account name and seems to reflect that the Documents folder is changed. Based on what you've confirmed, I would expect that to be the the correct value. However, given the use of the "previous installation location of FSUIPC6", I wonder if I need to check wherever you store that value. Perhaps that very first installation of FSUIPC6 on the clean machine set some value that remains and is subsequently being used on subsequent installations. The only FSUIPC6 registry values I see beyond references to the uninstall program location are at HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\FSUIPC6v5 and are the expected new account value. I've searched the registry again and can't locate any other references. I may be forced to reinstall Windows to clear out the old remnants. Again, this is not an issue of your making but I'm trying to minimize re-work. Thanks again... ...DaddyBooks EDIT: Apologies for the duplicate images. I cannot locate a method to remove uploaded images and they auto-attach to the message.

Greetings... I purchased a new computer that helpfully already had Prepar3D and the most recent download of FSUIPC5 downloaded and installed for me. Unfortunately, I had to change the user account name in Windows 10 in order to work with my sim network. Subsequent installations of FSUIPC are now creating the FSUIPC documentation and add-on.xml in the old documents location which the installer helpfully re-creates. Everything else for the installation is installed in the correct \Documents\<new-username>\. Interestingly, the add-ons.cfg in the AppData\Roaming\Lockheed Martin\Prepar3d v5 directory point is referencing the correct location where I expected the add-on.xml to be installed. I have temporarily moved the relevant files to the correct directory which has me up and running but I would like to sort this out so future upgrades function properly. I've exhausted my ability to troubleshoot this having removed and re-installed Prepar3D and FSUIPC a number of times. I also removed all of the old AppData content that had any references to my old username that I could find and have searched through the registry and environment variables for any references to the old username without any success. I'm obviously missing something. Can you steer me to what the FSUIPC installer uses to identify the location where these important files are created (apparently referred to as the Documents folder location) and I can change that to the correct reference. I recognize this may be of my own making by changing the username but I though the Prepar3D and FSUIPC removal and re-install would sort it out with no success. Install log attached. For reference, the old-username is Visual and the new username is 737NG. Thanks for the great utility and now the update for FSUIPC 5. It has been a close friend in my simulator for many years. ...Robert (aka DaddyBooks)InstallFSUIPC6.log EDIT: I apologize but I inadvertently posted in the wrong folder. This is an FSUIPC6 question and not related to FSUIPC7 or MSFS.

I made the request of them in a formal support ticket. Let's see how they respond. The mechanism for the 777 and the 737 is exactly the same now that I have had the opportunity to look at the .h files and sample code in detail. In fact, they use the same ID although the structures are different layouts and a different size data block. The interfacing mechanism appears to be consistent between both FSX and Prepar3D although I am looking at the NGX on FSX and 777 on Prepar3D so I need to see the product on both platforms to be sure it's the same. I would provide you the .h personally today but am afraid it would violate their EULA. I've asked if they will allow me. Let's see how they respond although, to be fair, I am but one customer and not someone they would know. Thanks... ...Robert

I would be happy to purchase you the required software for both FSX and P3D so you would own the SDK. You've done such a service for a hobby I truly love that it would be my honor. I will also be happy to act as a tester for both the 737 and the 777 on both FSX and P3D. The NGX on P3D is not yet released but I will be purchasing it once it is available to the market. Please send me a PM to discuss if interested. In parallel, I will open a support case with PMDG to see how to accomplish that appropriately within their EULA. I will also ask if they will simply allow you the SDK as you suggested. I recall from reading their EULA that they are very precise in how the SDK may be used. It appears they granted permission for this with the NGX and aligned with the exclusions and disclaimers you included so I'm trusting support for the 777 will not be an issue. I'm also looking at your SDK but it seems a bit daunting. I still may dig in as an intellectual exercise just for fun and so I can add C to my list of languages I have dabbled in. ...Robert

Hello Pete... Posting this in anticipation of your return. I am hopeful you were away for holiday and trust you had a wonderful and restful time. I have a 737 flight deck that was greatly enriched by your courtesy of mapping the PMDG 737NGX data structure to a series of offsets in FSUIPC. I have interfaced the associated controls as well by making the associated event calls both directly from the FSUIPC interface and in a few bits of LUA I have developed for certain use cases. PMDG have now made a SDK available for their wonderful 777 aircraft which I have now chosen to purchase given they now support Prepar3D. I can fully appreciate that you are not in the business of mapping every aircraft product into FSUIPC or you would never have time for a holiday. However, can you provide any guidance on what mechanism(s), if any, may be available for me to effect a similar type of offset mapping for the read-only values given the similarity of the interface between the 777 and the 737? Again, I am not asking you to support this but curious if there is a mechanism to accomplish something similar from FSUIPC given I have the .h file. I have done development early in my career but am not all that experienced at C variants or SimConnect but can dust off my Visual Studio and have a go if that's the only way to get to my desired end-state. The 777 data area definition has the same ID (0x4E477831) as the NGX data area definition that you interfaced some time ago so this may be as simple as me creating a different data map using the existing offset range (6420-64FF) allocated for the NGX using the 777 header file to identify the structure. I've not yet spent enough time to ascertain whether or not the structures are of different sizes but believe they must be given the significant differences between the aircraft. Should the 777 be a smaller data structure, I hypothesize that it must work since they both map to the same control ID but I'm afraid I am still trying to understand the internals and interfacing. If, instead, the data block is larger, I speculate that anything beyond the allocated address space would not be available. It's worthwhile to note that I am hopeful that the NGX SDK may be extended in the future as there are a few annunciators and the electrical values that were, for some reason, not included in the first round so we may need to have a go at something for NGX at some point in the future. In summary, I'm willing to try to sort it myself but could use a bit of guidance. Apologies in advance if I missed something foundational in your documentation. The control events are quite straight forward so I have that sorted. Anyhow, trust you are warm wherever you are and thanks in advance for any thoughts you can lend on this topic. Warmest Regards... ...Robert (aka DaddyBooks)

Pete... Many thanks for looking. No disappointment on my front. I had a suspicion that there might not be a straightforward way to intercept a control call. My original plan was in alignment with your recommendation to reverse the function. I was trying to keep the number of calls to FSX as minimal as possible in anticipation I might use this more widely in the future. It will not be a problem for the less than ten (10) controls I need to address at module start-up. Again, my thanks for your software and for the courtesy of looking into this for me. Have a wonderful weekend. ...Robert (aka DaddyBooks)

Greetings... I have a desire to suppress a small number of FS control calls being written by a hardware interface (external .EXE) when first initialized. The developer of the software is overwriting the desired initial aircraft state using a view of a number of switch positions different than that desired. I've written a small piece of LUA that uses event.control to trap the events. What I am seeking is to suppress the events a single time from within the processing function and I will then event.cancel the functions so that subsequent calls to those FS controls are not impacted. After much digging, I'm not aware of any mechanism to suppress a FS control in this manner. I also tried event.intercept on an IPC offset of 0x3110 with a type of UD as well as SD thinking I could simply defer the ipc.writeXXX and the event.intercept never triggered. I suspect that the executable is making an external call outside of FSUIPC's purview and event.intercept is therefore not able to see this offset. FSUIPC does log the events so perhaps I am not calling it properly. Is what I am trying possible? The alternative is to write additional functions to set the switch positions back to the desired state which I can do if this approach is not possible. I was trying to avoid the "repeated switching" that takes place with that approach. I find that I am using FSUIPC all the time and I am grateful. A very clever piece of software which has solved many interesting challenges. My foray into LUA is now proving very interesting. Thanks in advance for any insights... ...DaddyBooks