John Dowson

You have to do more than just activate the WASM.... What knob/aircraft/hvar/lvar are you talking about? Have you checked, if an lvar, that it is writeable? FSUIPC provides the tools for you, you have to investigate what works and how to use the lvars/hvars. I cannot possibly provide support for all lvars in all aircraft, especially in add-ons that I don't have. If you have any issues with a particular assignment, best to raise a new topic detailing you issue, and make sure you specify the aircraft that you are using. Then, someone else who has looked ath this may be able to help you, otherwise, if its an MSFS default aircraft, I may take a look for you. However, this support forum topic is for issues with the WASM and the lvar/hvar access in FSUIPC. It is not meant for specific questions on using a particular lvar/hvar in a particular aircraft. But there should be plenty of information there for advanced users who are already familiar with lvars/hvars. That is why this is currently a beta for advanced users. Even if I add more information, there won't be a 'how to use the WASM' section. That is in the background. The average user doesn't/shouldn't need to know much about the inner workings. You just need to know how to use lvars/hvars, and the documentation for this is already there in the relevant sections. We are also always open to user contributions if anyone wants to provide a more detailed tutorial. I do not have the time for this.

Ok, so its a momentary change. Yes, some lvars work this way - its really up to you to experiment to find out how these work especially for add-aircraft. Note that some lvars are also read-only, but FSUIPC has no way of knowing which. If you write to such lvars, they won't update.

I have said this several times to you now but you keep doing the same thing. The lvar name is the name of the macro. Due to this, you can only use any given lvar ONCE in any macro file (i.e. each macro name in a macro file must be unique), otherwise it will cause issues. Please stop doing this. That should work. If it doesn't, I don't know why. Does setting these values (using the WASM ->Set Lvar... menu entry) work consistently? If so, then activate debug logging (in FSUIPC7 WAPI and in the WASM) and check the correct values are being sent - maybe compare the log output from 'Set Lvar' to that produced from activating the macro. You can post your log files here and I will take a look.

No. Will it ever be complete? I update FSUIPC7 and release on a regular basis. Check the history document. All updates to FSUIPC7 are free. Yes. There are a couple of Java SDKs for FSUIPC, but these will be for windows. Note also that usually FSUIPC clients run in the same machine aa FSUIPC7. To run FSUIPC clients on a separate PC, you need WideFS7. This is also only available for Windows. I do not know how you could run something on Android - you would need a WideFS version for Android, which doesn't exist.

? As I said they are working using lvars (latest FBW stable). Or were when I tried them a few days ago.

This has been fixed in the latest beta, v7.1.0f, available here: The beta for the 128 update has been superceeded by a ne beta with lvar/hvar support. Sorry, I should mention that on the announcement - I will add that now.

There aren't that many steps. If you have installed the 7.1.0f beta (including the WASM), then all you have to do is enable the WASM in FSUIPC7 - you do this once, from the Add-ons -> WASM -> Enable menu entry. Once thats done, you can write your lua scripts to use lvars/hvars and assign or auto-run as required. So it basically works out-if-the-box, once enabled, although you can tune/change certain aspects if required. I have added some documentation for the WASM in the Advanced user guide, but I still need to add more, especially w.r.t hvars. I'll add more on this in the next update.

Don't worry about this - it looks like its not updating anymore. I will look into it. Me neither, unless you are using Saitek drivers and/or software. Rather than specifying the condition as M! off and M3 off, can't you just use M2 on: 53=CP(+B,15)B,2,C65603,0 -{FLAPS_DOWN}- ?

WideFS7 works with FSUIPC7 (as well as FSUIPC6, FSUIPC5, FSUIPC4), so yes, it will work with FSUIPC7 + MSFS.

As far as FSUIPC is concerned, the mode switch is just another button. Each position is a read as a button press (held), and I don't think they emit a release (at least not in my X52). As I have said, how to use the mode switch on the X56 has been asked many times before. Its pretty straightforward - please check existing posts on this topic. Not according to the log file you attached - thats from 7.0.5a, a very old version. Please check and update if needed. Is it? But previously you said it was mainly on B, but occasionally on A: I don't understand how it can do this, unless you have installed the saitek drivers and/or software. If so, best to remove and just use the standard windows drivers (and no saitek software). The Saitek ones are known to cause issues and best not to use.

Yes, of course (sorry!)...but really the value doesn't matter when checking a bit, its either 0 (off) or not 0 (~=0), unless you are checking for multiple bits....! The value, of course, will depend on the bit position.

Was FSUIPC running - did MSFS start it ok, or did you manually start it? If it didn't start, did you get a pop-up from MSFS saying that it couldn't be started? Your EXE.xml looks fine. From what you are saying, it is not clear to me if you have FSUIPC running. Please confirm FSUIPC is actually running before you start Pilot2ATC. And doesn't Pilot2ATC have any log files? If so, what do they say? As Pete says, if FSUIPC is running ok (and connected to the FS), any problems with clients connecting are down to the client.

Are you using one of the FSUIPc7 betas? If so, this has support for outside the 32 button range, and button 32 is shown as 132, 33 as 133, etc. If you previously useda lua to access buttons > 32, they will be using the button flags, and if still running the lua you will see two button presses (but the virual devive for the virtual buttons should be 64 or above....). I don't know why thwy aee showing as 'B', which is a normal device letter. Maybe show me your FSUIPC7.ini and an FSUIPC7.log and I'll rake a look. You don't need to do it this way. You can use compound button conditions. Please see the Advanced user manual. There are also many other support requests on using the mode switch in the X56 (and other devices) - if you have issues, try looking for one of them first.

ODOC is 2 bytes, so you can read the value using the lua ipc.readUW function. You can then get the value of the bit you want to test using the lua logic library. So, to check for landing lights, which is bit 2 (and 2^2=4), do something like n=ipc.readUW(0x0D0C) v=logic.And(n, 0x4) and v will hold 1 if the landing lines are on, 0 otherwise.

You shouldn't need to restart the simulator. You can issue a reload, as I said.

Thats ok, but there is no 'value' associated to an hvar, so you can just use: 1=H:A320_Neo_EICAS_2_ECAM_CHANGE_PAGE_ENG=Set 2=H:A320_Neo_EICAS_2_ECAM_CHANGE_PAGE_BLEED=Set 3=H:A320_Neo_EICAS_2_ECAM_CHANGE_PAGE_PRESS=Set (and no space between the 'H:' and the hvar name - I'm surprised it works if you have that...although white space may be removed, I'm not sure without checking the code....) If you list hvars (see the Add-ons->WASM->List Hvars... menu entry), can you see that hvar? If so, it may be that extra space after the 'H:'. Otherwise, the hvar is not know to FSUIPC7. FSUIPC7 only knows about hvars loaded from the aircraft *.hvar file, located in the FSUIPC7 WASM folder. Check that file and add it there if its not there already. If you do this when FSUIPC7 is running, issue a Reload (from the Add-ons->WASM menu) to reload the hvars (and lvars) for the current aircraft.

We don't get any feedback from issues raised. Best to check yourself it its available or not. It was recently reported that the to/from fields are now populated: I'll check the remaining fields in the next few days and raise another support request for the missing info. John

This may work as you are using different commands (Set, Dec, Inc), and so the menu entries are different. However, due to the lvar name being the macro name (internally) this can cause problems. Its fine if it works for you, but if you get problems doing it this way the first think I would recommend is that this be changed.

You have to write the controlling command (GLOB) to offset 0xC800 last - it is this write that triggers the weather change. See here for more details: I'm not sure if you also need the GLOB control in the Metar string, maybe @Pete Dowson can clarify. Try the WeatherSet2 utility, available from: although I'm not sure if the source is included....

Many aircraft continuously omit certain events, which are different for different aircraft. To stop such events being logged, you can use the DontLogThese ini parameter, which will stop the events being logged for all aircraft if in the [General] section, and for specific aircraft when in your [Profile,xxx] section. See the Advanced User guide for details. And make sure you have only activated logging for Events and Buttons & Keys. You can also open the FSUIPC7.log file in an editor and find your button press there.

Not 100% sure what you mean, but, depending upon what you want to achieve, lua scripts can be auto-started and wait for 'events' and then act upon them . Events can come from various sources, such as a button press or offsets. So you can set a lua function to be called when one of the gear position offset changes (or the landing light offset). Take a look at the event library documentation in the Lua Library.

FSUIPC7 should not run anything, it is MSFS that should run FSUIPC7. It was only in earlier versions of FSUIPC that the desktop icon started MSFS. So, first download the latest version of FSUIPC7 (v7.0.9 or the latest beta, v7.1.0f). Before your run it, best to uninstall your current version by running the uninstaller located in your installation folder. Don't wirry, when you re-install into the same folder all your current settings will be preserved. Also, you may have remnants of your Steam install left over, so if the following file exists, please delete (or rename) before installing FSUIPC7 again: <USER>\AppData\Roaming\Microsoft Flight Simulator\UsrCfg.opt

If you open your FSUIPC7.ini file in an editor, look in the [General] section and you will see these lines: Change to: TrafficStallTime=-2 InitialStallTime=120 NormalStallTime=-2 i.e. make the TrafficStallTime and NormalStallTime negative values. However, this will not solve your problem, but just prevent the re-connections due to stalled data. Looking at the new log you attached, the parameter for all your axis controls are 0 for the first minute and a half or so: Was it during this period you had no control? Than just over minute later there is a break of 4 seconds where there were no rudder controls, but could be sue to them not being used: Do you maybe have auto-rudder or some co-pilot functions active in MSFS?

In a text editor.

As well as what Pete says, your log shows two disconnect/reconnections due to stalled data. Try changing to the following ini parameters to the following - the -tve numbers will just log messages when data is stalled rather than re-connect: Also, activate logging for axis controls, and if you open the console you can see if/when any rudder controls are sent. You can attach the log if you get the same problem. And as Pete says, its not clear from the log the aircraft you are using when the problem occurs - and is it just in one aircraft, or all or multiple? Your log shows you using both the DA40-NG Asobo and the Just Flight PA28 Arrow III OE-DSN. In the former your rudder axis is assigned to the FS AXIS_RUDDER_SET, and in the latter it is assigned Direct to FSUIPC Rudder control.