John Dowson

Both ComWriteLoopTime and ComReadLoopTime should now have a default value of 10, so you shouldn't need to set these values in your ini file. Thanks for the update. John

This is a trial license - this is to be used to trial the registered facilities before purchasing. It is not for continual use. You have obviously tried this, and so you must decide whether to purchase or not, and not continually use the trial license. If everyone did this, I would have no sales and be out of business. And this is also why I leave a few days after the expiry of one license before I provide another. John

Your log file shows that you are using the aircraft 8563 Aircraft="Milviz 310R DIRFT" And this is using the following profile: General axis assignments are NOT inherited. They are copied to a profile when you create the profile (unless you decide not to do this). If you want to use these general axis assignments in existing profiles, you need to copy them to the axes profile sections. Only button and key assignments are inherited, not axes assignments. John

Please attach your FSUIPC7.ini and FSUIPC7.log files, not screenshots. And check if your lua file is running - if it was started from a profile-specific [Auto.xxx] section, you will also have to move that to be started in the general [Auto] section. Also, the lua you attached had extension .txt - it should be .lua. John

I have added ComWriteLoopTime as a new ini parameter in the attached version, and have set the default value of both ComReadLoopTime and ComWriteLoopTime to 10 (was 20). Could you please try this version first with the default values, and then maybe play around with different values to see what gives the best results. Thanks, John FSUIPC7.exe

Could you please try the following build: FSUIPC WASM Module 1.0.0 + WAPI 1.0.1 John P.S. If you have problems downloading by clicking the link, try right-click and save as. There can be issues as the link is on http not https, so you may have to accept or disregard any browser warnings.

Once a profile exists for an aircraft, you cannot change axis assignments back to general assignments. Either load an aircraft that does not have a profile assigned and duplicate your assignments (i.e. add again) to get it into the general assignments, or copy across the assignment from the profile specific axes section of your FSUIPC7.ini to the general axis section, making sure that the index number of the assignment line is unique. If you do this, make sure that FSUIPC7 is not running, or you have the axes assignment dialog window open and then click the Reload all assignments button once you have saved the updated ini file. John

John, not Peter. Did you also update your VC++ redistibutables? If not, please also do that. Download and install the latest combined 2015, 2017, 2019 & 2022 x86 and x64 packages from https://learn.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist and make sure that you install any of the individual packages already installed before installing. I really can't see anything in that.... Could you please attach log files, rather than pasting the contents. It looks like you are also using FSUIPC 5.156 - the latest and only supported version is 5.157 - can you please update. Can you also try removing each one of the wideclient applications running on the problem PC one at a time, to determine if it is one of those causing the issue. Maybe also try moving those clients to another client PC, to see if the issue occurs there. Are you still getting a crash or any error events in the windows event log on the client PC with the issues?

Did you try with a lower value, e.g. 5? Try with various values to see if any improve the response. Not at the moment.... I could add a similar parameter to control the write delay (ComWriteLoopTime) which is currently fixed at 20. You could then play around with both parameters to see which give a better response. John

I don't understand this - a line starting with '//' is assumed to be a comment and ignored, regardless of whether the line also contains a # character.... Can do, but what was the issue?

Only the latest version of FSUIPC is available and supported. What precious version were you using? A bug in FSUIPC or in your add-ons? What is the issue?

There are currently no controls provided by the SDK to control more than 4 engines.

Are you sure about this? The "Profile Specific?" checkbox is only checked and greyed-out in the Axis assignment dialog, not the Button assignment dialog. You can still add a general assignment to a button if using a profile, as long as there is not already a profile-specific assignment on that button. John

I was not saying the issue is not due to FSUIPC, but was questioning as to whether it is due to those console messages, as they were also present in previous versions of MSFS - although maybe they are now logged at an increased rate. As those messages related to the use of the "Modular Fuel System", have you tried with an aircraft that uses this system? I would suspect/hope that these messages wouldn't be logged in such an aircraft, and it would be interesting to know if there was also a frame-rate drop in such an aircraft. I'm also not sure what the Modular Fuel System is - is the the new 'modern component fuel system' as opposed to the legacy one? If you could log offset 0x07A8 (NEW FUEL SYSTEM) and maybe also 0x07A9 (NEW ELECTRICAL SYSTEM) using FSUIPC's Log->Offsets... facility (both as U8) and see what these hold when these micro-stutters occur, and if they only occur in aircraft that use or don't use these new systems. I also see there is a new MSFS release today - is this the SU12 release? If so, I can not longer test against the previous release to see what has changed, which is a shame...or is there still a beta available? It doesn't - it requests these variables once only, to be received at a specific frequency (either a 1hz, 6Hz, Frame or VisualFrame rate, depending on the variable). No errors are received when requested. It is MSFS that is then logging these errors at this rate for some reason - there is nothing received by MSFS that indicates that this is occurring. This is now getting confusing...some people say that its FSUIPC, others have said re-installing FSUIPC solved the issue, and now you say it is caused by the WASM.... Are you still getting those messages logged? What aircraft are you using? What version of FSUIPC are you using? What LvarUpdateFrequency are you using? If using the latest release, v7.3.17, could you try with the new feature that scans for lvars disabled, by setting the following parameter in your FSUIPC_WASM.ini file: LvarScanFrequency=0 John

Just checked the code and I have found a possible issue that could cause this - lvar and hvar CDAs are dropped when closing down, but I made change in the last beta to drop these once they have been processed, so the close function is trying to drop CDAs that have already been dropped. I will correct this and provide an update build here for you to test. John

No, not easily... FSUIPC is aircraft agnostic and requests all simvars once a simconnect connection is established, not once an aircraft is loaded. It would be a major change to only start requesting simvars once an aircraft is loaded, and to also determine what to request depending on systems used by the current loaded aircraft. The problem is that simconnect doesn't return any errors if you request an simvar that is not available/used by the currently loaded aircraft, and the only way yo know this is by those console messages. Anyway, as I said, this issue has been present since MSFS was released, and shouldn't be the cause of this current performance issue in the SU12 beta. Something else must gave changed... I will look into installing the beta later this week and report back once I have investigated this issue.

That will be a windows error code: ERROR_OPEN_FAILED 110 (0x6E) The system cannot open the device or file specified. As well as updating windows, make sure that you are running everything at the same privilege level. John

Thats the log from FSUIPC, and just shows that FSUIPC7 exited as MSFS was no longer available, presumably because it crashed. I need to see the WAPI log from your application. If you haven't set a name for the log file, then it should be called FSUIPC_WASMIF.log and be in the folder where you run the application, The FSUIPC_WASM_log file will be: You should also set debug level logging in both the WAPI (i.e. in your application) and in the WASM - using the FSUIPC_WASM.ini file (see Advanced User guide for details). John

Maybe @Paul Henty can recompile a new dll against the latest/released WAPID.dll to make sure there is no issue with that. I did make some minor changes between the beta and final release, although I would have thought that this shouldn't matter if the latest WAPID.dll is dynamically loaded, but Paul will know more about this than me.... John

This is not new - has been present since MSFS was released, and so is not related to the current issue. This problem has been reported to MSFS/Asobo already and still waiting a resolution. When such a simvar is requested, an error is reported, but for some reason such messages are logged at either 6Hz or frame/visual frame rate (depending on how FSUIPC requests the simvar). I really can't do anything about this, and it is up to Asobo to either return an appropriate error when such a simvar is requested, or to stop logging such messages. As FSUIPC is aircraft-agnostic, there is no way it can know what simvars to request depending on the aircraft loaded. Indeed, all simvars are currently requested even before an aircraft is selected.... John

Are you also using the WASM v1.0? Can you set debug level logging in both the WAPI and the WASM and show me the log files (both WASM and WAPI). Also make sure that the lvar updates are performed in the WASM, not the WAPI - i.e. set the LvarUpdateFrequency (n the WAPI) to 0, which should be the default. John

I am not using the SU12 beta yet - I will try and make some disk space and install this with the beta-switcher next week and take a look. Is this occurring with the registered or unregistered version of FSUIPC7, or both? Could you also maybe try without the FSUIPC7 WASM module, if using that - just (temporarily) remove it from your Community folder before starting MSFS. Would be useful to know if this is related to the WASM or not. Are you using any other SimConnect clients, and if so do they give the same issue? John

I'm sorry but I don't know, this is not my area of expertise - you need to ask the aircraft providers/developers. I would have thought that each aircraft provides its own my dynamics model (as each aircraft is different), but best direct your question to either the aircraft providers or the Asobo/MSFS and P3D forums. John

Yes, I have also seen this. I need to think about whether to use this or not.... Btw, I have just released FSUIPC7 v7.3.17 (as well as WASM/WAPI v1.0.0), which has support for > 10,000 lvars, as well as automatic scanning for new lvars (i.e. no need to issue a WASM reload command anymore). John

Thank you very much! Glad your issue is resolved. Regards, John