John Dowson

First, you posted in the FAQ section, where it explicitly states NOT for Support Requests. I have moved your post to the main support forum. You can use the offset area starting at B000, which uses METAR weather strings. However, you may find it easier to use a 3rd party weather engine to control weather, either free or payware.

No problem. What do you men by this? You can read and write lvars when the sim is paused. However, I have disabled lvar functionality (from the WASM) when MSFS is in a main menu (or aircraft in a parking state). There are some lvars available in this state from the loaded (or partially loaded) aircraft, but there is really no point doing anything with them. FSUIPC detects 3 out of the 4 pause states - still not possible to detect the default 'pause' (but more like an alt/att freeze), but that one really shouldn't be used - even though it is currently the MSFS default pause! I have posted in the Asobo forums on how to detect the various pause and in-menu states via simconnect events, if you are interested check there. With MSFs especially, I find its best not to do anything (via simconnect or WASM) until a plane & flight are already fully loaded, or the results are unpredictable. Another issue is that this state is also very difficult to detect! In the WASM, I have added a delay of 1500ms (can change using the ini parameter LvarScanDelay) which delays scanning of lvars for that amount of time after the 'ready-to-fly' state is deduced. If you increase this (or you can just issue a reload command instead) you will see that you will get a few more lvars than the first time (for complex aircraft) as the aircraft model continues to load and/or change. Ok, thanks.

Ok, thanks. You may get this earlier though as Pete has said he may look into it for you, even though he has "retired"...! I need to allocate the offsets first though, and make a decision as to whether to start re-allocating old offsets (FS9 and before) that are (hopefully!) no longer used... Will keep you informed. John

Yes, this is possible. However, I don't know at the moment when I will have time to look into this. I also have several other pending new feature requests. I'll add this to the list, and and let you know when I come around to looking at this in detail. It will probably be a few months away though, as I've a lot on my plate at the moment with getting lvar access working in FSUIPC7. Once thats done/released, I will start on the backlog of other user requests. Regards, John

As it says in the README, install both x86 and x64 libraries. FSUIPC will need the x64 (64-bit), but best to also install the x86 (32-bit) as well.

As mentioned above, did you click the Register button and if so what happened? If it said your key was valid, then check your installation location - make sure you haven't installed FSUIPC6 under your Documents folder, especially if you are using OneDrive or some other cloud-based storage mechanism for your Documents. If all else fails, you can manually create your key file. Create a file in your FSUIPC installation folder called FSUIPC6.key, with the following contents, substituting the details in bold with those from your SimMarket order:

The splash screen is not related to anything else - it should display that while MSFS is starting. I've really no idea why that isn't working for you, but its not important to the functionality. But there is no such message...can you show me what this message says please. And FSUIPC7 runs ok? What happens when you try to run FSUIPC7 on its own, by double-clicking the FSUIPC7.exe? If you get an error when running FSUIPC, you need to update your VC++ redistributables. See the README.txt provided.

No. Sleep is not a blocking system call, so the script will be killed anyway, as you observed.

A few bug fixes and improvements, and max number of lvars increase to 2044 in this version (now the latest and only supported version, so please update): FSUIPC-WASMv0.4.8.zip @andhogThis also contains a few further corrections for when using > 1022 lvars, so can you please test this and let me know. I have released anyway, as this version contains a few other corrections that need to be released, the main one being that lvar/hvar CDAs were getting confused on a reload.

Yes, it should be killed regardless of whether it is 'sleeping' or not. However, I suspect that if the process is sleeping due to a blocking system call, then it won't be killed before that is returned. This is why there are sometimes issues killing luas that use the com library.

I have moved your post to the specific sub-forum for FSUIPC7. This is because you have hidden known file types in Windows Explorer - see the Addendum on the last page of the Installing and Registering FSUIPC7 manual. What do you mean by this? Can you show me your FSUIPC7.log file please. You will have to follow the advice in the Addendum before you can see this file. Which desktop link - the one FSUIPC7 creates? Do you see the splash screen? Does MSFS start? What needs to shut down - MSFS or FSUIPC7? Also, please don't attach .exe, .bat or .ico files - I have all those! I have removed them. When there are issues, I usually need to see your logs and ini files. Also, for start-up issues, I need to see your EXE.xml, so please show me this file: C:\Users\garyp\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\EXE.xml

No - its a dll an is automatically loaded and started by the FS.

Which version of FSUIPC are you using? The installer for FSUIPC5 must always be ran in admin mode, and the installer for FSUIPC6 requests admin level privileges. And if you are running P3D as admin, then as FSUIPC is an embedded dll, it also runs with admin privileges. It is normal for the P3D window to go black when you open FSUIPC. Sounds like the window may be being displayed outside of the screen coordinates. Try removing the parameter OptionsDialogOffset from your FSUIPC .ini file, in the [General] section.

Yes, I see the same. It seems that he requests from the WAPI to the WASM are working, but the data from the WASM isn't getting back to the client, so the client-side lvar/hvar lists are empty. I think this is because a lot of the functions from the WAPI.lib are missing from the dll, but I'm not sure how to correct this at the moment and don't have the time/resources to look into this, sorry. As I said, the project is now in github, so if anyone has any experience in wrapping a static lib in a dll wrapper, please take a look!

Ah, ok - thats good then, as you can just drop in the latest version and it will work without any changes. A few bugs fixed since 7.1.0a, but mainly in more advanced features. Yes, and lvar support is also coming soon. The WASM module (to enable lvar/hvar support) has already been released as a beta, and I'll be releasing yet another FSUIPC7 beta with lvar support in the next week or so. However, the initial lvar functionality will replicate previous lvar functionality in FSUIPC, so only accessible via macros or lua files.

Ok, well done - and thanks. Not sure which version of FSUIPC7 you are using, but there is also a beta version available (v7.1.0c) which has native support for up to 128 buttons, which will remove the need to use the Lua files for the Alpha & Bravo. See

Some issues with that version, please try the following: FSUIPC-WASMv0.4.7.zip

@d147 I have updated the interface rebuild the dll against he latest WAPI. Files attached below: FSUIPC_WAPI.hFSUIPC_WAPID.libFSUIPC_WAPID.dll I still don't think these are correct though, as the dll is only 96KB and the lib 8KB, whereas the WAPI lib is 6,473KB. I can push the DLL project to github if anyone wants to try and sort this out - I don't have time at the moment I'm afraid. John Later: I've just replaced the .lib/.dll so please download again. Project also available on github: https://github.com/jldowson/FSUIPC_WDLL As I have said previously, I don't think this is working at the moment.....

@andhogHere's the corrected version: FSUIPC-WASMv0.4.6.zip

If its a one button rotary, try the provided lua script, documented in the Lua Plug-ins document: If its a two-button type, then you can assign the different buttons to different increments (using the offset incr/decr controls). If its a phased rotary, then check the advanced user guide on how to handle. John

...power just back! Ok, will take a look. But tomorrow now..😴

Ah, yes - missed that. I will correct and let you know - tomorrow now though - power/electricity has just gone....

I don't think its an issue (at the moment) as only the CDAs needed (for the names) will be created, and its only an additional 8k CDA for the second values CDA, which won't get used by the client anyway. I'll look into allowing user restriction on the available lvars at a later date. Another quick and easy alternative for the time being would to add an extra ini parameter which can be set if you wanted to use more than 1022 variables, but I don't think its needed at the moment. Allocating an extra 8k, even if unused, shouldn't be too problematic these days.... Anyway, please try the version I attached. I can easily extend to allow for 1738 lvars (by allowing 12 lvar name CDAs which would accommodate 1752 lvars), or you can build yourself by changing the following in the WASM.h header file (if you are programming yourself, of course - if not, please ignore!): to Let me know if you want me to make a build for this...maybe this is something I can allow the user to set as an ini parameter, to basically tune to the needs of the user. However, this is obviously aircraft dependent, so I would need to allow tuning for profiles. Really, I need to concentrate on getting the basic functionality out and useable in FSUIPC7 before I consider such changes, but I don't mind over-tuning the parameters for the initial release, so it works for all/most add-ons, before I start adding the bells and whistles to tune.

Its up to you. You can still use the lua file in the beta version, with either the 128 button support enabled or disabled - from the Announcement page: You should try it, as its good to have people not using this feature (as well as people using this as well as the luas) to also test this beta. This will also be the official release at some point - hopefully pretty soon as I have had no further reports of any issues. John

Here - in the main support forum (I moved your post for you). The FSUIPC7 / MSFS sub-forum is specifically for FSUIPC7, all other support requests should go here. The 'User Contributions' forum is for contributions (advice, scripts, etc) from users, not support requests.