John Dowson

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

Really? Where is this file created, and how? This is news to me, so can you let me know how you generate that file (or if its automatic) and where it is located. O have never heard of such a file. If you are doing this from code (C/C++), can you just not use the WAPI interface, the following functions: void getLvarList(unordered_map<int, string >& returnMap); // Returns a list of lvar names keyed on the lvar id void getHvarList(unordered_map<int, string >& returnMap); // Returns a list of hvar names keyed on the lvar id void getLvarList(unordered_map<int, string >& returnMap); // Returns a list of lvar names keyed on the lvar id void getHvarList(unordered_map<int, string >& returnMap); // Returns a list of hvar names keyed on the hvar id Alternatively, Hvars are loaded from a .hvar file anyway, so for hvars can you not just use the same file? For lvars, I guess I could add a lua function to list them to a file (also for hvars I guess) if really needed. John

Yes, I did point this out to you: It is not a good idea using two distinct axes for the same control as they will not be syncronised and can send conflicting values. I suggest you delete one of those assignments. And your spoiler calibration looks strange, with a very large null zone: Spoilers=-11903,-7168,-512,12223/24 I suggest you re-calibrate your spoiler axis, once you have decided which axis to use. Yes it does: It is only there because you must have assigned this at some point. There is no way that it can be there otherwise. John

Of course I need to see that. You stated that your issue is that FSUIPC does not recognise your yoke. How can it recognise it if its not connected? The new log and ini files you posted shows the Alpha was recognised, now it is connected: And you have your ailerons assigned to the X axis: and that you have also set a very large slope on the this axis (in the calibration tab): Such a large slope will give very little movement unless you move the axis to its extremes (check the slope curve in the calibration tab). So, if your ailerons are working but only when moving the axis to its extremes, remove that slope. If the ailerons are not moving at all, try switching to a different aileron control such as Aileron Set, or, better still, switch to using 'Send direct to FSUIPC Calibration' (rather than 'Send to FS as normal axis' and use the Aileron or Aileron/SlewSide control, and then make sure you calibrate that axis in the FSUIPC calibration tab. John

Happy New Year. Sounds very strange.... First, try reinstalling FSUIPC. If you get the same issue, take a look add both of your add-on.cfg files. One is in C:\ProgramData\Lockheed_Martin\Prepar3Dv5 and the other is in C:\Users\[your_name]\AppData\Roaming\Lockheed_Martin\Prepar3Dv5. The FSUIPC entry should be in the latter - is this where it shows Active=true? If that is the case, you should not have to reactivate. You could also try tr-installing the P3D client. If you still get issues after this, can you show me your add-ons.cfg file from your AppData\Roaming\Lockheed_Martin\Prepar3Dv5 folder. John

No it hasn't - the current license is valid until the 28th January:

Then either - you placed the key file in thr wrong folder - the file does not have the correct name - it should be called FSUIPC7.key - check this as explorer sometimes hides extensions of known file types. If the key file is in the correct location, then you will see the registration details in the installer registration screen. But just skip - validation will not work. However, the usual way is to install fsuipc7 and skip registration, then drop the key file into the installation folder. You cannot drop the key file into this folder before you have installed, unless you are re-installing.... It really isn't that complicated....