John Dowson

But what exactly is your problem? A hatr switch (buttons 32-29) can be assigned as an axis (e.g. to PAN_VIEW, but not in MSFS/FSUIPC7) or as individual buttons. Your ini shows that you do have some assignments to your hat switch: The log you attached is useless as it doesn't show anything - not even which aircraft you are using. Could you please explain what your issue actually is. Also, active logging for 'Buttons & Keys' as well as 'Events'. Load an aircraft, activate the hat switch, then close down MSFS/FSUIPC7 and show me the log and ini files from that session.

I'm sorry to hear about your issues but I have no control over SimMarket - please contact SimMarket support via there support system: https://secure.simmarket.com/ticket_create.php John

Yes, this is correct. I will update to add the 0 terminator to all 3 offsets when updated. Note also that I haven't really tested FSUIPC when changing aircraft using the dev menu facilities. I'm not sure the correct events are being received by FSUIPC changing aircraft this way. I'll take a look at this at some point, bit it may take me a while (low priority).

Increasing the update frequency will apply to all lvars, not just those that you are adding to lvars. Increasing the frequency will (obviously) tale more resources, but not by much, at least in the ad-hoc tests that I have done. I wouldn't worry about this too much, unless you start having performance issues. a CDA is a Client Data Area. It is simcoonect terminology, and referes to the memory areas used to exchange data (via SimConnect) between the WASM and FSUIPC7. Its a technical term and I wouldn't worry about it too much. First try the standard offsets/controls for these to see if they work, otherwise look at the available lvars and hvars. The Mobiflight spreadsheet (now a web app - see https://hubhop.mobiflight.com/#/list) is a good resource for finding lvae/hvar/calculator code scripts for various a/c.

No, you don;t need an account to download as it is also freeware. Just download from www.fsuipc.com No. If you install into the same directory, your FSUIPC7.key file will be recognised and your registration details populated in the installer registration screen. You can verify again or just skip registration as you already have a keu file. If installing in a different folder, just copy your FSUIPC7.kry file to a different folder.

Before I look into this, please update to the latest version of FSUIPC, v7.2.6. Your log file shows you are using an old version, v7.1.0. However, your ini looks recent.... Are they from the same folder?

I know. Please see my previous comment and link. It is not related to FSUIPC. And please don't paste comments from other sites out of context - at least include a link to what you are referring. What are you expecting me to do with this?

If you are reading the lvar values from offsets, the lvar values are populated via the WAPI/WASM. Why don't you just try increasing the update frequency in the WASM, as advised?

Looks to be a general issue since the SU5 update. You could try deleting your rolling cache (if you use one) as it seems to improve loading times for some folk. See https://forums.flightsimulator.com/t/extreme-long-loading-times-since-su5-solved/428994 John

The increased loading time sounds like it is due to the latest MSFS update, not the FSUIPC update - especially as you have the same loading times with FSUIPC7 not installed. FSUIPC7 does not change anything in MSFS (expect the EXE.xml if the FSUIPC7 auto-start component is installed) and so can not be the cause of the increased loading times without it being installed.

I'm surprised at this if you are only polling every 500ms, which is slow. I would have thought that there would be plenty of time to receive the updated values back from the FS, even at a 6Hz update frequency. You could try setting the update frequency to VisualFrame (or Frame), to see if that helps.

Hmm, strange. How are you reading them? Reading an offset should be the same whatever the offset holds - an lvar, a simvar or anything else, as the code is the same. Its only the way the offset is populated that is different. Or are you talking about when monitoring them? If so, the monitoring logging will only be performed when the lvar value changes, which depends on the defined update frequency. The lvar update frequency can be controlled by the WASM ini parameter LvarUpdateFrequency, which is set to 6Hz by default, i/e/ 6 times per second. This can be changed to one of the following values: Off, Second, 6Hz, VisualFrame, Frame (with Frame being the fastest). Alternatively, if you turn off lvar updates in the WASM, you can set the update frequency in the client (FSUIPC7) by setting the same ini parameter in the [WAPI] section of your FSUIPC7.ini. Please see the WASM Module section in the Advanced User Guide, P 43. Ok, good. Thanks for letting me know.

From the log menu, and the statements will go to youy FSUIPC7.log file (if you don't opt to log luas to a separate log file, which you shouldm't). Please see the User Guide.

@Ircghost Did you try just leaving it running to see if it eventually loads? Just done some tests (in my development system) on loading times with and without the FSUIPC WASM module installed. In both cases, FSUIPC7 is started around 4min 10-15seconds after MSFS started. Without the WASM installed, I get to the MSFS main menu after around 11min 45seconds. With the FSUIPC WASM module installed, this increases but only by around 15 seconds, to 12min or so. So I really don't know what could be causing your issue....

I've increased this locally and now get 1903 lvars for the CRJ700. I will release this update in the next WASM/FSUIPC7 full release. I can post and advanced copy here if you need access to any of the lvars not currently discovered.

The current build/release of the FSUIPC WASM module is limited to 1752 lvars per aircraft - any with an index of 1752 or higher will not be discovered by FSUIPC7. This is due to the number of CDAs used to transmit the lvar values, currently fixed to 12 (and allowing 146 lvars per CDA). It seems there are more than 1752 lvars for the CRJ, which is why some are missing. I could increase the number of CDAs to 14, to allow for up to 2044 lvars to be discovered, if that helps. Let me know. John

There is an issue using the SD size specifier. That should really be used for an int (or signed int), not a 32-bit floating point value. I've updated to use signed int for SD in the attached version, and also added a new size specifier F, which can be used to convert the lvar value (double) to a 32-bit floating point number before being stored in the offset (4-bytes). FSUIPC7.exeFSUIPC7.zip

What exactly isn't working? The script log shows that the lua is running ok. Maybe you can try listing the lvar values and checking the value of the lvar L:A32NX_PARK_BRAKE_LEVER_POS Does it change value when you apply/release the parking brake?

I'm not sure. Are your scripts running and not working, or are the scripts not running? How are you starting them - from your ipcReady.lua? Your log shows one of the luas being killed (twice!): 251266 LUA: "announcement.lua": killed 1139453 LUA: "announcement.lua": killed Fist, check the scripts are running. Try activating debug logging for lua scripts, which would tell you if they are running or not. If they are not running, try adding them to the [Auto] section of your FSIOC7.ini (see Advanced User Guide for details) and remove them from your ipcReady.lua, if they are started from there. If they are running but not working as before, then please show me your 3 lua files (ipcReady.lua, announcement.lua, anouncement2.lua).

Yes and yes (21H1). Here are the exe details: size: 625 KB (640,000 bytes) size on disk: 628 KB (643,072 bytes) created: 17 ‎August ‎2021, ‏‎19:27:50 modified: ‎17 ‎August ‎2021, ‏‎19:26:31 Check the file properties are the same. I occasionally get support requests saying that the installer contains a trojan or virus (again, false positives, and usually due to the installer using NSIS) but this is the first time someone has complained about the standalone exe. zip attached. FSUIPC7.zip

I can download that and run it without windows defender causing any issues. If I rebuild, its exactly the same. I don't know why you are getting a false positive. If you don't want to try it, thats up to you, but there is nothing more i can do. John

No, just ignore.

Its not an issue as as you don't have any assignments in FSUIPC. All text display facilities are broken since SU5, so that will be your issue.

Did you not read my last comment: ? Corrected in the attached version - please try this: FSUIPC7.exe

No idea. Please show me your FSUIPC7.log and FSUIPC7.ini files. If using a new PC, did you check and update your device GUIDs in your FSUIPC7.ini? You need to change these if moving to a new PC, as the GUIDs (and also joy ids) can change. Also, what do you mean by 'announcements'? Note that all standard FSUIPC text display facilities are broken in MSFS since the latest update, as the SimConnect_Text API function is no longer working at all (it was partially working in previous releases).