John Dowson

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

FSUIPC does not have any flight dynamics models - these are part of the sim and the aircraft models. John

By "extras" do you mean the components under Extras in the installer? If so, these don't actually do anything, unless you actually use them, so I can't see how they could have any affect om performance at all...

Thanks, but you don't need to do that - the license is per user and you can install on as many PCs as you like, for your own use. No - it will be either because you have not entered the key details correctly, or your VC++ redistributables are out-of-date. Please see the provided Installing and Registering FSUIPC7 document, section Invalid Key Problems. John

Could you please try with the following setting in the [General] section of your FSUIPC7.ini file: ComReadLoopTime=10 If you get the same issue, can you also try with a value of 5 and then maybe 2 and then 0... Let me know if any of those values make any difference. Thanks, John

Sorry, this one had moved off my radar...I will take another look and report back, although it will be difficult for me to investigate properly as I don't have any VRInsight devices.

Yes, but not at the same time!

FSUIPC7 only connects to MSFS. It is self-loading cargo that connects to FSUIPC7. And you (probably) don't need to use a registered version of FSUIPC7 to run 3rd-party clients, the free/unregistered version should be sufficient. As it says in the first comment on this topic where you downloaded the FSUIPC7.key file: What do you mean by this? If you got to the license registration page, where you pressed Skip. then FSUIC7 is already installed. If your issue is with self loading cargo, you need their support - I cannot and do not support 3rd-part programs, Otherwise, please clarify as to what your actual issue is - and please do not post again in this topic, as this is for requesting a trial license only. Please check/search the forum for the same issue and use that (if the answer isn't given!) or create a new appropriately titled topic. John John

To determine how to operate a switch, do the following: - first, see if there is a standard event/control that you can use. To do this, activate logging for Events (non-axis controls) and open the logging console window. Then flip the switch in the UI and see if any event is logged - if so, you can use that. - if there is no standard event/control,. list the lvars and see if anything looks appropriate. Then flip the switch and list the lvars again to see if the lvar you have identified changes value. If so, you can use that. I can't really help you any further as I don't have the 390 Premier IA. Well, if that assignment doesn't work when assigned to a switch, it won't work when sent when using an axis range. Note also that the range for the action you assigned is 0-0, You should really set a wider range for this (using the From and To buttons). Also please note that these questions have nothing to do with the title of this topic - 'PFChid64 Addon doesn't open in P3Dv4'. Please don't continually use the same topic for different issues. Create a new appropriately titled topic (also with the aircraft you are using) - you may then get assistance from others who own this aircraft. John

FSUIPC only does what you ask it to do.... If the speed is limited, this could be because the flaps or spoilers are deployed. Try activating logging for Events and Axes Controls, to see if you see anything logged that could be limiting the speed (i.e. do this with the logging console window open and see what is logged in real-time). You can also attach your FSUIPC6.log file here and I will take a look. Please exit FSUIPC/P3D before attaching you log, and it will probably be quite large and so need zipping/compressing. Also, attach your FSUIPC6.ini file. Not sure what this means...for many/most switches in the PMDG 737, you need to use custom controls - see Additional offsets (read-only) are also provided for the PMDG 737 (once activated) - see the provided documentation (Offset Mapping for PMDG 737NGX and 737NGXu). John

I have released this now - the beta release (available in the Announcements page) has been updated to include this change. I plan to make this the official release at the weekend. John

I have looked at his now as well and have updated so that the lvars-loaded callback will be called after the initial values have been received. The downside of this is that you wont get an lvar-update callback for the initial value. I haven't released this update yet though - I will do some further testing first.