John Dowson

No - profiles are selected automatically, you do not need to do anything. What are you actually doing - please explain. General button assignments also apply to an aircraft in a profile, unless overwritten. When you open button assignments panel the profile-specifiic check-box is not checked, When you press a button, if there is a profile-specific assignment, then that will be shown and the profile-specific box will be checked. If not, and there is a general assignment, the assignment will be shown but the profile-specific box remains un-checked, as it is a general assignment and not profile-specific. It works this way as all profiles inherit the general button assignments, unless overwritten, and the panel allows you to see both general and profile assignments, all those applicable to the current loaded aircraft. If you think there is an issue, set logging for Buttons & Keys, open the logging console and you can see what is happening when you press the button. Any issues, show me/attach your FSUIPC7.ini and FSUIPC7.log files (with the aforementioned logging enabled and showing your issue).

I am not sure why the group priority would affect this...I will check out the dev support forums (but a link would have been useful). How would I use that snippet to test this here? I really do not know - I will have to look into this further.... John

Ah, i see now - the installer detected and installed correctly, but FSUIPC7 checks things the other way around. FSUIPC7 does first check that location for the UserCfg.opt file, and so incorrectly determined that you were using an MSFS version and looked for the WASM under E:\MSFS\Packages\Community. Removing/renaming the YserCfh.opt file would have fixed this. I should really check the location in the same order as the installer to avoid such issues....I will update for this. Cheers, John

You have no axes assigned in your Fenix profile - where are these assigned? You also have no calibration section for your Fenix profile, so the general calibration section will be used. In this section, you have flaps calibrated which could be interfering. Create a calibration section for your Fenix profile and remove the flaps calibration: with the fenix loaded, open FSUIPC and go to the calibration tab and click the profile-specific checkbox, then go to page 6 of the calibaration tab and click Reset on the flaps. This will remove any interaction that FSUIPC has on your flaps. Not sure if this will help but worth trying before investigating further. John

It will be kept and included in the next official release, 7.4.7. No problem - cheers, John

No - you do not have to add this. The ipcReady.lua is always started if available, you do not add this to an [Auto] section. From the lua plugins document: Ok Ok

Maybe worth going back to your previous/last working ini and forgetting about the last one you attached, Use that, start FSUIPC7 and exit and then attach your files again, and I can look into any issues with those. Looks like we might need to remove some registry entries again - these look to be incorrect: Wrong GUIDs: N, x00, x04D8, xF30F, AGRONN B737 Yoke V2.2, -1, -1, 1, {NULL}, {F73B7EE0-4B37-11EE-8013-444553540000}, {NULL}, N, N N, x00, x044F, x0402, Joystick - HOTAS Warthog, -1, 2, 0, {NULL}, {F73ABB90-4B37-11EE-8003-444553540000}, {F73ABB90-4B37-11EE-8003-444553540000}, Y, Y N, x00, x0000, x0000, Fulcrum One Yoke, -1, 12, 0, {NULL}, {89A3AE10-D256-11EE-8002-444553540000}, {NULL}, N, N N, x00, x2356, x8046, Landing Gear Lever, -1, 5, 0, {NULL}, {F73B09B0-4B37-11EE-8008-444553540000}, {F73B09B0-4B37-11EE-8008-444553540000}, Y, Y Wrong GUIDs, multiple entries: N, x00, x16D0, x3530, Parking Brake, -1, 10, 1, {NULL}, {F73B09B0-4B37-11EE-8009-444553540000}, {F73B09B0-4B37-11EE-8009-444553540000}, Y, Y N, x00, x16D0, x3530, Parking Brake, -1, 12, 0, {NULL}, {89A3AE10-D256-11EE-8002-444553540000}, {NULL}, N, N ...etc No idea how your registry got into such a mess again. May be easier to remove everything and start again, but lets look at your files when using your previous working ini first... John

Should be fixed in the latest beta: FSUIPC7.exe

Sorry, but this makes no sense according to your current assignments in you latest ini: A=Cat3Design A320 FO Tiller V2 B=Cat3Design A320 FO Tiller V2 C=Joystick - HOTAS Warthog D=T-Pendular-Rudder E=VPC Panel #1 F=Landing Gear Lever G=throttleTek 3 H=LEFT VPC Stick MT-50CM2 J=Throttle - HOTAS Warthog K=Parking Brake M=<< MISSING JOYSTICK >> << MISSING JOYSTICK >> and these are now completely different from your previous working ini: A=AGRONN B737 Yoke V2.2 B=Joystick - HOTAS Warthog C=Cat3Design A320 FO Tiller V2 D=T-Pendular-Rudder E=VPC Panel #1 F=Fulcrum One Yoke G=T-Pendular-Rudder H=LEFT VPC Stick MT-50CM2 K=Cat3Design A320 FO Tiller V2 L=Throttle - HOTAS Warthog J=Landing Gear Lever M=throttleTek 3 FSUIPC does not change device letters, so you must have done this - why? And why are you specifying a 'preferred setup)? Once you have assigned a letter to a device, you should stick with that - so why is your "preferred setup" so different from the last ini you attached, but is the same as your last "working" ini? Are you manually editing the ini, or starting without an ini to generate a new one, then cutting and pasting?

Can you please attach your files - FSUIPC4.ini, FSUIPC4.log and the PFC.log or PFC,ini files. Also please see the provided PFC.dll User Guide and follow the steps there. I do not have nay PFC devices and do not use FSX, so you will need to trouble-shoot this yourself, but I can try and help... John

But how can you set thigs up in the cockpit if you do not have an aircraft loaded? You should not be trying to set anything for an aircraft when in the main menu... But then you need to open the fuel valve once the aircraft has been loaded, not when in the main menu - setting anything in an aircraft when in the main menu is not guaranteed to actually do anything.... The best way to initialise an aircraft on load would be to have a auto-started lua script, which will be started when the aircraft is initially loaded. You can also use ipcReady.lua for anything that applies to all aircraft, but for anything that is aircraft-specific you should have a specific script that is started from the the aircraft profile auto section. The WideServer component/thread in FSUIPC has always been started once an aircraft is loaded and ready-to-fly. Starting it earlier may not guarantee WideClient will work correctly, as this may also depend on other threads which are not stated until an aircraft is loaded. However, in the attached version I have added the ability to start the WideServer thread soon after the simconnect connection has been opened and the data requested, but I am not sure that this will work as you would like it. To use this feature, add StartEarly=Yes to the [WideServer] section of your FSUIPC7.ini file. John FSUIPC7.exe

Can you please attach your FSUIPC7.ini and FSUIPC7.log files.

This is strange as the installer first checks the steam location for the UserCfg.opt file in this location: %APPDAT%\Microsoft Flight Simulator\UserCfg.opt If this file exists, a Steam install is assumed, and if not then an MS Store installation is assumed. And your installation log shows that the following UserCfg.opt file was used: File D:\Users\Administrator\AppData\Roaming\Microsoft Flight Simulator\UserCfg.opt opened OK This IS for your Steam installation. Are you sure that you did not update the UserCfg.opt file from the MS Store installation, which would be here: %LOCALAPPDATA%\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt or possibly %LOCALAPPDATA%\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\UserCfg.opt

You are using an old and unsupported version of FSUIPC7, 7.4.1. Please update to the latest and only supported version, 7.4.6 and see if you get the same issue. If so, please re-attach your files. Please disable Log>Log Lua Separately and set Log->WAPI->Debug. and also attach your FSUIPC_WASM.log file. Google is not going to help you with FSUIPC errors... But are these errors actually causing any issues? I suspect that they are due to the fact that you are creating a lot of new lvars in succession and can safely be ignored. The line after these errors indicates that you have the lvars loaded successfully: If you want to remove the errors, you can add a small delay after you create each lvar (e.g. ipc.sleep(250)), to allow time for the updated lvar list to be passed back to FSUIPC, or create all the lvars in one calculator code statement instead: ipc.execCalcCode("0 (>L:DA62_Lt_Panel) 0 (>L:DA62_Lt_Flood) 0 (>L:DA62_Start_1) 0 (>L:DA62_Start_2) 0 (>L:DA62_Eng_1) 0 (>L:DA62_Eng_2) 0 (>L:DA62_Fuel_1) 0 (>L:DA62_Fuel_2) 0 (>L:DA62_AV) 0 (>L:DA62_Batt) 0 (>L:DA62_Alt1) 0 (>L:DA62_Alt2) 0 (>L:DA62_LPump) 0 (>L:DA62_RPump) 0 (>L:DA62_DI_Mode) 0 (>L:DA62_DI_Max) 0 (>L:DA62_DI_Alt)") John

Sorry, but this is still not clear... What is a "fake command"? You send "commands", also known as events or controls, via assignments to keys presses, buttons or axes, or using lua or by writing to offsets. All controls go via the SimConnect API. I have not used either, and am not sure what the 'npm fsuipc package' is...the WebSocket server will be the newer of the two, so maybe start with that... John

Way back in time. FSUIPC hacked into the sim to get the data for the offsets (before my time!), and was instrumental in developing the simconnect API. Once the the API was introduced, it was moved to use this, but also used some hacking for initial simconnect defects. From P3Dv4 and onwards, 95% of functionailiy has been via simconnect, abut some features still used other FS dll functionality, namely via the panels dll. For MSFS2020, everything comes via simconnect, or the embedded FSUIPC WASM module. These are all requested at sim_frame rate in FSUIPC How can things possibly work faster than the API allows? And there is always going to be a lag between setting and receiving the updated data - everything is asynchronous - you need to allow for this. Setting/updating are different channels than receiving. And the lg between the two depends on many things,,, Sorry, this is beyond me - what are "Token vars"? MSFS has various SDKs for different applications - take a look at those, FSUIPC is a 3rd-party simconnect application providing a uniform interface to multiple flight sims for 3rd party developers (amongst other things). We stopped hacking into the sim code after FSUIPC4, as this was a maintenance nightmare.... John

I am not sure what you are asking.... FSUIPC is a simconnect client, and is therefore restricted to the update frequency allowed by simconnect. Different data is requested indifferent frequencies - some in visual frame, some in sim frame, some in second, but always tagged (i.e. only received when changed). Most data is requested in sim frame (SIMCONNECT_PERIOD_SIM_FRAME), but also a lot in visual frame (SIMCONNECT_PERIOD_VISUAL_FRAME). If you let me know which offsets/simvars you are interested in. I can let you know the request frequency. But FSUIPC is a simconnect client, and has the same restrictions as all clients, And in MSFS2020, FSUIPC is an external client, not an embedded dll, so there is always going to be a lag in communication between an external app compared to an embedded dll. In summary, FSUIPC IS a simconnect client, and can only receive data via this interface. It does have an embedded/WASM component, but that is used only for lvar/hvar/calculator code. The data update rates are always going to be restricted by the provider, not the client. John

But did you change the script to remove the conflicting device? You cannot use the same script - it needs to be adjusted to the device that is giving the problem... I will look at your new files tomorrow or early next week and advise... John

Do you have an issue or question? Then why are you posting?

Not pedantic at all, more like a bug - I will look into this and update in the next release. looks like I'm trimming before removing comments, when it should be after... John

I have no knowledge on x-plane, but for smooth braking on a button in FSUIPC, regardless of version, see the following: John

This is way before my time, but I think that it is obvious that you cannot use a cfg file from 2004 in 2020.... Also changing from FSUIPC3 (FS2004) to FSUIPC7 (MSFS2020) is not an easy transition.. . That is basically 20 years apart, you cannot expect things to work the same way after so many years. I suggest you upgrade and just try things. There is a trial license for FSUIPC7 available in a post pinned to the top of this sub-forum if you would like to try it. John

Yes. and this issue has been known for a long time. There is already a thread on this in the Asobo forums...

When you get a lua error, the line number is given - just remember to check the previous line as well as the one given, as the error may be there (or even before!).

On line 14 (and 18) you have ipc.exit when it should be ipc.exit() It is a function and you are missing the brackets, so it is being interpreted as a variable, and thereofore an assignment is expected, hence the error (i,e, as its a variable, it needs to be followed by an '=' sign, but it is followed by 'else' instead).