John Dowson

You should always check the changes.txt document when you update. In 7.4.12, the default auto-start method has been changed from using the EXE.xml method to using the MSFS.bat, so what you say doesn't make sense. For all issues with auto-start, please see the following FAQ entry, and if you still have issues after reading that then please post in that topic and I will take a look: That log file you attached shows that FSUIPC was working as expected - the WAPI was started/connected. lvars/hvars were received and your lua autos started. The only error is this: and that is because it is being sent too early, before the WAPI has been started/connected. You cannot use presets/calc. code before the WAPI is ready. Re-run the installer, and at the components selection page, select the EXE.xml auto-start method only, i.e. open the auto-start options, de-select the MSFS.bat method (first option) and select the EXE.xml method (second option). But really should not need to do this - the MSFS.bat method should work fine, once your start-up options have been tuned correctly. I would try this before changing auto-start methods. Your ini also shows one issue - a missing device: Are you not using this anymore (replaced by the T.A320 Pilot perhaps)? If not using this any more, you should remove all assignments to the A device, and also remove those two lines from the [JoyNames] section. If you still have and use this (i.e. connect it for certain aircraft) then ok to leave everything how it is. However, you could get some strange issues if you have the T.Flight Hotas X connected at the same time as the T.A320 Pilot, as you will have the main flight controls assigned to two controls which can conflict and cause sudden jumps on the axes. You should also update this: to this: i.e. use substrings for your aircraft profile names to catch more variants And looks like you manually added something to the LuaFiles section: That 2nd entry is invalid, and the section should be: The [LuaFiles] section is maintained by FSUIPC and should NOT be manually edited. John

Looks like the WAPI is not enabled - could you please attach your FSUIPC7.ini file as well so I can check this. Also, please try the following: - check that the WAPI is enabled (i.e. in your FSUIPC7.ini you should see something like: - in your FSUIPC7.ini file, change or add the following: DetectToConnectDelayAuto=60 InitialStallTime=20 StartUpTuningActive=Yes then run MSFS and let it start FSUIPC7. When MSFS gets to the main menu, exit then restart. The first run will tune your parameters, and then these will be use in the second. Then try FSUIPC7 and see if it works. If not, restart FSUIPC7 - does it then work? Any issues, please attach your FSUIPC7.ini file and your FSIOPC7.log and FSUIPC7_prev.log files. You can also maybe try with another aircraft - people reporting this issue seem to be using the Fenix A320. I think this may use a different camera state during loading and FSUIPC7 may not be starting the WAPI because of this. John

First, you posted in the Announcements sub-forum, where it explicitly states NOT for support requests. Please take care to post in the correct forum for support - I have moved your post. That statement is of no use. What exactly is not working? Can you at least attach a log file? These are the known issues with 7.4.12: 1. Controllers/devices that have a vendor ID of 0000 are no longer recognised. This is a mistake on my part and an easy fix is available for this (i.e. adding IgnoreDevice=0xFFFF,0xFFFF to the [JoyNames] section of your FSUIPC7.ini file, as well as a new version available (see topic Missing Joystick - Fulcrum One Yoke). 2. Key presses sometimes not received by FSUIPC7, so key assignments and application hot keys no longer work. This is due to timing issues and has been a recurring problem for quite a while. The fix for this is to tune the start-up parameters correctly. 3. FSUIPC7 just not working (i.e. no assignments, no lua, etc). This is due to auto-tuning setting very high values, usually as it has determined the values during an MSFS update. The result of this is that FSUIPC seems to not work as it is still waiting to connect and start everything. Just wait, and things will eventually start. or if you exit and restart FSUIPC7, everything should connect. The fix for this would be to either force another auto-tuning run or to manually tune the start-up parameters. See the section on auto-tuning and start-up parameters in the Advanced User guide. 4. Issues with auto-start. The switch to using the MSFS.bat file rather than the EXE.xml file to auto-start FSUIPC7 has caused issues for some people, especially if FSUIPC7 is installed in a windows-protected folder (e.g. Documents or Program Files). The easy way to fix this is to use the EXE.xml auto-start component rather than the MSFS.bat method, selectable in the Components page of the installation process. There is a FAQ entry on this topic: FSUIPC7 auto-start with MSFS2020. What problems exactly? It really is pointless posting if you are not going to provide any details. And for any issue, you should at least include/attach your FSUIPC7.log file.

Yes, that used to be the best way to assign. However, as many aircraft in MSFS, especially add-ons, use lvars, hvars, input events or a combination of all three via calc code/presets, and all of these are aircraft specific, you will probably find that you need a specific profile for many aircraft. It is still useful to initially start with profiles as you say, but if you find you need to use an aircraft-specific control for one function, you can then create a specific profile for that aircraft. John

You posted in the wrong topic - there is a temporary fix for this issue as well as a patched version available in the following topic: John

👍Looks good!

@fjschoute How did it go with that Key file? Did it validate? If so, why are those details different from the ones you entered? If it doesn't validate, does FSUIPC still run as registered? I am interested to know why you could not register correctly.

Yes - your a) log shows that key presses were not being received, and you also had a couple of re-connections, and this is the only test where FSUIPC7 was auto-started. I still don't understand why key presses are sometimes not being received, but this also looks like its timing related. Can you therefore set the following values for these ini parameters: These will delay the initial connection attempt by another 10 seconds, and allow more time for the response, hopefully reducing these re-connects, and the -1 will prevent auto-tuning from changing these values. If you get this issue again (FSUIPC7 not receiving key presses), can you first try disconnecting and then reconnecting (from the MSFS menu option) to see if that corrects it, and if not then restart FSUIPC7. John

Yes - you should assign it to the same profile (it is the same aircraft!) and not create a new one. Better still, once you have created a profile, it is always a good idea to open your FSUIPC7.ini and change the aircraft name just added to the profile to be a substring of the aircraft name that matches all aircraft, regardless of liveries. I have done this now for yo now, except for the Skymaster profiles which you need to sort out yourself. Once this is done, whenever you create a new profile or add an aircraft to an exisiting profile, get into the habit of then editing the aircraft name in the profile and shorten it to a string that matches the aircraft you want to capture in the profile. You can also use the ini parameter UseAirLocForProfiles which changes the way aircraft are matched to profiles. See the Advanced User guide for details. If you switch to using this method, you will have to redo all your profile mappings (NOT the profiles themselves). I can help if you want to try this. By using profiles. All axes assignments are profile specific, so aircraft with a stick should use a profile (maybe the same one, maybe there are a few different stick-profiles) with the stick assigned to the aircraft axes, and the other profiles would use the yoke. You can also assign the "other" device's axes to something else, or leave them unassigned, but just don't assign them to the same aircraft axes (elevator, aileron, throttle, mixture, prop pitch, rudder, left/right brake). Cheers, John

As I said above, there really is no point re-running the installer as this does absolutely nothing for this issue. A re-installation of the same version installed (using the same locations and selected components) will make no difference to anything (except in the extremely rare case of some sort of file corruption). It can't do any harm either.

Use case 1,2 shows lua WAS working. What wasn't working was the WAPI so the scripts were failing when trying to access lvars/hvars or execute calculator code. This was bacause the WAPI was disabled (in your ini file). So this behavior is expected. Again, this is because the WAPI has been disabled. Please enable this and do not disable again please (unless instructed) as this is confusing matters. This doesn't necessarily imply that the lua scripts were not running. They were just not functioning correctly due to the WAPI being disabled. Not sure, but will be something due to no access to the WAPI functions causing the script to mis-behave, The prev log shows no access to the WAPI, again because this is disabled. The other log looks good, so you must have enabled the WAPI. However, looks like you attached this when FSUIPC7 was still running or had crashed. Can you please always exit FSUIPC7 before attaching logs. If it did crash, this is more serious and I will need further information. I think the initial problems were due to using 7.4.12c after installing 7.4.12, which gave incompatibility issues in the WAPI preventing access to lvars/calc. code, etc. Then when you updated back to 7.4.12, the WAPI was disabled. Yes - re-enable those functions. May as well keep using the 7.4.13a version I gave you, with the extra logging, and post your files again if you get issues.

How do you know this? There is nothing in the logs. But the FSUIPC7 did not stop, did it? Did FSUIPC7 hang or was it still running? Please always exit FSUIPC before attaching logs. The logs just show you restarting the WAPI connection twice. This will not restart your luas as FSUIPC thinks they are already running. It is strange that there is no message stating the number of lvars loaded, but there may not be one if not starting luas. I need to see the lua file to make sense of the log, but it looks like it was still running to me. if the thread had crashed, this would have been reported in your FSUIPC7.log file. So I still don't understand why you think the lua has crashed. Also check that you don't have the MSFS option End Flight When Aircraft Shuts Down checked. I prefer to see lua logging in the main FSUIPC7.log file rather than separately as well - it is easier to make sense of things seeing everything in chronological order. I see you have posted more files while I was writing this - I will check them tomorrow. Finishing for the day now. John

P3D will not recognise PFC, but FSUIPC will. However, your logs show the PFC driver was not loaded. Are you sure you put the driver in the correct location, which is: C:\Program Files\Lockheed Martin\Prepar3D v4\Modules\ ? It could be because you have installed under the windows folder Program Files. This has some restrictions and you may need to run FSUIPC6 with admin privileges if running there, and so also P3D and any other add-ons you may be using also need to be ran with admin privileges. Better to re-install FSUIPC6 in a non-windows protected folder (e.g. C:\FSUIPC6 or C:\P3D-Add-ons\FSUIPC6) No idea what that is but you certainly don't need it and shouldn't install it. It is for FSX, not P3D. John

@Luigi Martinelli You are using a very old version of FSUIPC7, v7.3.20 from April last year. Please update to the latest and only supported version, 7.4.12. John

But now you have assigned to a missing joystick: The mode switch is on the throttle so you need to change those E's to A's (and remove that missing joystick entry). You should also use substrings for your aircraft name(s) in the [Profile.xxx] sections. I have made these changes in the attached FSUIPC7.ini file if you could try it. Any issues, please activate logging for Buttons & Switches and also attach your FSUIPC7.log file together with your FSUIPC7.ini file. John FSUIPC7.ini

You have assigned two of your Logitech Extreme 3D axes to the elevator: So what is happening is that you are moving the elevator assigned to the Y axis, and occasionally you are getting a signal from the R axis which is resetting the elevator position to that axis. Remove that 2nd assignment - the one in bold (best to do this when FSUIPC7 is not running). You should only ever assign one controller axis to each aircraft axis per profile.

But that log file you pasted shows the luas were loaded? No, not a coincidence. As I said in my previous post, the issue is that the WAPI isn't being started (it was enabled but not running). By disabling it and re-enabling it, it started running. If you can provide me with a log file showing the WAPI not being started (with the additional logging in that version I posted) then I can correct for this. It seems the root cause of this is a change in order of events from MSFS which I need to correct for. Maybe specific to the Fenix - have you tried other aircraft? It would also be useful if you could add logging for the pause state offset 0264 (Log->Offsets) as U8 in hex (with Display to 'Normal Log File' checked).

I have not heard a report yet of the WASM crashing. You also only showed a prev log for this - there must also have been a current log. And switching back to the beta version confuses things...Anyway, forget this for now as I don't think this is your issue - we can return to this if it happens again. Auto-tune did run and set quite a high value. It can do this if/when MSFS is updating, or maybe if using a complex aircraft on previous flight. If this is too high, this just means that it will take longer for FSUIPC to connect and be ready. What is happening now, is that auto-tune is running and detecting no issues, so it is reducing the detect-to-connect time by 10 seconds and will run on the next execution. This will repeat until it detects an error or gets to the minimum time set (30seconds). Once it gets an error, it will determine the times needed, set them and then finish. So, it reduces until an error is detected, then increases and finishes. As your current DetectToConnectDelayAuto is set to 300, this could take quite a while. This is why I asked you to set: InitialStallTime=15 DetectToConnectDelayAuto=60 which will most-likely give a connection error (or several), but then the times will be correctly set and the auto-tuning will finish. Looking at your latest logs, it seems that the WAPI was not started. This looks to be a strange timing issue, where the WAPI is not being started as the either the aircraft is still in the parking state or the sim is in a pause state when it is supposed to start. This will be due to the state of the MSFS and the aircraft being loaded at the time FSUIPC7 is starting things up. I need to know the state of a few things before I can correct this, so can you please try once with the attached version, which has additional logging added. Run MSFS with this installed and have FSUIPC7 auto-started. If the aircraft loads but your lua no longer load, try going back to the main menu and then start the flight again. Do they then load? Please show me your FSUIPC7.log from thjs test. Then (if luas still didn't load), exit FSUIPC7 and start it manually - do the luas then load? Please show me the log file from this test. Rename your FSUIPC7.exe (to FSUIPC.exe.7412) and use the attached version for this test: FSUIPC7.exe Then please try changing the settings to: InitialStallTime=20 DetectToConnectDelayAuto=60 StartUpTuningActive=Yes Then run MSFS again to get FSUIPC7 auto-started. Once MSFS arrives at the main menu, wait a short time before loading an aircraft. This should then set the parameters to good values for your system, which will take affect the next time you run MSFS. John

So you updated the VC++ redisributables and still it won't validate? It validates just fine here. I will PM you a key file - please save this to your FSUIPC7 installation folder, then re-run the installer. This will then pre-populate the three registration fields (name, email, key) with the details from the key file - try validating them. If it fails validation, please check any anti-virus software that you are using. It has been reported that some anti-virus software quarantines/removes (or doesn't allow to run) the registrationChecker.exe program build into the installer. If none of that applies, and you have updated your VC++ redstributables, then I have no idea why it fails validation. If you run FSUIPC7 with that key file, does is run as a licensed/registered version (e.g. can you see the Assignments menu)? John

Also, better to change the following two ini parameters in the [General] section of your ini file and let auto-tuning do its thing (keep all other parameters as they are): John

Can you please download and update to the official release of 7.4.12 - you are using 7.4.12c, a beta version, which is no longer supported. Are you using 7.4.12c with the WASM for 7.4.12? This can maybe cause issues as they are compiled against different MSFS SDK versions and also different VC++ redistributables. So please update to the latest official release, try again and then show me the updated files. Also please activate debug logging for the WAPI (Log -> WAPI -> Debug). Also, please exit FSUIPC7 BEFORE attaching files. Your FSUIPC7.log shows that FSUIPC7 was still running (i.e. no closing statements) or had crashed... And those log files show completely different time stamps - I need to see the files from the same session, and the FSUIPC_WASM.log not the FSUIPC_WASM_prev.log, which is always the log file from the previous session. Your ini file also shows some issues with controllers, but you only have two assignments: and both of these are for a T.A320 Pilot controller which you no longer seem to be using: To clean things up a bit, delete those two button assignments, and remove all the joy letter assignments, i.e. your [JoyNames] section should just contain: New joyletters will then be assigned, starting from A, and you will have a clean ini ready for assignments. John

Lua auto scripts are not started until the list of lvars/hvars has been received fromthe WASM module via the WAPI, here: Is nothing logged after the '[INFO]: Connected to MSFS' message, even if/when you keep FSUIPC7 running? Can you test again, and if your lua's don't start, exit FSUIPC7 and then attach your FSUIPC7.log file as well as your FSUIPC_WASM.log file (see Advanced User guide, WASM section, if you do not know where this log file is). Maybe also attach your InstallFSUPC7.log file so that I can check the WASM was installed correctly. As you are a new user to this forum, your upload file limit will be very low - it will increase the more you post. Try compressing the files before attaching, but if still too large you can paste the contents instead (but please paste the whole file, not an extract). John.

I have corrected what I can - please download and try the attached ini file. There are still some issues that you need to sort out: 1. You have two profiles for the Skymaster: Do you really need different profiles for the same aircraft with different liveries? Take a look at those profiles and decide which one to keep, then delete all of the profile sections for the other profile. Then corrrect the aircraft in the profile section, i.e. either: or Or, if you want to keep the two different profiles, maybe it should be a different profile for the Cessna 337 to the Carenado, e.g.: ? It is up to you to decide, but it seems strange having the same aircraft with different liveries assigned to different profiles - different liveries should not affect the aircraft controls and so you don't need to use a different profile for a different livery. 2. Your general [Axis] section has the same axis assigned to multiple controllers/devices: You have aileron, elevator and throttle all assigned to device A (Saitek Pro Flight Yoke) and C (T.Flight Hotas X), and the throttle also assigned to D (Saitek Pro Flight Quadrant). Having the main flight axes assigned to multiple controllers can cause issues, as the axis position can be sent from both controllers, causing the axis to jump. Revise those assignments and remove the ones not needed - just assign one axis to each of the main flight axes (aileron, elevator, throttle, left brake, right brake, rudder, Mixture, PropPitch) to avoid problems. So, please revise the above, make the necessary changes to your ini file and try again., Any issues, please re-attach both your FSUIPC7.log and FSUIPC7.ini files and describe the issue. John FSUIPC7.ini

That is a completely different ini file from the one you originally posted! The ini file now shows that some of your device GUIDs have changed, and rather than fix this issue you have then re-assigned to the new joy letters: You are also NOT using substrings for your aircraft profiles - this can cause issues with the assignments not being loaded when using the same aircraft with a different livery. You should use substrings for your aircraft profile names. The aircraft you are using (Aircraft="Black Square TBM 850 N851TB") does not match any profile, so will be using your general profile sections, so for axes it is using the [Axes] section. You have no assignments to a throttle 2 axis in your general profile, just to the Throttle control and on multiple controllers (A,C, D and G) although only one of these exists (G - Saitek Pro Flight Quadrant). The Throttle control should control the throttle for all engines - is this not the case? Why do you think the throttle 2 axis is not working, when you are not assigning to this? I don't understand how your ini file got into such a mess, but I will try and correct it and post an updated version later today for you to try - don't have time just now. John

If using FSUIPC6, then you need the 64-bit driver, PFCcom64.dll. You should NOT have that in your FSUIPC6 installation folder. Where is that message from? The FSUIPC PFC drivers do not come with an installer - they are just dlls that you need to put into the same folder as the FSUIPC6.exe Just download and copy the PFCcom64.dll driver to your FSUIPC6 installation folder and remove any other 32-but drivers. Any further questions/issues, please attach your FSUIPC6.log file. John