John Dowson

FSUIPC7 is not auto-starting due to this error in your log file: This is usually due to another product corrupting the EXE.xml file (usually some logitech add-on for MSFS, but could be others). You can either remove that file and re-install (as suggested in the log), or post it here and I will correct it for you (if you also want whatever corrupted it also to be started).

I don't know PACX, but is FSUIPC7 installed and running (can you see its icon in your system tray)? If its not running, download the latest version from www.fsuipc.com and re-install (no need to uninstall). Then start MSFS and if FSUIPC7 is installed correctly and running you will see a splash screen and an icon in your system tray. If you don't, show me your InstallFSUIPC7.log file.

I think you need to add a delay between the write the read. The write takes a round-trip to MSFS, and then the updated values need to be sent back to FSUIPC7. If you write, then read directly, you will be getting the old value back as the internal values have not yet been received from the server. It shouldn't take too long for this, but this also depends on the update frequency set for the lvar values (defaults on every frame at the moment). Anyway, as you have just written the value, if its a writeable lvar then you can just set eCon to that value (40). Otherwise, try adding an ipc.sleep call between the writing and reading, starting with 100ms and adjust as needed.

If you have filed a flight plan, he GPS aircraft destination airport ID is in offset 0x6137. Other than that, I think you would need to get the location of the current flight plan (from offset 0x0130) and parse the file yourself (using lua) to extract the ICAO parameter from the [Departure] and [Arrival] sections. You may find the origin in the previous waypoint offset (0x6081) if you have a flight plan, as reported here: John

For using the Xbox One/360 controller with FSUIPC, you could look into using this for the time being (although it looks rather complicated to set-up): https://github.com/samuelgr/Xidi. I'll take a look at this on more detail when I get a chance. - this would be an interim solution (if it works) to use before I add direct support in FSUIPC.

For using the Xbox One/360 controller with FSUIPC, you could look into using this for the time being (although it looks rather complicated to set-up): https://github.com/samuelgr/Xidi. I'll take a look at this on more detail when I get a chance...and this would be an interim solution (if it works) to use before I add direct support in FSUIPC.

Sorry, I have no idea what O: variables are or how to use them. If you know how to use them, you could try in lua using the ipc.execCalcCode function. John

As I explained in my earlier post, it depends on how your rotary functions - is it a one button or two button (each direction) type? Or is it phased? Use the appropriate method as advised, depending upon the type of your rotary. If you want to use offset 0C4E, you need to assign to the Offset Word Increment/Decrement controls using that offset and an appropriate parameter, which is the amount to increment or decrement on each 'button press', so use 1 for the slow incr/decr, and maybe 10 or so for the fast inc/dec.

The legend is in column R, rows 6-12. This is a "temporary" document. I still need to merge this in the FSUIPC offset documentation to produce a new document for MSFS. I plan to start looking at this once the lvar functionality has been completed and released. Thanks! John

Thanks. Its also attached here. in-case the link dies:

No. You also PM'ed me this - please do not POM me for support issues, use the forum. You could have posted that here: Are you using the FBW (stable) mod? I don't think that lvar is available in the Asobo A320 Neo.

There is only one way to install FSUIPC7, and that is by running the provided installer. Any installation issues, I need to see your InstallFSUIPC7.log file, and need to know if you have an MS Store or Steam installed version of MSFS. This doesn't make any sense. MSFS can not possibly uninstall FSUIPC when running it.

Sorry, I really don't understand your reply. You tell me 'The Knob isn't turning' and expect me to know what you are talking about? As I said in my response, firstly this is not the topic to post such requests. This topic is for questions relating to the WASM functionality and the use of the WAPI, and its integration into FSUIPC7. It is not meant to be for control of specific functions for specific aircraft. For such issues, you need to raise a separate support requests, detailing your issue, and including at least the aircraft (and mod, if applicable), and as well as the function you are trying to assign, together with maybe any attempts you have made. If you do this, and its a default aircraft, I would look into this when I have time. If its an add-on aircraft, then an appropriate title may attract other users with that aircraft that may be able to help.

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.