John Dowson

That will be the microcontroller USB board that the kit is built on. Yes, arduino boards are used a lot for this type of thinks. Unfortunately I have no experience with such controllers. Your best bet is to look at the microcontroller board documentation - see https://docs.arduino.cc/hardware/leonardo. You could also try looking and/or asking about this on https://www.cockpitbuilders.com/. John

👍

If using FSUIPC, you should use FSUIPC's logging facilities, and also attach your FSUIPC7.log file, with appropriate logging enabled (in this case, for Buttons and Key presses + Events) so that I can see what is happening. I also need to see your FSUIPC7.ini file. Why are you double-pressing/clicking rather than just using a single click/button press? I have just taken a look and pressing the ALT button sends the following events (alternating): Ap Alt Hold - switch to Altitude Hold mode Ap Panel Vs On - switch back to VS and goes between ALT and VS (not clear). Sending the same events in a button press via FSUIPC also has the same affect. Therefore, you need to overload the assignments on your button to use both controls, and add an offset condition to send the correct control depending upon the current ALT mode, which is held in offset 0x07D0. John

I am sorry but I cannot support hardware devices that I do not know - you really need support from the manufacturer. You do not even mention the manufacturer, name or model! If it is detected by windows as a keyboard type device, then you should be able to assign the "keys" in the FSUIPC key assignments panel. However, if doing this then it may/probably will only receive the input when FSUIPC7 has the focus, and not when MSFS has the focus. This is because MSFS does not recognise it as a keyboard input device, and so doesn't forward the "key strokes" to FSUIPC7 when it has the focus. Is there some configuration software and/or driver that this device is using to convert the button presses to key strokes? If so, maybe not run or uninstall the drivers, and see if it recognised as a HID joystick type device without this driver or software. If that is the case, then you can assign in the usual way. If it is recognised as a non joystick type device, it may be possible to assign using lua. You could maybe look into using the example HidDemo.lua script provided (in the lua examples zip file in your FSUIPC7 Documents folder), but I would first check with support for that device. John

Most of the controls for these are using lvars, hvars or calculator code. You can use MobiFlight events with FSUIPC if you like, but you do not need to. If you want to use the MobiFlight WASM module, event files for MobiFlight are provided in the EventFiles sub-folder of your FSUIPC7 installation. To use these, you need to move them to the main FSUIPC7 installation folder (i.e. up one level). There are event files for the G1000, the GNS530 and the KAP140. Alternatively, you can just use the lvars/hvars/calculator code theat the MobiFlight events use directly. There are various methods of doing this, all described in the user manuals and in various posts, but the general technique is the same. Take a look at the MobiFlight hubhop site (https://hubhop.mobiflight.com/) to see what a MobiFlight event uses, and depending on what that is you can either assign to a control, an lvar or hvar (using lvars-to-offsets functionality, macros or lua) or using calculator code (only available via lua at the moment). No, they are distinct. Simconnect events are also known as K events. Simvars are also known as A vars in gauge /calculator code. Usually its one or the other, maybe a combination of both, or possibly using other variable types (hvars, bvars, etc) or complex calculator code. Take a look at the code for the presets in that MobiFlight hubhop site. But really you need to look at the Asobo documentation and web resources for a full understanding if all the variable types and what they are used for. John

Different aircraft can use different controls - you need to see which controls work for each particular aircraft and use that control. To see what an aircraft uses for a particular control/action, activate appropriate logging in FSUIPC, open the logging console and activate the control in the UI. You will then (hopefully) see what control the aircraft is using, and then can assign to that. But your question is too general. If you let me know a specific aircraft and function (axis/button) that you wish to assign, let me know and I can take a look. There is no way I can provide any information on assignments without knowing which aircraft you are using. Also, if assigning in FSUIPC, best to start with an empty profile for your controller/device in MSFS. And your general [Axis] section in your FSUIPC7 has some strange entries: 0=AY,256,F,65694,65695,65696,0 -{ TO SIM: ELEVATOR_SET, AILERON_SET, RUDDER_SET }- Do you really want yout elevator, aileron and rudder all activating on one axis? I would delete this line. 3=AV,256,F,1,0,0,0 -{ TO SIM: Custom control: <1> }- Not sure what this is - I would remove this. Maybe many aircraft don't "work" as you don't have your main axes set-ip in your general [Axis] section, and your profile aircraft names are full names and not substrings, so will not catch all variants. So, i would recommend: - removing those entries mentioned above from your FSUIPC7.ini file - assign all your main axes for the general axis profile (i.e. no profile) - update your profiles to use substrings. To do this, change: to And to It is a good idea to manually adjust the aircraft names used in profiles to use substrings to catch all variants. John

Ok. Note that there is also an FSUIPC Pause Control (1152)which can also be used to achieve this, in overloaded assignments or compound macros, if/when needed. John

The easiest way to do this is to use the Adding Lvars to Offsets functionality, which may be easier to understand. A full example is given on how to do this in the Advanced User guide, P43. Can you please read the whole section on using the FSUIPC WASM module to get a basic understanding on how to use lvars/hvars, then just try it out. There are also many support requests where I have explained things in more detail, so please check previous support cases if you have any issues, e.g. It is the index number for internal reference. If using mactos, then assign to that macro - it will be listed as: YourMacroFilename: L:A32NX_OVHD_APU_MASTER_SW_PB_IS_ON Toggle I just don't have time for this, but there is already an abundance of information on using FSUIPC macros - they have been around for many many years. If you find using macros complicated, just use the lvars-to-offfsets functionality instead. The example given in the Advanced user guide should be easy enough to follow. Just make sure that the offset control used matches the type of the value you are storing, don't overlap offsets, and make sure that they are boundary aligned (all explained in the Advanced User Guide). John

As far as I am aware, hvars have no associated value and are basically JS / HTML events, and should probably be called H:Events (I have seen this term also used). The FSUIPC WASM just uses the H:varName to execute the calculator code: (>H:varName) I have seen examples where an actual value has been set. However, I don't thing this is an associated value to the hvar, but more like a parameter to an event. There is no way that I know of to actually read the value of a hvar. If needed, I could allow a parameter to set on a hvar, but up to now I have not seen a need and no one has requested such a feature. This can currently be achieved by using the ipc.execCalcCode(“code”) function, if needed. Thats strange - I can only assume that you made the call too soon. Hvars won't be available until a number of seconds AFTER the aircraft has loaded, defined by the LvarScanDelay parameter, which has a default value of 5. However, I recommend increasing this to around 45 if using complex aircraft, such as the FBW A320. If you check your FSUIPC7.log, you should see when the lvars/hvars are available and if you made the request too soon. I can think of no other cause of such behaviour. No problem.

Not sure why you are getting that value, but I found an issue which is corrected in the attached version (still not tested though!)FSUIPC7.exe:

Hmm, strange. I presume that hvar exists....I will take a look - tomorrow now.

They are not lvars. You have created macros that send the control '2999'. Did you read the manual? This is the relevant section: Why do you think that would work? PLEASE read the documentation. To toggle (i.e. change from 1->0 or 0->1), ytu: 1=L:A32NX_OVHD_APU_MASTER_SW_PB_IS_ON=Toggle I don't know where you are seeing this. You are confusing offsets with controls. If you want to add the lvar to an offset, then that is a different way to access lvars which is also explained, with an example, in the Advanced User guide. John

I have added those additional controls in the attached beta version, v7.2.15a, if you would like to try: FSUIPC7.exe John

Hi Andrew, please try the attached version, v7.2.15a: FSUIPC7.exe

Sure, I will add that as well. John

That should be fine - as long as your PC meets the minimum requirements. I, and many others, are runnning MSFS with FSUIPC7 on windows 11 without issues. Note, however, that if running on Windows 11 you may need to add the following to the [General] section of you ini file: DisableMSFSMonitor=Enum This is needed if FSUIPC7 closes because it thinks MSFS has stopped running (cannot be detected) although it still is. Could you please provide more details on what you have actually done...when I give you several things to try, you need to be explicit in your response so that I know what you have actually done - did you run the first reg file again? Did you run the second reg file? Maybe we should take this one step at a time... Disconnect your X56 and your rudder pedals. Run both registry scripts (or combine them into one script and run that). Reboot. Rename or delete your FSUIPC7.ini - you will lose your assignments but you do not have that many, and they are duplicated, you can redo them once we have your devices recognised correctly. Then run FSUIPC7 - still with your X56 and rudder devices disconnected. This should just leave your Logitech G13 Joystick connected. Lets see if it recognises that as a single device. Then PLEASE exit FSUIPC7 - as I said, I need to see these files AFTER FSUIPC7 has exited- you keep attaching them when FSUIPC7 is still running (unless it has crashed...). That should tell us if we also need to clean the registry of your Logitech G13 joystick. Also, if you have installed Logitech drivers (or software) for that joystick, best to remove them and let windows install the default drivers, as you did with the Saitek devices.

You thought I would say what - that a) I pointed this dual assignment out to you? I did. Please re-read the comments. b) your Hotas has no V axis? If that is the case, how could an assignment to this "non-existent" axis cause you any issues, and why is your device reporting this as a valid axis? c) you must have manually assigned at some point? Well, I guess that is not 100% accurate. It can only be there if 1. It was assigned via the FSUIPC assignment dialogs 2. It was manually added by editing the file 3. Some other mysterious software added this for you (highly unlikely, but I do know of some utilities that try to do this for you) No point discussing this any further. Topic locked. John

Hi Greg, thanks for the update, glad its all working as expected. John

Hi Andrew. I will add an ipc.getHvarName(id) function. This should have been added when I added the ipc.activateHvar(“name”) function but seems to have been missed. I can post a version here for you to test if you like - may take me a day or two. John

I don't think it is available in the stable version. Read that link you posted: John

The Modules folder was the installation folder for all versions of FSUIPC prior to FSUIPC6. For FSUIPC6 and FSUIPC7, the Modules folder is now just the FSUIPC6/7 installation folder, i.e. where you selected to install FSUIPC7. If you do not know where that is, use the File -> Open Installation Folder... menu item. That is where your lua files go. Note also that you can now also run FSUIPC7 on a client PC. Not sure if that is useful to you or not, but details on how to do this can be found here: John

Thanks for the input Al. John

Good, as I have no idea! Glad its all working now, John

If its not listed, it doesn't exist, or didn't exists the last time that the scan for lvars was performed (done initial after aircraft load and whenever a reload command is issued. Why do you think this lvar exists? Presume that you are using the FBW A32NX. Which version (stable or development) are you using, and is it up to date? If you let me know I can check to see if I can see that lvar. John

Please always exit FSUIPC7 before attaching files as it helps to see the full files after FSUIPC7 has closed down, not when still running. Seems to be an issue with your rudder pedals now. Disconnect them, run the below again as a .reg script, reboot then reconnect: I don't know if you noticed, but I also corrected the first .reg file contents I posted an hour or two after the initial post (due to a typo). If you ran than before my update, please also run that again (with devices disconnected). If you still get an issue after that, disconnect those three devices and re-run those scripts and reboot. DONT reconnect your devices, just run FSUIPC7 then exit, and show me the FSUIPC7.Joyscan.csv file, as this will then show what is in your registry with those devices removed and disconnected. They shouldn't appear at all, but if they do there may be some other registry entries that need removing that I am unaware if. John