John Dowson

That should be ok... did you create the macro file when FSUIPC was running? If so, you need to 'Reload all buttons' or restart FSUIPC7 to pick up the macro. Presumably you are using a registered version of FSUIPC7, no? Can you see the macro file in the [MacroFiles] section of your FSUIPC7.ini? Btw, better to call your macro file something like TBM930.mcro. Its then more obvious and you can use the same file to add other macros to the TBM930 later if needed.

Ok, then that makes sense. But, always better to close down FSUIPC before attaching logs. Did you have an FSUIPC assignments window open when the plane was loading by any chance? It looks like FSUIPC7 didn't even receive your aircraft name. so it never got to the 'ready-to-fly' state, which is strange...

Great, thanks for letting me know. And thanks for the hvar file, I will include that in the next release. Which also reminds me, I need to add something about hvars and hvars files to the documentation.... Cheers, John

But the log does not show FSUIPC closing down - did you attach it before exiting FSUIPC7? Usual places - on www.fsuipc.com or in the Updated Modules -> Download links section of this forum. v7.0.9 is basically the same as v7.0.9a, but best to try with the supported version before I investigate, if needed. If the log you attached was the complete log, then FSUIPC7 crashed and I need to see the event log. Anyway, download the latest version and try again. If you still get the same problem with v7.0.9, please also try with v7.1.0f. Any issues, attach your log + ini + any info from the windows event viewer, if FSUIPC7 is indeed crashing.

I have just tried this and it seems to still be working fine: The log you attached was cut short, and shows that FSUIPC7 did not reach the 'Starting everything now' stage. Did FSUIPC7 crash or did you manually kill it? Is there anything in the event log? Can you try again please, and if you still experience this issue attach your FSUIPC7.ini as well as the full log, and if FSUIPC7 did not close down correctly, please check the event log. Also, you are using an old release, v7.0.9a - please update to the official release, v7.0.9 (or the v7.1.0f beta).

To use it how? The FSUIPC lvar module provides access to lvars/hvars for FSUIPC7, and also for any other that wishes to use its facilities (vie the WAPI library). If using FSUIPC7, then you can use lvars/hvars only via macro files and lua scripts at the moment. There is also a section on configuration of the WASM in the latest Advanced User guide in the 7.1.0f release - see

Did you do this: ? If not, please do that before setting global weather. Also, try activating Weather logging in FSUIPC6, and if you still have issues please show us your FSUIPC6.log file.

The latest beta, v7.1.0f, including installer + updated documentation, is now available here: Install_FSUIPC7f.zip:

If you mean the value of an lvar, then you can list them in several ways: - using the Add-ons->WASM-<List Lvars menu option - using the list local panel variables control - using the log lvars.lua script - use the WASMClient Ok, then you need to connect your leds to the FSUIPC7 user offsets, and write the values of your lvars to the user offsets. To do this, you need to use the event.lvar function, which will trigger when the lvar value changes, then you can write the value to user offsets as a byte, using ipc.writeUB in the handling function (or functions).

Great - good to hear!

If they are grayed-out, this indicates that the WAPI IF is not active, usually because you are in a main menu on MSFS rather than having a plane loaded and 'ready-to-fly'. If you were in this state, try restarting FSUIPC7. Also, if using beta facilities you should use the latest, which is now 7.1.0.e. Nothing will work if the WASM menu entries are grayed-out, as the WAPI interface isn't initialised. Anyway, update and try again.

Yes, sorry, the lvar functions were removed as they previously weren't available. I've added this back now, and also added the new functions, but I haven't released the updated documentation yet. I will do this in the next beta release, including the installer, either later this evening or tomorrow. You should still have the FSUIPC Lua Library.pdf in your documents folder, for the ipc.writeXXX functions. Here's the additional documentation:

Yes - you can use the DontLogThese ini parameter, either in the [General] section of your FSUIPC7.ini (where it applies to all aircraft) or in a profile section. Please see the Advanced User guide for details. Maybe. For the 530, I would first look at the MobiFlight events with FSUIPC7: You need to install the MF WASM module, and make those events known to FSUIPC7 by using an event file. There is an old post in this forum with instructions and some event files that you can use (and also maybe try the MobiFlight website for instructions on how to install their WASM).

What are you trying to achieve with this? This script will set the lvars when the values in user offsets 0x66C0 and 0x66C2 are updated, bur what is writing to these offsets? If you want to write the values of the lvars to the offsets, then you need to use the event.lvar function. Your processing function will then be called when the lvar changes, and then you can write the lvar value to the user offset using one of the ipc.writeXXX functions. But it is not clear to me if you are just trying to read these lvars, set them, or both. Also, did you check that the lvars are actually writeable (either using the FSUIPC7 test facilities or the WASM test client)?

No, but its pretty straightforward. Take a look at the Lua library documentation for event.lvar. In your processing function you just need to use one of the ipc.writeXXX functions (where XXX is the type of the lvar, usually a DBL but can also be an int or other type). For the offset, you can use 0x66C0-0x66FF, or 512bytes from 0xA000. So, try for yourself, and post again if you have any issues.

Pete was only trying to help. There are no refunds. Why do you expect us to support add-on aircraft that we do not own? FSUIPC can maybe do what you require, but you have to investigate on how to do this. FSUIPC provides the tools, you have to do the work, It is not an "out-of-the-box" tool that can understand all aircraft/controllers or perform actions not allowed/implemented in the sim model. I suggest you read the documentation, both for FSUIPC and your add-on aircraft before anything else. This topic is now closed. If you have any questions on using FSUIPC (not already covered), then please raise a new topic. John

I think so, but not 100% without checking...best to try. Actually, maybe not. All assignment facilities are for registered versions only. but I'm not sure if this includes the button flags. As I said, best to check.

Yes - anything with lua/macros is only with registered versions, even for use by offsets. I think so, but not 100% without checking...best to try.

lvars are auto-discovered by the WASM, and you can re-initiate a scan at any tine by issuing a 'Reload' command (from any WASM client, such as the test Client or FSUIPC7). For hvars, you will have to find them yourself. I have provided a hvar file for the A320 (constructed form the MobiFlight spreadsheet), but you need to search for hvars yourself i'm afraid. There were instructions on how to do this on the Asobo forums a few months ago, but I have been unable to find that post since. I have also asked for users to supply these if found, but have received nothing so far on this. Hvars are new to MSFS, and there is scant info on how to find/use at the moment... I will look into these further when time permits. However, for the time being I would like to concentrate on getting lvar functionality via FSUIPC up & running & reliably. I have provided access to hvars, but there use is really down to the user... John

As well as what Pete has said, the usual way to program a button or switch is to activate event (non-axes) logging in FSUIPC, activate the desired UI component to see what events + parameters its using, then assign your button to that event + parameter. If that works, fine, if not, then you need to start looking into alternative solutions.... John

I don't use MobiFlight (except for the MF WASM module), but I think MobiFlight uses FSUIPC offsets, so you could read the lvars in a lua script (using event.lvar) and populate some user offsets with the values to be read by MobiFilight.

You need a registered FSUIPC7 to use lvars/havrs in FSUIPC7. The WASM is free to use & distribute as you wish, and thw WAPI (and test client) are open source, so you can use that however you wish.

Yes, as Linda is lua based, which are part of the additional registered version functionality. More of a question for the Linda support forum really, but with FSUIPC profiles, general button & key assignments apply to all aircraft, and can also be augmented (i.e. added to or modified) by profile specific assignments. For axes, the general axes assignments will be used unless there is a profile specific axes assignment section, in which case that will be used and the general section ignored (even if the profile specific axes section is empty). ...I see Pete has also replied...

Sounds like you are running an unregistered version. Did you register again, or, if you had an existing key file, were your registration details displayed ok at the end of the installation process? Probably best to just re-install - just download the latest installer and run again to the registration page, and then register again (if needed), and if you have issues tell me what the pop-up said after clicking the Register button.

I added a lua function for his yesterday, but still not tested or released... I'm still queued for the current update that fixes the CTD when using standalone WASMs. Once tested, I'll release this as the next beta update, with the installer updated for the WASM & hopefully with updated documentation, in the next day or two. There is one major difference to the lua version though - it will have a max argument (i.e. calc. code string size) of 64 characters. I can maybe look into changing this if there is a need, but that would have to be a post-release update.. Cheers, John