John Dowson

Could you please share/post your solution - it may help others who have the same issue. Thanks.

Have you tried listing the available lvars? Also check the documentation that comes with the aircraft (does it contain an SDK?), and maybe ask on DC Designs support. Sorry, cant advise any further as this is the first I have heard of this a/c. Maybe some other users/owners can comment. John

You need to understand how the spoof offset at 0x0024 works. Please see the provided documentation. Here is the code in the script I provided: local spoofOffset = 0x0BC8 -- Parking Brake offset, unsigned word (2 bytes) local pBrakePosition = 0 -- Loop forever while true do -- Get value of the lvar A32NX_PARK_BRAKE_LEVER_POS pBrakePosition = ipc.readLvar("L:A32NX_PARK_BRAKE_LEVER_POS") if pBrakePosition == 1 then pBrakePosition = 32767 end -- and write it via 0024 as overrides to those being read ipc.writeStruct(0x0024, "1UW", spoofOffset, "1UW", 2, "1UW", pBrakePosition) -- Sleep for 100 mSecs so the update gets done roughly 10 times per second ipc.sleep(100) end John

A320ParkBrake.lua

Done

Please try the attached version, v7.2.7c: FSUIPC7.exe

I can't really help with Project Magenta - please use their support as a first port of call for this. Also, to control the A32NX, if using the FBW version, you should also use the FBW support/discord channel. However, you could also try activating logging (for Events and maybe also Axis Controls) and change the lights in the sim (via the UI) to see what events, if any, are logged, or what lvar values change, and then try assigning to those. There are various Light Potentiometer controls/events available in MSFS that you can also try, e.g.: However, at the moment only the Light Potentiometer Set control is currently flagged (in FSUIPC7) as an axis control, so the others cannot currently be used to assign to an axis. You can try the others by setting them to a key or button press, with an appropriate parameter, and I can update to allow them to be assigned to an axis if needed - I'll do this anyway as they are axis controls. John

This is very strange, as 68066 is the Speed Slot Index Set control, and is the same control sent when writing to offset 0x0298. You could try activating logging for Events, to check what is actually being sent when you write to that offset. Which offsets (or lvars) are you using for this? Maybe try the following offsets to see what they contain: 0x2F48 - Autopilot Cruise Speed Hold 0x3458 - Autopilot Airspeed Hold Var 0x3BD7 - Partial Panel Airspeed 0x07DC - Autopilot Airspeed Hold 0x07E2 - Autopilot Airspeed Hold Var Otherwise, it may be worth asking about this on the FBW support/discord channel.

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