John Dowson

Looks ok to me - this is what I see when I monitor sitting at EGLL, tuned-in to 348 (FAIROAKS NDB):

Note that there are also the following controls (available in FSUIPC4/5/6, not 7) for controlling traffic which may be of use: 1008 Traffic Density Set (param = 0–100 %) 1009 Traffic Density Toggle (param = 0–100 %) 1079 Traffic zapper

Presumably your ADF was tuned in to an NDB, no? They will be 0 if/when not tuned in. Which aircraft were you using - a stock one or an add-on? It surprises me that these are not available. I will take a look. Thanks for reporting, John

I am not sure what you mean by 'toggle ai traffic'. There is no control to turn ai traffic on or off, that is controlled by the P3D options - if thats the FS you are using. FSUIPC's traffic management (limiting) facilities and traffic zapper are controlled by the traffic management options - see the Traffic tab and the User guide (P15 in the FSUIPC6 user manual). There are currently no traffic management facilities in FSUIPC7 for MSFS, as the facilities to do this are not yet available in the MSFS SDK. John

Also, check that you don't have two [Axes.Mooney MR20] sections in your FSUIPC7.ini file for some reason....

This is very strange, and I am not sure how this is possible.... I have just tried with several different profiles and cannot repeat this. Next time you do this (i.e. add a profile-specific axis control), can you check if your existing axis assignments are visible. I can only assume that the original axis assignments weren't loaded for some reason. but as some of the assignments are preserved, this doesn't seem likely. If you keep your FSUIPC7.ini file open in an editor, it will get updated when you open the axis assignments panel - check the axis assignments are still there when you do this (you will need to reload the file), and then reload and check again once you have added the additional assignment. Can you also make sure that you are using the latest version, v7.2.10, and check that you have not installed FSUIPC in a windows protected folder, such as Program Files or Documents. If you have, please uninstall and re-install into a different location. Also, can you attach the full FSUIPC7.ini files next time, both before and after, so I can check the whole file. Thanks, John

The zones you have set are overlapping for the Flaps Set 4 & 5 controls. However, if using an axis for the flaps, why are you doing this via ranges? Just assign your axis to the FS control Axis Flap Set. No need to calibrate, unless the axis needs reversiong. John

FSUIPC7 is the version that works with MSFS2020. For the steps, that depends on what you want to do. Consult the provided documentation. There is also a trial license available in a sticky thread at the top of this forum, if you would like to try the registered facilities. John

First, you posted in the FAQ sub-forum, where it explicitly states NOT for support requests. I have moved your post for you. You also attached a continuation log, which is useless to us. I need to see the full log file. And also turn off all logging unless asked to activate. So there is no movement in the axis at all in the FSUIPC assignments dialog box? What do you mean by "jittering in the boxes"? Could you attach a full FSUIPC4.log file, and also your FSUIPC4.JoyScan.csv file please. John

Custom events are added to FSUIPC, not the WASM, by adding event files (with extension .evt) to the main FSUIPC installation folder. Some event files (for the MobiFlight WASM and FBW A320) are included in a sub-folder of your installation folder called EventFiles. If you want to use hvars, you need to make these know to the FSUIPC WASM by adding a hvar file (extension .hvar) to the WASM include folders. Some are also provided under a folder called HvarFiles. Not necessary if you are executing them via the ipc.execCalcCode function. Please see the FSUIPC7 Advanced User manual for details. Note that there is a currently a minor issue with some of the hvar files: The FSUIPC WASM will only recognise hvars if preceded by 'H:', however this is missing in some of the provided hvar files. This has been corrected in the latest version of the WASM, which is available in a topic is this forum somewhere and will be released shortly. @roarkr Sorry, seemed to have missed your post. Probably too late, but: No, a custom event is a K var, not a hvar. Try command = "(>K:A32NX.FCU_AP_1_PUSH)"; See https://hubhop.mobiflight.com/#/presetview/17d6a1e6-e019-4d8f-8932-05dfcc236d93/ John

It will be a false positive. Try disabling your anti-virus before downloading.

Error 740 indicates a permissions issue. You should run all your FSUIPC clients at the same permissions level as FSUIPC and the FS, which should really be basic, i.e. not elevated. I see your TeamSpeak is installed under Program Files, which is a windows protected folder and can cause issues with programs that do not conform to windows protocols (including FSUIPC!). Better to install such programs outside of Windows protected folders, as this can cause issues. John PS Very small font you have....difficult to read without expanding, maybe consider increasing your font size.....

Not sure what you mean by this.... Only the latest release of each FSUIPC version is supported. We request, for support purposes, that you always update to the latest version before requesting support. Updating only updates FSUIPC installed files, and does not in any way effect your configuration. Basically, if you have a running installation, the installer will just update what is required. I'm not sure if this answers your question, if not, please elaborate.... John

Both the missing dll and the application error are due to missing VC++ redistributables. You need to re-install the combined VC++ redistributables for 2015, 2017 & 2019. Please see the provided README.txt (in the zip file you downloaded), section Problems running FSUIPC7. John

This is not going to be possible, as the right alt key is recognised on my (and many) systems as lalt + lctrl. And on some keyboards its Alt Gr, which behaves similarly - at least on my keyboards. Strange. I think this is due to the shift (temporarily) cancelling the numlock, so the keys are seen as the Up, Down, etc keys in the windows message. So, I'll leave it as it is - with just the left/right shift and control keys being distinguished. John

Yes, very strange . In MSFS, a similar thing occurs, but with the shift + num8, for example, I get 'shift + num8 + Up'. Also, using the right Aly key gives 'alt + lctrl', which is also strange. And in MSFS, the right Alt key is recognised as 'Right Ctrl + Right Alt'! Not sure if I can do anything about these anomalies, as they also seem to affect MSFS, but I will look into it. I think I'll also distinguish between the left/right alt keys for button assignments to keystrokes, so I'll update for this before I release officially. John

If this is the case, there should be the following entry in the controls drop-down: FBW: L:A32NX_ECAM_ALL_Push_IsDown Set Are you sure its not there? Please check again... If not, please attach your FSUIPC7.ini, FSUIPC7.log and FBW.mcro files and I will take a look (but tomorrow now!). John

This is support for FSUIPC, nothing to do with Taxisigns HD, whatever that is. I have no idea. Please use the FSUIPC support forums for FSUIPC support only. Thanks, John

@ark1320 Could you try the attached version, v7.2.11a. This should distinguish between the left and right shift and control keys, for button assignments to key presses, not for FSUIPC key assignments. I may update for FSUIPC key assignments at some point, but this will be low priority I'm afraid. Existing assignments to the control or shift keys will only work using the left control/shify key when using this version. I haven't checked the lua keypress functions. event.key certainly cannot be used to distinguish between left/right keys. It should (hopefully) be possible to distinguish and send left/right ctrl/shift using ipc.keypress / ipc.keypressplus, but I haven't checked these yet. I will do this shortly. FYI, the additional flags used for this (P18 of Asvanced User manual) are: 512 - Right Control 1024 - Right Shift Please try this and report back: FSUIPC7.exe John

You are mistaken! I am not looking at this at the moment - I am still on Windows 10. It will be a while before I can update to windows 11, not sure when at the moment. As I said, the current requirements for FSUIPC7 (and MSFS as far as I know!) are windows 10. Windows 10 applications should be compatible with Windows 11, as long as the PC meets the Windows 11 requirements, as far as I'm aware. If this is not the case, it is really an issue for MS! I am not planning on updating my flight system to windows 11 for quite a while. I currently need to keep my development system on Windows 10, as that is still currently what most users are on. I still have a a windows 7 system which I need for certain activities (mainly key generation). I need to move these to windows 10, then update my windows 7 system to windows 10, then my windows 10 system to windows 11. It is going to take quite a while. For the time being, I will not be responding to any Windows 11 issues, except maybe just to re-instate that it is currently not supported. As I said, you need to be patient! John

This is support for FSUIPC7. I do not know anything about Fsradiopanel, but just googled it and it seems like its something that connects MSFS to android apps. Looks interesting. Latest version seems to be 4.5.1: https://fsradiopanel-demo.apps112.com/ - is that the one you are using? The Tambucho site does say: We have a fast and efficient customer service. So maybe try there support: http://www.tambucho.es/android/contac-form/ John

Esta funcionalidad se eliminó ya que FSUIPC7 es una aplicación separada ( no un dll) y no puede recibir información del mouse (desde Windows) mientras MSFS tiene el foco. También parece que todavía no es posible recibir estos eventos a través de SimConnect, por lo que, lamentablemente, aún no es posible restaurar esta funcionalidad. John

Hi Jim, Settings (and profiles) are never lost. When this occurs, it is usually due to one of three changes: 1. The aircraft you are using is not covered by the profile name. This occurs if you are using the full aircraft name rather than a relevant substring, so when the same aircraft but a different livery is loaded, the profile is not loaded. To get around this, you can attach the new aircraft to the existing profile, or, better, use substrings to identify which aircraft should use which profile. 2. The controller in question has been assigned a new ID. When this occurs, the current assignments to that device will not be recognised as FSUIPC detects it as a new device. To get around this problem, you should use the "JoyLettters" facility, which was designed to get around this issue. See the Uset guide for details. 3. Your device GUIDs have changed. This can occur, but usually on only windows upgrades. To get around this, you need to manually edit your FSUIPC .ini file, changing the GUIDs used to assign your devices. Is quite straightforward, but I can assist when this is needed. I suspect that you experienced issue 2, but I don't know without seeing your files. If you can attach both your FSUIPC .ini and .log files, I will take a look. Cheers, John

Updated - sorry for the delay. John

But that would be the same if not using WideFS. There is no difference between using RC directly with FSUIPC compared to using it with WideFS, which is what i thought was your question. Whether RC works with MSFS is a different question. If it relies on the SimConnect_Text API call (or the FSUIPC facilities that use these calls), then there will be issues. See John