John Dowson

Try with the following lvars: ELECTRICAL_APU_Bleed ELECTRICAL_APU_Starter and maybe ELECTRICAL_APU_Generator_1 ELECTRICAL_ExternalPower_1 First try operating the APU using the UI and listing the lvars to see how they change. You can then try writing to them - suggest you do this initially using the Add-ons->WASM->Set lvar... functionality first to check they are writeable lvars and not just read-only lvars. If you find you can control them that way, then you can either add the lvars to offsets and assign to them using the Offset controls, or use macros or a lua script. Later: maybe also try the FBW A320 as that fixes a lot of issues that the stock A320 has. However, looking at some of the APU lvars on the MF site (e.g. https://hubhop.mobiflight.com/#/presetview/8f842455-d574-4d5e-93a0-f3eb7e4e4652), they are also not working in the stable branch, so you may need to use the dev branch. Anyway, worth installing and trying if you fly the A320.

Ok. Let me know if you have any issues.

You cannot use 66FF, as the offset is 4 bytes so would go from 66FF to 6702 (4 bytes), and so would overwrite the data in offset 0x6700. Try with 66FC - data would go to 66FC - 66FF (4 bytes). Then I suspect that you are using an old version of FSUIPC7. The 'F' designator was added in the most recent release, v7.2.7, released on the evening of the 23rd (two days ago). Please download and update. Yes, and you also need to specify the offset you are using (66FC?). John

I don't think this is possible using macros as the parameter will be treated as an int. However, there are two things you can try: 1. you can add that lvar to a free user offset, using the lvars-to-offsets functionality, using a type of 'F' (for 4-byte floating point numbers). Then you can assign to the Offset Float32 Set/1000 control, specifying the user offset you are using with a parameter of 100. 2. You can use a lua script, passing in a parameter of value*10 and then dividing the parameter by 10 in the lua script before setting the lvar value, using the ipc.writeLvar function (or have the value hard-coded, if you prefer). John

You need FSUIPC6 for P3Dv5. If you want to use the registered facilities (assignments, lua, etc) then you need to purchase a license. If you have already purchased FSUIPC5, you will automatically get a discount applied on checkout. John

If it doesn't work/download with a single left click, right-click and select 'Save as...'. You can also download from www.fsuipc.com. John

No, its FSUIPC6 for P3Dv5 (and FSUIPC6 also supports PsDv4). FSUIPC5 is no longer available (to purchase). John

You need to check your code and/or ask on Paul Henty's .net client sub-forum. I have checked the offset by assigning a couple of buttons to write either 1 or 2 to offset 0x0298, and this is recognised, the SPEED_SLOT_INDEX_SET control/event is sent and the offset value updated, as can be seen from this log extract: I therefore think there must be something wrong in your code (sorry, I don't use C# or the .net client so can't help with this). You can also try updating the offset directly (via an assignment or using lua) to confirm. John

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.