John Dowson

No idea what that could be - the link you pasted works fine here. You can try this one instead: Install FSUIPC7 John

Why are you running FSUIPC7 with administration rights? That is not necessary and shouldn't be needed. Where have you installed FSUIPC7? Make sure that it is not installed in a Windows protected folder, such as Program Files. Can you start MSFS (and also FSUIPC7 if not auto-started), let it load, select and aircraft and get ready-to-fly, and then exit, and show me your FSUIPC7.log and FSUIPC7.ini files. Thanks, John

How are you assigning these? Can you attach your FSUIPC7.ini file. Also, produce a short log with logging for Buttons & Keys as well as Events activated showing your issue and attach your FSUIPC7.log file. Also, if the issue started after the FBW A320 update (which version?), you may be better of asking on the FBW discord channel (https://discord.com/channels/738864299392630914/738864300818432023). John

I'm not sure, sorry. Its been many years since I messed around with camera views, although its something thats been pending on my flight system now for several months. I'll be looking at this shortly, but in P3Dv5 which I still need to configure correctly for my system. Maybe others more familiar with camera configuration could comment. John

Maybe they still need a unique GUI? Most tutorials on the web (e.g. http://www.ontheglideslope.net/2016/05/18/how-to-creating-custom-cameras-in-prepar3d-v3/ - for P3Dv3 but still valid): Also check that your button/key assignments to the views are still valid/active for the different a/c. John

Please attach your fsuipc.ini file, not a photo of the screen. Also please activate logging for events and axis events, and generate a log file where you move the lever to the armed position, then exit, and attach the log file as well.

Please see the provided User guide. FSUIPC7 sits in your system try. You can open the main window from there, or use the default hot key, Alt + F, to open/close the main window. That is just the FSUIPC WASM module. FSUIPC7 itself will be installed in the location you selected or approved during the installation process. You should realy read the Installing and Registering FSUIPC7 document before installing, o that you at lerast understand where the various components are installed. Please take a look at that document, together with the README.txt and the User guide.

Each lua runs in its own thread and the variables are only global to the thread. To share a variable between luas, use the ipc.set and ipc.get functions - see the FSUIPC Lua Library document. John

Your installation folder now looks ok - the FSUIPC7.ini and FSUIPC7.log files are now present. However, that is a strange log you posted - was FSUIPC7 still running? The last entry in the log is after 5.5 mins, so nothing to do with your CTD after 5 hours of flying. Show me the log file after you next get the CTD. John

👍

Ok, then for some reason MSFS hasn't created the registry entries which tell FSUIPC7 where MSFS is installed. There is no much I can do about this. FSUIPC7 will still run ok, but this will have two consequences: 1. the FSUIPC WASM module will not be installed 2. the auto start component will not be available For the WASM module, you can download this from www.fsuipc.com, and copy the WASM module manually to your MSFS Community folder. For the aut0-start component, you can manually create the required EXE.xml file following the instructions in this thread: John

The easiest may to achieve this is to overload the assignments to the button by editing your FSUIPC7.ini file. Locate the assignment to the first lvar in the macro, it will look something like this: <index number>=P<joyId/letter>,<buttonId>,CM1:1,0 -{Macro <macro file name> L:ASCRJ_OVHD_LDG_LEFT}- then copy this line and duplicate twice, then change to give both a unique <index number> and increment the macro index, to end up with something like <index number>=P<joyId/letter>,<buttonId>,CM1:1,0 -{Macro <macro file name> L:ASCRJ_OVHD_LDG_LEFT}- <index number + 1>=P<joyId/letter>,<buttonId>,CM1:2,0 -{Macro <macro file name> L:ASCRJ_OVHD_LDG_LEFT}- <index number + 2>=P<joyId/letter>,<buttonId>,CM1:3,0 -{Macro <macro file name> L:ASCRJ_OVHD_LDG_LEFT}- You don't need to change the annotation/comment - FSUIPC will update this when it is next ran. If you do this when FSUIPC7 is already running, you can reload the changes from the buttons assignment dialog panel using the 'Reload assignments' button. John

The WASM will load any .hvar files whose name is a substring match to the aircraft name, as reported in the log (from the aircraft.cfg file). So A320FWB.hvar wouldn't match, so use FWB.hvar or TAM.hvar, or even the full "FWB TAM.hvar".

Do you have a Steam or MS Store version of MSFS? Have you ran MSFS at least once before trying to install FSUIPC7?

32-bit software/drivers can still run on a 64-bit system, as long as whatever is talking to it understands that it is a 32-bit program... I would just try it on a single system first. If you use/need FSUIPC, you can first try with a trial license, available in a sticky post at the top of this forum. WideFS7 is compatible with FSUIPC7, if you want to go down the client PC route. However I don't know anything about SimKits UCC2, so maybe other simkits users' opinion on how to get this working with MSFS would be more helpful. Maybe try the SimKits or Asobo forums. John

hvars are only recognised by FSUIPC7 if they have been registered via an appropriate *.hvar file, located either under the FSUIPC WASM installation folder or under your MSFS persistent storage area. See the Advanced User guide for details. If the hvars were previously available and are no longer visible, this suggests that either the *.hvar file(s) matching the aircraft name has changed, or the aircraft name has changed and no longer matches the name of the aircraft you are loading. So, please read the Advanced User guide so that you understand how hvars are recognised, and then check the folders. If you require further help, activate debug level logging in both the WASM and WAPI (instructions in Advanced User guide) and show me your FSUIPC7.log and FSUIPC_WASM.log files. John

Ah, yes - you didn't mention that! Ok, good. Sounds like the windows 11 installation may have screwed up the installed VC++ redistributables. Interesting. Cheers, John

i would try that. Of there is no .ini or .log files, that usually means that FSUIPC cannot write to the installation folder due to Windows protection. Try installing in a different folder (e.g. D:\FSUIPC7) and running MSFS again to see if the .ini and .log files are created. Nothing to do with your issue though. But for me to take a look at your issue, I need to see an FSUIPC7.log file produced form the session where it CTD'd. John

Strange, if that is the full contents of your installation folder. There is no FSUIPC7.ini either - have you assigned anything in FSUIPC7? From your installation log, I see you installed under D:\Program Files\fsuipc. Is D:\Program Files your windows Program Files folder, and thus protected? If so, you should uninstall and re-install in a different folder.

No, the FSUIPC7.log file, not the InstallFSUIPC7.log file. I don't really need to see it if it says that FSUIPC7 exited normally due to MSFS no longer being available. Just take a look at the log file. You can post it if you like.

In your FSUIPC7 installation folder - if you don't know where that is, use the File->Open Installation folder... menu option from FSUIPC7. If you can't see the FSUIPC7.log file, see the annex in the installation and registration guide. John

Even stranger.... I suspect something is wrong with your windows installation. I'll take a look (maybe later today, more probably tomorrow) to see if I can add some extra logging to see what is happening. In the mean time, can you try uninstalling your VC++ redistributables and reinstalling - instructions are in the README.txt that comes in the zip download. John

Can you please show me your FSUIPC7.log. I suspect that it was MSFS that CTD', and FSUIPC7 exited normally due to MSFS no longer being present. The log would confirm this. This can generate a windows fault event in FSUIPC7, but there should be a preceding event that indicates MSFS has crashed. If this is the case, you should report to MSFS, as you have done. John

This is very strange! Could you try manually starting FSUIPC7 before MSFS, and uncheck the option 'Exit with FS', then start MSFS. FSUIPC7 will then attempt to re-connect when it thinks MSFS is no longer available. Please try this and show me the updated FSUIPC7.log file. John

Good to hear! Yes, I think the custom events (those with a period '.') get translated by the handling code in the MSFS/WASM. In FSUIPC, you always need to declare (and assign to) custom events with an embedded period. Thanks! John