Scotfleiger

Hi John, Sorry for the delay but I got tied up with other matters. Thank you for your considered reply. My understanding was at fault regarding FSUIPC profiles. I had forgotten it is the user who originally allocates a new aircraft to a specific profile. I await you having time to consider the the options for improving the .Hvar assignment to a specific aircraft. At present, only the default FBW A32NX (both Airbus and Xmas liveries) that can call up the A32NX.hvar events. The available variations can not which limits user choice. We appreciate all your hard work.

@VERTSPDmake sure your aircraft name includes a subset of the custom macro file name. If you are using a custom livery this may not be the case. For example, the "FlyByWire A32NX" matches the A32NX FBW.hvar file. Other liveries don't include A32NX.

Further testing and reading the advanced manual reveals that the selection of the aircraft Hvar file is also impacted by community liveries not including the matching string. This means additional .hvar files need to be recreated for each additional livery file whose name does not include the aircraft sub-string (eg. A32NX FBW).

That is a good idea. There is no rush.

Hi Pete I am not sure how FSUIPC matches the 2 samples to place them under the same profile. Loading the Asobo A320 and FBW A320 gives 2 different paths to the AIR FILE as defined by 0x3C00. When the OperatorLand468 BA FBW livery it the AIR FILE is the same as for the FBW A320. This I believe is the match that should define the Profile group for MSFS2020/FSUIPC7. MS/Asobo has changed how and where add-on liveries are stored. In the past with FSX and P3D the aircraft's own aircraft.cfg had to be edited to include extra liveries. With MSFS, the extra livery is installed in the \community directory. In the aircraft.cfg file for the BA FBW livery there is a pointer to the base aircraft in a [VARIATION] block. For example: Asobo A320 Neo with standard livery AirFile (0x3C00) = ....\official\onestore\asobo-aircraft-a320-neo\simobjects\airplanes\Asobo_A320_NEO\aircraft.cfg Aircraft (0x3D00) = Airbus A320 Neo Asobo Asobo A320 Neo with OperatorLand468 BA livery AirFile (0x3C00) = ....\official\onestore\asobo-aircraft-a320-neo\simobjects\airplanes\Asobo_A320_NEO\aircraft.cfg Aircraft (0x3D00) = British Airways OperatorLand468 FBW A320 with standard livery AirFile (0x3C00) = ....\community\flybywire-aircraft-a320-neo\simobjects\airplanes\FlyByWire_A320_NEO\aircraft.cfg Aircraft (0x3D00) = Airbus A320neo FlyByWire FBW A320 with OperatorLand468 BA livery AirFile (0x3C00) = ....\community\flybywire-aircraft-a320-neo\simobjects\airplanes\FlyByWire_A320_NEO\aircraft.cfg Aircraft (0x3D00) = Airbus A320neo OperatorLand FBW The AirFile is common to each aircraft while the Aircraft Name reflects the livery name. The aircraft name that is derived from the aircraft.cfg Title= entry is the same as that in FSUIPC7.ini profiles. I suggest it should be the AirFile name (before \aircraft.cfg) that should used. This is what LINDA has always used for identifying the aircraft loaded to use the corresponding module. I hope that makes sense.

Hi John I would like to reopen this discussion on matching loaded aircraft to specific profiles in MSFS2020. We are working at the moment on a LINDA module for the FlyByWire A320 Neo. We have found that different liveries for this aircraft are stored separately but linked to the loaded aircraft by a [VARIATION] entry in the livery aircraft.cfg pointing to the base-container (= "..\FlyByWire_A320_Neo"). FSUIPC, as described in the User Guide, uses a name match. This wrongly assigns the FBW livery to the Asobo A320 as follows: [Profile.A320] 1=Airbus A320 Neo Asobo 2=British Airways OperatorLand468 FBW not to: [Profile.A320NX] 1=Airbus A320 Neo FlyByWire While you suggest users should manually edit the FSUIPC7.INI Profile entries, the increasing number of add-on liveries will make this a major task prone to errors. It would be better if the base aircraft model (ie. base-container) could be used to match the profiles using the Air File? What are your thoughts?

The VAR:1 appears to be the constrained Altitude (limited by Flight Plan and flight profile as in SID) and VAR:3 is the targeted Altitude (as entered and displayed on FCU).

😉 It really is an arcade game. I will keep working....

Hi John Many thanks again. The AP Alt Lock Var (0x0768) works perfectly when convert to feet and apply the correction (/65536*3.29). Having switched on the MSFS control pop up help it reports that the A32NX EXT PWR button is unavailable. That would explain why the offsets are not working. Sorry for wasting your time.

Thanks for the clarification.

Offset 0x3400 allows a text message to be displayed in the MSFS window. Offset 0x32FA is normally used to define how long the message is displayed in secs. This does not appear to working correctly with MSFS with the message remaining on screen (it works with FSUIPC6). This is the function LINDA calls, the default timeout is 2 secs. function ShowMessage (text, cnt) if cnt == nil then cnt = 2 end if text == nil then text = 'Test message!' end ipc.writeSTR(0x3380, text .. string.char(0)) ipc.writeUW(0x32FA, cnt) end Also in MSFS 0x3400 calls marks these as TIPS!. Is there a different type of message box available like P3D's discrete top line? The Offset Status document note on Options-Settings-General-Text Display does not seem to apply to the latest MSFS 1.21.18.0. There is a question against this statement in the text.

Will do.

Offset 0x07D4 is mapped to MSFS Var AUTOPILOT ALTITUDE LOC VAR. The FBW A32NX refers to another AUTOPILOT ALTITUDE LOCK VAR:3. Is this var available (similar to 0x07CE for AUTOPILOT HEADING LOCK DIR:3)? Is so can you add it to the offset list?

Several of the dropdown menus are too narrow to display the full length of Hvar names. For example, the Activate HVAR and Button & Switch Assignment panels. This makes selecting the correct value pot luck in some cases.

Hi John The FlyByWire A32NX API lists a number of MSFS VAR and SIMCONNECT VAR some of which are listed in FSUIPC Offsets. Can I request that the following MSFS VARs be added to the offsets? EXTERNAL_POWER_AVAILABLE EXTERNAL_POWER_ON Is the a way developers/users could temporarily assign their own offsets to these variables? Once tested a consolidated request could be submitted to you.

Thank you John. I am now much better informed. I was quick off the mark trying to access the Lvars after start up.

Hi John, the latest build (version no unchanged) works for both ipc.getHvarName() and ipc.getHvarId(). The correct values are returned. When first run I got a nil error and had to click on Add-ons/WASM/List Hvars to 'load' the Hvars for use. I am still confused on the difference in use of the Hvars to the traditional Lvars. ipc.activateHvar is said to 'write' to Hvar but takes no parameter. How does this differ from ipc.writeLvar("name", n)? Is there any case for adding ipc.readHvar("name"), ipc.readHvarSTR("name","value"), ipc.writeHvar("name", n) and ipc.writeHvarSTR("name","value")? Thanks again.

It is the same and valid as I fed the results of one into the other. function test() m= ipc.getHvarName(5) _log ('Hvar = ' .. m) n = ipc.getHvarId(m) _log ('Hvar = ' .. tostring(n)) end returned : [EVNT] Execute Command = "test" : Hvar = H:A320_Neo_PFD_BTN_LS_1 : Hvar = 1.844674407371e+19 Good night.

V7.2.15a tested. ipc.getHvarName(n) returns the expected Hvar name and allows me to extract a full list of Hvars. I can also read and write to these Lvars as before. ipc.getHvarId("name") returns a very large number. For example, for the FlyByWire A32nx: n = ipc.getHvarId("H:A320_Neo_PFD_BTN_LS_1") _log ('Hvar = ' .. tostring(n)) returns Hvar = 1.844674407371e+19

Thank you so much. There is also the paired ipc.getHvarId("name") that would replicate those for Lvars.

Hi John Thanks for your help again. The lvars.lst is generated by LINDA using calls to ipc.getLvarName(id). It is likely that this ipc call was not implemented when I first modified LINDA with an early version FSUIPC7 as I had to comment out the calls and, hence, no list was created. I have now have a list. LINDA uses Delphi/Pascal and not C/C++ so calling WAPI is not an option. Without an ipc call I will look at accessing the .hvar lists directly.

Prior to FSUIPC7 Lvars were saved in file lvars.lst which is used by LINDA for monitoring and setting their values. Would it be possible to copy the list of current Lvars and Hvars to lvars.lst and hvars.lst respectively? The files should be populated when the aircraft is loaded based on the WASM.ini LvarScanDelay variable.

I think you will find that the Announcements link is a web redirection to https://forum.simflight.com/topic/92031-wasm-module-client-api-for-msfs-fsuipc7-now-available/ not to the zip file. This shows up when I hover the mouse over the link. The one above is to the zip file and starts a download. I have hit a problem with the fsuipc-lvar-module.zip file. When I follow the install instructions and extract into the MSFS Community directory, the folder is double embedded. Eg. the folder is fsuipc-lvar-module/fsuipc-lvar-module. I had to copy the inner folder contents up a level for FSUIPC7 to find it.

P3Dv5.3.15.28131 successfully reinstalled and offset correctly reporting version number. It appeared that somehow I had taken a step backwards when I installed the HF. Apologies for taking up your time.

The above links worked fine except I did yet an unsafe file warning which I bypassed.