John Dowson

Remove assignments (or, better, create a new empty profile for your devices in MSFS). For your keyboatd, you should use the defualt keyboard assignment in MSFS, unless assigning your keys in FSUIPC, in which case check that you have no duplicated assignments. Otherwise, activate Axes logging in FSUIPC, load an aircraft and move your throttle showing youe issue, then close down and show me your FSUIPC.log and FSUIPC.ini files.

Please do so, but with the latest version, v6.1.1, released earlier today.

Yes, but I don't know why your EXE.xml is not working. Does FSUIPC7 actually run - have you tried running it manually? I have also just released v7.1.0, so you should download and update.

Are you sating that having FSUIPC installed (and running, presumably) when P3D runs, this gives you problems with P3D recognising your keyboards, as wel las other strange issues, but uninstalling FSUIPC6 and this issue goes away? Could you also show me your FSUIPC6.ini and .log files (from your configuration where things hang or you have issues). Can you also check your windows event viewer, to see if there are any crash (or other strange) events logged there at the time this occurred, and if so, please show them to me. As I said, FSUIPC does nothing special with keyboards, and only receives the key presses/release via standard windows messages. Does everything work ok for you, in FSUIPC and P3D, when using just one keyboard? Cheers, John

No need to. Your installation log looks fine, as does your EXE.xml. Ah, then maybe you are now using an early version of MSFS that does not have this facility (EXE.xml) yet enabled. What version are you using? Will you be updating to the latest version? If that is the case, and you are not updating (or if it still doesn't auto-start via the EXE.xml), you could re-activate the older method of doing this, via the desktop link. To do this, open the desktop link MSFS.lnk in an editor and fine these lines (should be from line 32): Remove those two double colons (highlighted) before the timeout... and start... commands and save.

The FSUIPC WASM and support for lvars/hvars has now been released as FSUIPC7 v7.1.0. This topic is now closed. For any further issues, please raise a new topic (or use an existing appropriate topic). Thanks. John

The implementation of the support for up to 128 buttons is now complete, and has been released as FSUIPC7 v7.1.0. This topic is now closed.

The implementation for up to 128 buttons has now been completed with the release of FSUIPC6 v6.1.1. This topic is now closed.

Sorry, but no time today as I need to release both FSUIPC6 and FSUIPC7. I will look into the traffic information provided tomorrow...

All keyboard handling in FSUIPC is received through windows, and FSUIPC can't distinguish between multiple keyboards, it just acts in the key presses received from windows, whatever they are and whichever keyboard they come from. You can use multiple keyboards with windows, but if you do you may have issues if the keyboards have different keyboard layouts. There are things you can try - you have probably seen these already, but google shows this that may be of use (if not already tried): https://www.codeproject.com/Articles/20994/Using-multiple-keyboards-with-different-layouts-on This seems to allow switching keyboard layouts automatically when a key is pressed on a keyboard. However, I'm not sure how this would wotk with FSUIPC, but may be worth a try. Otherwise, you could try switching keyboard layouts manually when switching keyboards, using the windows facilities (win + space keys, or Alt + (left)shift) to switch keyboard layouts to the keyboard you are using. As for P3D not recognising your keyboards and your windows issues, I have no idea, sorry. I don't understand what you mean when you say 'but the axes and buttons configurations in FSUIPC are corrupted' either, as the keyboard should not have anything to do with any of your other controllers. It does sound like you have some windows issues, that may be better solved by a repair or re-install. John

The log you attached shows the slope adjustment working as expected, so I don't understand your issue.. Is it working correctly for you now or are you experiencing the same issue?

The icon displays a splash screen and loads MSFS. MSFS should start FSUIPC7. Of it doesn't, there was possibly an issue updating your EXE.xml file during the installation process. Please check or post you install log. The usual solution is to delete/rename you current EXE.xml and re-install FSUIPC.

Check the file has the correct extension (.mcro). It will appear, near the top of the menu, listed as 'A320: L:A320_Neo_MFD_NAV_MODE Set'. If its not, the files in the wrong place ir has the wrong extension (or content). But does FSUIPC see your arduino board switches? If not, this wont work. If FSUIPC doesn't recognise your device as a HID joystick type device, you cannot assign directly using the UI. If its recognised as another HID type device, you could try the lua com library, but that is quite advanced. If thats the case, you maybe better off trying MobiFlight.

Thats enough for it to be recognised by FSUIPC. If you enabled lua plugin logging and didn't see anything, then it didn't run. Have you tried to assign in fsuipc, to a button or key press? If not, try that. I'm sure it will work. And as I said before, try logging the offset. Of course, you need a registered version of fsuipc to run lua scripts.

I think you are confusing things a bit. As I said, the FBW events just activate hvars or set lvar values. You can do the same with the lvar/hvar facilities provided by the WAPI .lib and .dll, and in c# using Paul's MSFSVariableServices class. If you really want to use the FBW events, you have to add them to FSUIPC using event files, as I indicated earlier. And to then use them, you need to use the control numbers assigned, which I also explained earlier. To start with, rather than using the FBW events, why don't you just look at the available lvars/hvars and see if you achieve the same via lvars/hvars. Looking at the FCU, the following hvars should be available for you to try: and the following lvars are related: Note that hvars are only available if you add them to your A320.hvar file, located in the FSUIPC WASM modules folder. From what I can see, only the first two (H:A320_Neo_FCU_MODE_MANAGED_SPEED & H:A320_Neo_EXPEDITE_MODE) are currently included in the provided A320.hvar file. To use the others, you will need to add them to that file . Once added to the file, you need to reload (function available from Add-ons->WASM-Reload menu option) or restart MSFS (or reload the aircraft).

I don't delete topics, unless raised by mistake. This may help others who have the same issue. Glad its now working for you. John

Did you try clicking Yes/ Oui to allow FSUIPC to run? If not, try that. It should then be ok. If you still have difficulties, please see If you have re-installed, make sure you have installed both service packs, SP1 and SP2.

If the executable is gone, then that sounds like some sort of anti-virus software that's doing this. Try disabling ort adding an exception to the anti-virus software you are using. Also, for installation issues, please consult the provided README.txt and Installation and Registration guide. If the installer is crashing/not working, if not anti-virus software, it is usually caused by missing or invalid VC++ redistributables. This is explained in the README.txt.

Yes, maybe he has a better way of doing this... I'm not sure about that...he wants to reduce support and spend more time on his cockpit and actually flying. It would be interesting to look into, but there's no chance I'll have time for this in the next 6 months or so at least - to much to do on FSUIPC7 (and FSUIPC6) for the time being, sorry... Maybe @spokes2112will take a look - he likes a lua challenge and has helped out many users before with useful lua scripts... You could try to look into why this doesn't work any more....

Ah, you are using MobiFlight....! You didn't mention this. I cannot support MobiFlight, you need their support (or Discord channel). However, that log extract is an IPC write log, which is showing the MF is writing to that offset area, which is the offset area for macro (and lua) requests. So that seems correct. Try logging offset 0x66C0 using the FSUIPC offset logging facility. You will probably see that that offset is also changing. IPC write log will only log the changes to offsets via IPC calls, not from macro or lua scripts, which are internal. You need to use FSUIPC's offset logging facility to see those.

Well, I thought that was what I was doing...giving you basic instructions. To create a file, right-click in the folder where you want the file created (in Windows Explorer), and select New-> Text Document. Then right click the file and select Rename, and give it the name A320.mcro. Then open that file in an editor (e.g. Notepad++), and add the text I specified and save it. It really isn't that difficult. Once you have done that, if you restart FSUIPC7, you will see the macro/lvar name in the assignments drop-down menu.

For MSFS (2020, not FSX), you need FSUIPC7. Please do not use 'FSX' when talking about MSFS, it is confusing (FSUIPC4 supports FSX). If you need/use WideFS, WideFS7 is compatible with FSUIPC7 (as with FSUIPC4-6), so if you already have that no need to purchase again. Note that you don't need WideFS7 unless you are using a 2nd PC to run FSUIPC clients (or additional devices). I will also update the title of your post to clarify it is for MSFS.

Well, using either 0x66C0 or "66C0" should work. This is a free user offset used by many folks (including me) for years without issue, so something else must be happening... Please activate logging for lua plugins, as well as offset logging for 0x66C0, and generate a log file running the lua, and show me that as well as your lua script.

No. Currently no access to weather information in MSFS using FSUIPC7.

Hi Ray, FSUIPC only holds the details of the nearest 96 AI aircraft. For ground traffic, you could monitor the additional AI ground aircraft data at offset D040, matching on the departure ICAO to your landing ICAO, and then check/match the runway (and/or maybe the runway designator?). For the state, you would need to read from E080. Any matches, you could then kill (via offset 2900). You could do this in lua. Interesting project.... There is also the 'Detecting runways in use' facility, at offset D000, but I don't think that provides AI details for you to kill. Pete may have other suggestions... Cheers, John