John Dowson

Ok - thanks for the update.

Ok. You can also try listing the available lvars to see if any of them stand out (from Add-ons->WASM->List Lvars menu entry).

Do you have an MS Store version of MSFS then, or a boxed version? Can you show me your InstallFSUIPC7.log file please (it will be in your FSUIPC7 installation). Sounds like the installer thinks you have a Steam version of MSFS. This is determined by the presence of the file $APPDATA\Microsoft Flight Simulator\UserCfg.opt Can you check if that file exists. If so (and you do not have a steam install), you should delete (or rename) that file, uninstall FSUIPC7 (using the uninstaller created during the installation process, or from the windows App management panel) and re-install FSUIPC7 as an MS Store install. John

👍😎

I've taken a look at this and this is what I have found: - when available, the ICAO designator, manufacturer and model strings (available in offsets 0x0618, 0x09D2 and 0x0B26 respectively) are enclosed in double quotes - I have removed these in the attached version - when starting FSUIPC7 when MSFS is already running with an aircraft loaded (i.e. out of main menu), only a partial path (from the SimObjects folder) for the aircraft.cfg file is passed given, and it is not possible to determine the complete path. In such circumstances, the offsets will be empty. You can enable logging for Extras, which will show the path to the aircraft.cfg as received from MSFS (in your FSUIPC7.log file). This is a known issue and was reported to Asobo over a year ago now. - even when the full path name is received, it is sometimes not possible to read the aircraft.cfg file. This applies to Deluxe and Premium content aircraft (and maybe also add-ons), as the files are encrypted for such content. Again, this is a known issue and I don't think there will be a way around this. Note that this is actually documented in the offset status spreadsheet for those offsets: Read from aircraft.cfg file (only available when 0x3C00 contains the full path to this file, and the file is readable) So I'm afraid that there is not much more I can do about these offsets, pending further updates from Asobo, sorry. However, note that the ATC Model and Type are also available in offsets 0x3500 and 0x3160. You may be able to use those, but they are currently prefixed by TT:ATCCOM.AC_MODEL for 0x3500 TT:ATCCOM.ATC_NAME for 0x3160 It is on my list to look into this, to see if I can remove those unneeded prefixes, or maybe to use the specific language localisation package files that come with each aircraft, e.g. here's the contents of the en-Us.locPak file for the C152: There could still be issues with this for Premium/Delux/add-on content though, not sure yet. This is on my list to investigate, probably starting around mid-September. Latest build attached. John FSUIPC7.exe

Yes - see the section Additional parameters to scale input axis values on P39 of the Advanced user manual - you can reverse and scale using that, and it looks like your usage is the same as the example given (i.e. add ',*0,5,+8192' to your axis assignment line), so try 10=HS,256,F,67012,0,0,0,*0,5,+8192 -{ TO SIM: ANTI_ICE_GRADUAL_SET_ENG1 }- John

Very strange. I'll take a look later this afternoon and get back to you. John

Not necessarily - in fact I doubt very much there is an offset for this as there doesn't seem to be s standard simvar that holds the wing sweep position. Found this on the wing sweep: So it sounds like the lvar L:WingSweepCover is the one that determines cover down (auto-mode) and cover-up (manual mode). As that says, when the cover is down, the sweep is determined by the mach number. so you can only change the sweep position manually when the cover is up. With the cover up, try changing the manual sweep mode and see if any of the lvars change (I can't see any suitable candidates). Also, try activating logging for both Events and Axis Controls, open the log console and see if any events are logged when you change the wing sweep in the UI. If there is something logged, you should be able to use that to control it. Its also worth asking on the DC Designs F-14 support forum, to see if there are any custom controls for this.

Best to check this type of thing with MobiFlight - see https://hubhop.mobiflight.com/#/presetview/a195f339-77e4-409d-a3a4-89fd192a2666 Searching for A320_Neo_FCU_HDG_INC gives the following: So it looks like A320_Neo_FCU_HDG_INC and A320_Neo_FCU_HDG_DEC are presets, not hvars. So, to use them as-is you would need to use the MF WASM and make the MF events known to FSUIPC via event files. Alternatively, you can try using the calculator code that the preset calls. Initially try using the Add-ons->WASM->Execute Calculator Code... menu option, and if it works as expected you can then have a lua script to execute the code and assign to that.

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?