John Dowson

Are they still there? Better to keep your own hvar files in the other location. You don't need to do this as No is the default value. Understandable as doing this doesn't change anything. Don't restart MSFS - try restarting FSUIPC7. Before you do this, please check for that line in the FSUIPC7.log file as indicated in my previous post. To see details on the loading of hvar files, set Debug level logging in the FSUIPC_WASM.ini file and take a look at your FSUIPC_WASM.log file. You could also consider switching from using hvar files to presets. You can activate hvars via presets without making the hvars known to FSUIPC7. To activate a hvar via a preset, create a file called myevents.txt, and in it add lines of the form presetName#>(H:hvarName) You can then assign to the presetName in the drop-down as 'Preset: presetName''. John

Which folder is your hvar file under, and is it still there? It takes values Yes and No (default) and goes in the FSUIPC_WASM.ini file, preferably in this file located in your WASM persistent storage area, not in the one under your Community\fsuipc-lvar-module folder. if you don't know what this means, please see the Advanced User guide. However, it does look like i forgot to add this new ini parameter to the manual - i will do this for the next update. How are you starting FSUIPC7 - manually or via auto-start? I have noticed that since the latest MSFS update, FSUIPC7 is sometimes/occasionally not starting everything that is needed. This seems to occur occasionally when auto-started, and when manually starting FSUIPC7 when MSFS is in the main menu. I am currently looking into this. This occurs if/when the following message is not reported (in your FSUIPC7.log file) by the time you are ready to fly: -------------------- Starting everything now ---------------------- If this is the case, you could try restarting FSUIPC7 once you are ready to fly and things should be ok. If that is not your issue, please attach your FSUIPC7.log and FSUIPC_WASM.log files and tell me the name and location of your hvar file. Note the name should probably change if you set UseAirLocForHvars to Yes, so best not to set this for the time being. John

@Gianni4 I'm not sure if thus is of interest (or if you solved your issue), but for the latest FSUIPC7 beta I have added a facility to allow FSUIPC7 to use a global keyboard hook to receive keyboard input rather than getting it from the FS via SimConnect. This may (hopefully) detect the key presses sent from your controller. This version is currently available in the following post: John

Ok. Then try activating logging for events, and then move the Fuel-Control-Switch to its various positions to see if any events are logged. If they are, try assigning to them. Also, maybe take a look at the MF preset list (https://hubhop.mobiflight.com/) to see if there are any presets available for the SWS Kodiak. There are different control numbers as they are different controls: 66292 AXIS_MIXTURE_SET 65773 MIXTURE_SET See the auto-generated document 'Controls List for MSFS Build 999.txt' in your FSUIPC7 documents folder for a list of MSFS provided controls. The difference between these is the range - MIXTURE_SET uses 0 to +16383 whereas AXIS_MIXTURE_SET uses -16383 to +16383 But you probably shouldn't be using the axis mixture controls if the mixture control is not an axis in the aircraft itself... And I don't understand why you want to map a button to Mixture Set - for buttons you would normally use the rich/lean (and inc/dec) controls - as you seem to be doing... I also don't have the SWS Kodiak 100, so cannot really advise on how to configure FSUIPC for this aircraft. This post on the Asobo forums may help - it refers to the Bravo but should be nearly the same for other controllers: https://forums.flightsimulator.com/t/kodiak-100-mixture-lever-on-honeycomb-bravo-with-fsuipc/506489 John

Hi Detlef/ @dedel, could you try the attached FSUIPC7.exe, v7.3.3b. You can use a global keyboard hook for keyboard input (instead of receiving keyboard input via SimConnect) by adding the following to the [General] section of your GSUIPC7.ini file: UseKeyboardHook=Yes The hook is set when you leave the MSFS main menu, and removed when you go back to the main menu. Let me know if this enables FSUIPC7 to see the key presses from your button box. John FSUIPC7.exe

No problem. John

Ok, that is interesting... I don't understand how this can cause your issue though, as requests to update lvars from a client are ignored if the WASM is configured to update itself. I may look into this further when time permits to find out exactly what is happening in this configuration. Thanks for reporting back, and I am happy that you have now found the solution and cause. John

What aircraft are you using? Many controls are specific to the aircraft being used - you should always specify the aircraft if you cannot determine what to use to control a function. Have you tried logging axis controls (and possibly events) to see what is logged when you move the mixture lever in the aircraft in question?

Your post doesn't make sense....Have you upgraded from FSX to MSFS2020? But it doesn't matter... each version of FUIPC requires its own key. A key for FSUIPC4 will not work with any other version. If you are using FSX, you need FSUIPC4. If you are now using MSFS (i.e. MSFS2020), then you need a key for FSUIPC7. There is no expiry date on keys, but each version of FSUIPC (i.e. FSUIPC3, FSUIPC4, FSUIPC5, FSUIPC6, FSUIPC7) requires its own key, and a key for one version is not valid for any other. John

That is because the FBW is still in your Community folder. Yes, this is normal. You don't need to uninstall, just move out of your Community folder if not using. As I said, take a look at the MSFS Add-On Manager. There is no change between v7.2 and v7/3 as far as lvar discovery is concerned. It is the WASM module that provides the lvars, and this has only had minor updates. You would have seen exactly the same lvars using v7.2 as the latest version. FSUIPC just provides the lvars that are available - it does not know which aircraft has created (or is associated to) an lvar, it just reports the lvars it finds. And lvars associated to other aircraft not currently loaded have been returned since access to lvars has been available. You need to raise a bug report with Asobo/MSFS if you want to get this corrected - I suspect this has been reported a number of times already (I reported this nearly a year ago). As I said previously, the only way I know of to reduce the number of lvars is by removing anything you are not going to use from your Community folder before you start MSFS. And none of this is related to the topic of this post, which has been resolved. I am therefore closing this topic now. John

If you read that post, the OP installed FSUIPC6 on a different location to his previous FSUIPC5 installation and didn't copy across the required files. This is NOT the recommended location. That us the location where the add-on.xml must go. I recommend installing FSUIPC6 in an unrelated non-windows protected folder. Installing under the Documents folder can give strange issues (especially when using cloud back-up solutions such as OneDrive). I suggest you re-install to a different location. It was the default location (but certainly not recommended if you had read the installation guide) on earlier releases of FSUIPC6. No, sorry - that was for FSUIPC5. Many folks continue to use this for FSUIPC6 if upgrading from FSUIPC5. Nor do I. The uninstall log shows what files have been removed, and macro/lua/ini files are certainly not deleted by the installer. Try re-installing under a non-windows protected folder anyway. You macro files (as well as your FSUIPC6.ini file and any luas and other dlls that you may use) should still be there afterwards for you to move to the new installation location. I would also be interested to know if they are removed again if you do this... John

What version of the A32NX are you using? They won't work for the Asobo A320, and the one you have assigned to in the pic you attached is for the FBW A320 dev version only. For the stable, you need to use A320_Neo_FCU_ALT_PULL (i.e. 'Preset: A320 Neo FCU ALT PULL'). Please see (and use) https://hubhop.mobiflight.com/ to determine what presets are available for each aircraft. And please always state which aircraft (including vendor and version, when applicable) you are using if you need help. Also, no parameters are needed/required if using the MF presets. John

You can also try setting the lvar via the executeCalculator Code function rather than the setLvar functions. I'm not sure this will work - it may (should?) give the same error, but worth a try. To use this function, build a string of the form: "value (>L:lvarName)" substituting value and lvarName with the correct values. I would still like to see the WASM/WAPI logs if you could provide them. Depending upon what they say, I could write a small WAPI test application to see if I can duplicate this error, using the WAPI directly rather than Paul's C# wrapper. John

No - I think the default config is to update in the WASM at 6Hz. It is generally better to use that and set the WAPI ini parameter to 0. You should only let a WAPI client define the update frequency if you want a frequency not available in the WASM module. You also need to take care if using multiple WAPI clients as then you should only allow one to set the update frequency (if not letting the WASM update). I do not know if this is a timing issue - this was just to look into due to the description of your issue. How long are you sleeping for between each set request? Or, better, what is the frequency of your set requests? Do you get the same problem if you slow this down to say just 1 update per second? Please activate debug logging on both the WASM and WAPI and show me both of the log files. John

Then why not post in that topic, or at least provide a reference to it... No macro files are ever deleted by the installer (or uninstaller) - if they were deleted, something else must have done this. Maybe show me your InstallFSUIPC6.log file, as well as any uninstall log files (if available). I know the installer/uninstaller does not delete these files - there is no reference to *.mcro files anywhere in the installer (apart from maybe in a message displayed to the user). The FSUIPC6 installer also hasn't changed for a few years now, so nothing has changed. Usually when this is reported it is due to the fact that you have installed FSUIPC6 in a different location to your original FSUIPC5 installation folder, which will be under the Modules folder of your P3Dv4 installation. Check that location to see if your *.mcro files are still there. However, if this i the case then you would also have no FSUIPC6.ini file (unless you copied your FSUIPC5.ini file to the new location and renamed it)... John

The callback will be called when the lvars have been updated regardless of what mechanism is being used to update the lvars. If the lvars are being updated internally by the WASM (which they will be doing if the WASM ini parameter LvarUpdateFrequency is set to anything but Off) then requests to update the lvars from the client (sent when the WAPI ini parameter LvarUpdateFrequency is anything but 0) will be ignored by the WASM, so the WASM ini parameter setting takes preference. John

Yes - it is part of the FSUIPC WASM. Thus us documented in the FSUIPC Advanced User guide only at the moment. U should provide a separate document for those using the WASM without FSUIPC really - I will look into this. For now, please find the document attached - details on the WASM can be found from page 46 onwards, with the location of the log and ini files described at the bottom of P48 (the WAPI ini is also described, which you will also be using): FSUIPC7 for Advanced Users.pdf Presumably the VS.LVARUpdateFrequency in the MSFSVarServices C# code sets the WAPI parameter LvarUpdateFrequency. You need to decide what update frequency you require and whether thus should be controlled by the WASM itself or by the WAPI client. If the lvars are being updated by the WASM itself, you should set the frequency in the client to be 0. Alternatively, if the client is requesting the lvar updates, you should set the update frequency in the WASM to be Off. If you mean the messages 'Error clearing lvar value data definition with id=...' then these are normal and can safely be ignored. The WAPI is trying to clean-up but the connection to the FS is no longer available. John

Then why have you again posted in that post, after you posted here? I am sorry but you are beginning to irritate me by continually cross-posting in other topics for the same issue. I am going to delete all your posts (and responses) in the FAQ post. Are you saying that your hardware is recognised when you have the B737 loaded, but not when the PMDG is loaded? And this only occurs with the PMDG aircraft? If you load any other aircraft, FSUIPC can detect your hardware button press? The other post is in the FAQ section, and should NOT be used for support requests, except unless specifically related to the subject of the FAQ. Again, your issue is with hardware button detection, possibly only related to the use of PMDG, but certainly not related to PMDG control/assignments, which is the topic/purpose of the FAQ entry. I like to keep FAQ entries short and too the point, not full of useless comments related to other issues. Please stop cross-posting and use this topic only for your problem. John

Please don't provide such large log files - I am not going to go through that file. You have far too much logging activated - only activate logging related to your issue, which in this case would be Buttons & Keys and Lua Plugins. So, remove other logging and generate a log file with that logging activated. Also, before posting it here, try looking yourself to see if you can see what the issue is. If you do this with the logging console window open, you should be able to see the log entries in real-time which will help you diagnose your issue. You also hijacked a topic that is nothing to do with your issue. Please do not do this - raise a new topic if you cannot find a similar issue. This topic (also badly named) has nothing to do with lua. A quick scan of your log reveals this line: 340067 *** LUA Error: ...ments\Prepar3D v4 Add-ons\FSUIPC6\My320functions.lua:191: Event proc not found Line 191 is: event.flag(12,"AB_OVH_Ext_LANDING_retract") and there is no such function as AB_OVH_Ext_LANDING_retract, which will be your problem. If you had less logging, and had looked at the log for youtself, you should have been able to see and correct this on your own... John

If they are truly "Hot keys" (i.e. the application recognises the key press regardless of focus), then you should be able to assign your hardware/button to just send the required (hot) key. Even though this goes to the FS, it should be recognised as a hot key by the application. Otherwise, there is no facility in FSUIPC to send a key press to a specific application. However, this functionality is provided by WideFS/WideClient. So you could try installing WideFS6 (which is also free) and use WideClient on the same computer as your Swift VATSIM client (which can be on the same computer as the FS). Check the WideFS/WideClient documentation on how to do this. John

Ok, thanks for the update. This cannot be related to MSFS as it is not involved. Error #12 indicates that the utility cannot connect to FSUIPC. If FSUIPC7 is running, check that you are running the addons at the same privilege level as FSUIPC7. That is, if running FSUIPC7 with admin privileges, then the add-ons must also be ran with admin privileges, and if running without admin privileges, then the addons should also run without admin privileges. John

That lvar looks like it belongs to the Douglas DC6 (PMDG) - do you have that aircraft installed? If so, try removing that from your community folder if not using it (the MSFS Add-on Manager is a good free tool that many folks use to manage the contents of their Community folder). Also, i have noticed that if you start using one aircraft, and then switch to another (or even if the aircraft you used in a previous session is different to the one that you are using in newly started session) the the lvars from the previous aircraft are not fully cleared and are reported as available in the current aircraft. I'm not sure if this is due to the aircraft or MSFS (but most probably the latter). I will take a look at the FBW later to see how many lvars I see with that aircraft... I'm not sure you can 'deactivate' them. The gauges API provides functions to unregister them. However, I suspect this must be used with great care as unregistering an lvar used by the aircraft model could have severe affects, and it is difficult to determine what lvars are in use. I can investigate using these functions, but it would be better if MSFS (or the aircraft developers) removed all existing lvars before creating these used by the current model. Could they be created but not visible as they are created with ids > 2044? Maybe compare an id-ordered lvar list (available in the FSUIPC7log when you list the lvars) to see the difference between when they are available and when not. If you have a while bunch of defunct lvars before the FBW ones, these could make those lvars go outside of the 2044 range. If thats not the case, then you need to ask the FBW team why these are sometimes not available. John

Can you add offset logging (in FSUIPC) for offsets 0x0BDC and 0x0262, and also activate logging for Events and Axis controls, and produce a log file showing your issue. i.e. load an aircraft, set the flaps and then pause (offset 0x0BDC should then go to 0, according to your description). Then exit P3D, and attach your .log and .ini files. The log file may need zipping to reduce its size before attaching. Please don't start a new log file -I need to see the full log file. I may also need to see a log file with IPC Writes also activated. You can do the same test with this activated in addition to the other logging as well, and also zip and attach that. John

Maybe also check the WASM log file to see if there are any errors reported there...

I can only think this can be do with the speed you are calling this function, as Paul says. The simconnect call to set the value in the client data area is failing (as the message indicates), but there is no way that i can think of to get further details on why this is failing. Did you try continuing to see if subsequent calls succeed? If you can continue, see what %age if errors you get, and try throttling your requests accordingly (i.e. until you don't get any errors). John