joeherwig

Hi John, Thanks... So i see... Main issue is the way how simconnect makes AVars hardly available compared to LVars. So the latter are much simpler to access? The easier approach seems to reach out to the Addon vendors to provide the values to be readable via LVars instead of AVars. 🙈 Joe

Dear John, I'm currently integrating the A320 Korry-Annunciators of FBW A32nx into my home cockpit. Of course i found in the Advanced Users guide you provided the Manual for "Adding Simulator variables (simvars) to FSUIPC offsets" on Page 34. And you already implemented plenty of mappings of the easy to work with variable-names to the offsets. So it seems, that FSUIPC is accessing the vars within the sym by name which is great. For us as users, it is really painfull to first search for the variable then add the variable into the myOffsets.txt, search for the next free offset within an allowed range (respecting the sizes of the previously assigned offsets etc. and then accessing the var via the hard to remember offset instead of the easy to remember and usually documented variable name... Do you see any chance to implement something to read (and set) MSFS A:Vars (and Z:Vars as they behave identical) by name instead of the offsets somehow? It would be a huge leap ahead regarding the use of FSUIPC for home cockpits. Probably it would make it a lot easier for you as well instead of implementing completely everything listed as simvars on request. Thanks a lot and best regards, Joe

@John Dowson it seems that ZVars really behave like the AVars. A friend from german flight simulator club succeded to utilize them using calculator codes. So obviously they already can be utilized. No need for change imho.

Hi John, As MSFS SDK offers also the Z:Vars - which are A:Vars aka SimVars that can be assigned by the aircraft designer it is currently not possible to read values from some aircraft like AS33ME. See: documentation attached. Adding those directly to FSUIPC offsets seems to be a nightmare for you as the devs might change them quite often... So is there any option to read the values of that simvars other than requesting it for each variable at you? Writing it is no issue using calculator code. So it's just about reading the values of those vars...

@Paul HentyIs it true that the Websocket Server is only able to register the ports on the hostname if it is started as Admin? If not started as admin i get the "access denied" message...

Hi John, Works like a charm in 7.3.9e. Thanks a lot! 0=DX,256,F,PA32NX_LIGHT_POTI_DISP+INTEGLT,0,0,0 -{ TO SIM: Preset Control }- 11=DY,256,F,PA32NX_LIGHT_POTI_FO_PFD,0,0,0 -{ TO SIM: Preset Control }-

Wow! That's been awesome fast. Thanks. I'll check it tonight if the Su10 download doesn't block me too long.

Hi John, If you keep that "side effect" it would be very nice. 👍 If you can adjust it to refer to the name instead of the line index (or whatever it is) it would be perfect. 👍👍👍🧡 As at least on my quite old system with quad core and 1080ti only i cannot notice any performance impact even with the really long combination of multiple calculator codes. Joe

Since John added already the capability to use parameterized CalculatorCode Presets on axes as well i just added the dimmers now based on that standard mode: Just add the lines for your myevents.txt A32NX_LIGHT_POTI_CPT_PFD#@ 10.23 / $Param 16384 + 327.86 / max 100 min 88 (>K:2:LIGHT_POTENTIOMETER_SET) A32NX_LIGHT_POTI_CPT_ND#@ 10.23 / $Param 16384 + 327.86 / max 100 min 89 (>K:2:LIGHT_POTENTIOMETER_SET) A32NX_LIGHT_POTI_CPT_WX_TERR#@ 10.23 / $Param 16384 + 327.86 / max 100 min 94 (>K:2:LIGHT_POTENTIOMETER_SET) A32NX_LIGHT_POTI_CPT_CONSOLE#@ 10.23 / $Param 16384 + 327.86 / max 100 min 8 (>K:2:LIGHT_POTENTIOMETER_SET) A32NX_LIGHT_POTI_FO_PFD#@ 10.23 / $Param 16384 + 327.86 / max 100 min 90 (>K:2:LIGHT_POTENTIOMETER_SET) A32NX_LIGHT_POTI_FO_ND#@ 10.23 / $Param 16384 + 327.86 / max 100 min 91 (>K:2:LIGHT_POTENTIOMETER_SET) A32NX_LIGHT_POTI_FO_WX_TERR#@ 10.23 / $Param 16384 + 327.86 / max 100 min 95 (>K:2:LIGHT_POTENTIOMETER_SET) A32NX_LIGHT_POTI_CPT_CONSOLE#@ 10.23 / $Param 16384 + 327.86 / max 100 min 9 (>K:2:LIGHT_POTENTIOMETER_SET) A32NX_LIGHT_POTI_FCU#@ 10.23 / $Param 16384 + 327.86 / max 100 min 87 (>K:2:LIGHT_POTENTIOMETER_SET) A32NX_LIGHT_POTI_ECAM_UPPER#@ 10.23 / $Param 16384 + 327.86 / max 100 min 92 (>K:2:LIGHT_POTENTIOMETER_SET) A32NX_LIGHT_POTI_ECAM_LOWER#@ 10.23 / $Param 16384 + 327.86 / max 100 min 93 (>K:2:LIGHT_POTENTIOMETER_SET) A32NX_LIGHT_POTI_DISP+INTEGLT#@ 10.23 / $Param 16384 + 327.86 / max 100 min 88 (>K:2:LIGHT_POTENTIOMETER_SET) @ 10.23 / $Param 16384 + 327.86 / max 100 min 89 (>K:2:LIGHT_POTENTIOMETER_SET) @ 10.23 / $Param 16384 + 327.86 / max 100 min 93 (>K:2:LIGHT_POTENTIOMETER_SET) @ 10.23 / $Param 16384 + 327.86 / max 100 min 92 (>K:2:LIGHT_POTENTIOMETER_SET) @ 10.23 / $Param 16384 + 327.86 / max 100 min 87 (>K:2:LIGHT_POTENTIOMETER_SET) @ 10.23 / $Param 16384 + 327.86 / max 100 min 85 (>K:2:LIGHT_POTENTIOMETER_SET) @ 10.23 / $Param 16384 + 327.86 / max 100 min 86 (>K:2:LIGHT_POTENTIOMETER_SET) and then assign it in FSUIPC directly:

Sorry ladies and gents, Just found Johns response in the forum that the VRInsight Panels always have these toggle behaviour. So seems to be resolved.

Ladies and gents, I was really annoyed by issues i have with my VRInsight MCPIIa Airbus Combo Panel so i digged a bit deeper. I noticed, that within FSUIPC logging of "Buttons and Keys" Most of the buttons are reported to be toggling: That's pretty wierd and really annoying. See example log... 1851656 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1851656 Button changed: bRef=0, Joy=290, Btn=23, Pressed 1851656 [Buttons] 16=P290,23,C65752,0 1851671 FS Control Sent: Ctrl=65752, Param=0 PARKING_BRAKES 1852796 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1852796 Button changed: bRef=0, Joy=290, Btn=23, Released 1853953 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1853953 Button changed: bRef=0, Joy=290, Btn=23, Pressed 1853953 [Buttons] 16=P290,23,C65752,0 1853953 FS Control Sent: Ctrl=65752, Param=0 PARKING_BRAKES 1854250 VRI com3 <--- A/TFL [from Lua Plug-in] 1854250 VRI com3 <--- F/Dup [from Lua Plug-in] 1854968 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1854968 Button changed: bRef=0, Joy=290, Btn=23, Released 1855781 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1855781 Button changed: bRef=0, Joy=290, Btn=23, Pressed 1855781 [Buttons] 16=P290,23,C65752,0 1855781 FS Control Sent: Ctrl=65752, Param=0 PARKING_BRAKES 1856515 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1856515 Button changed: bRef=0, Joy=290, Btn=23, Released 1857171 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1857171 Button changed: bRef=0, Joy=290, Btn=23, Pressed 1857187 [Buttons] 16=P290,23,C65752,0 1857187 FS Control Sent: Ctrl=65752, Param=0 PARKING_BRAKES 1857906 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1857906 Button changed: bRef=0, Joy=290, Btn=23, Released 1858343 VRI com3 <--- A/TFL [from Lua Plug-in] 1858343 VRI com3 <--- F/Dup [from Lua Plug-in] 1858593 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1858593 Button changed: bRef=0, Joy=290, Btn=23, Pressed 1858593 [Buttons] 16=P290,23,C65752,0 1858593 FS Control Sent: Ctrl=65752, Param=0 PARKING_BRAKES 1859359 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1859359 Button changed: bRef=0, Joy=290, Btn=23, Released 1860078 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1860078 Button changed: bRef=0, Joy=290, Btn=23, Pressed 1860078 [Buttons] 16=P290,23,C65752,0 1860078 FS Control Sent: Ctrl=65752, Param=0 PARKING_BRAKES 1861000 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1861000 Button changed: bRef=0, Joy=290, Btn=23, Released 1861656 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1861656 Button changed: bRef=0, Joy=290, Btn=23, Pressed 1861656 [Buttons] 16=P290,23,C65752,0 1861656 FS Control Sent: Ctrl=65752, Param=0 PARKING_BRAKES 1862453 VRI com3 <--- A/TFL [from Lua Plug-in] 1862453 VRI com3 <--- F/Dup [from Lua Plug-in] 1862906 VRI com3 <--- DSP1PrkB [from Lua Plug-in] 1862921 VRI com3 <--- DSP2rk! [from Lua Plug-in] 1863484 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1863484 Button changed: bRef=0, Joy=290, Btn=23, Released 1866312 VRI com3 <--- A/TFL [from Lua Plug-in] 1866312 VRI com3 <--- F/Dup [from Lua Plug-in] 1866453 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1866453 Button changed: bRef=0, Joy=290, Btn=23, Pressed 1866453 [Buttons] 16=P290,23,C65752,0 1866453 FS Control Sent: Ctrl=65752, Param=0 PARKING_BRAKES 1868484 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1868484 Button changed: bRef=0, Joy=290, Btn=23, Released 1870390 VRI com3 <--- A/TFL [from Lua Plug-in] 1870390 VRI com3 <--- F/Dup [from Lua Plug-in] 1870734 VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle 1870734 Button changed: bRef=0, Joy=290, Btn=23, Pressed 1870734 [Buttons] 16=P290,23,C65752,0 1870734 FS Control Sent: Ctrl=65752, Param=0 PARKING_BRAKES 1870843 VRI com3 <--- DSP1to L [from Lua Plug-in] 1870859 VRI com3 <--- DSP2GSK [from Lua Plug-in] That means, i have to press the button mostly twice to toggle for instance the LOC mode, or toggle the AP1 Master switch. Does anyone of you have an idea how i'm able to get FSUIPC working with EACH press instead of just the "pressed" state recognizing the button. It is really wierd... Because i assigned for instance AP Master for the Kodiak for both (press and release) and it shows the above behaviour. For the Parking breaks i could get a real toggle working as follows: Anyone able to give me a hint where the "VRI command USRBTN7. trapped as Joy 290 Btn 23 Toggle" stuff comes from? Thanks, Joe FSUIPC7.ini

Thanks John for your explanation. Using myevents.txt with only relevant planes definitely helps already a lot. Good recommendation! Best regards, Joe

Dear @John Dowson, dear @Pete Dowson, As the Capabilities of FSUIPC 7 grew really a lot since its start and especially working with Presets (events.txt and myevents.txt) and we get more and more great planes in MSFS i have a small suggestion. Within FSUIPC7 there are a couple of places where a command / preset can be chosen with a dropdown menu. As we now already have > 7700 elements in this dropdown it's sometimes quite hard to find what you're searching for - especially if you don't know exactly how it is called. That's extremely time consuming. Do you see a chance to replace that dropdown with a search functionality being capable of searching for all terms entered in there (and split with a blank " ")? I'm sure it would be really of great help. I made a small example online as JSFiddle to show what could be a great improvement: https://jsfiddle.net/Lsyr9fc3/6/show/ Just try within the "Control / Preset" field to find something. For instance for Kodiak the ignition could be found with "kodi ign", or for the Fenix Engine mode just search for "ENG" then extend it to "ENG Mode" to find the engine mode switch options. Or to find the rotaries of the G1000(NXI) just search for "1000_ inc" Could that be an option? Looking forward for your response... Best regards, Joe

I know it really well, but thanks for the hint. I'm sure plenty people of the community were not yet aware of it.

Hi John, that sounds great. I'll check it out. Joe

Tried it with @ 10.23 / {value} max 100 min 88 (>K:2:LIGHT_POTENTIOMETER_SET) @ 10.23 / {value} max 100 min 89 (>K:2:LIGHT_POTENTIOMETER_SET) @ 10.23 / {value} max 100 min 8 (>K:2:LIGHT_POTENTIOMETER_SET) @ 10.23 / {value} max 100 min 92 (>K:2:LIGHT_POTENTIOMETER_SET) @ 10.23 / {value} max 100 min 93 (>K:2:LIGHT_POTENTIOMETER_SET) wich is >255 chars for CPT PFD, ND, ECAM1 and ECAM2 and works like a charm. Thanks a lot John!

https://github.com/joeherwig/A32nx-LINDA-aircraft-module/blob/017b120227d9d2b5a2bb24fff0b685925425a237/A32nx/LINDA/aircrafts/FBW A320/user.lua#L12 shows the example for just two synced dimmers. (PFD + ND) if someone wants to map all display brightness it will become even longer. But the 1k you provided should definitely be a good value.

Wow. That has been fast! Wilco. Thanks

OK. So for the potentiometers we need ~ 64 chars per dimmer. Distinguishing for instance between displays (12x 65 = 780 chars) and integrated / flood lights (7x remaining lights potentiometers) 1k should be fully enough imho and also only require two or three analog axes. And for those building more elaborate homecockpits, you can be sure, they're going to assign everything direcly and won't join. So imho 1k should be enough for the moment.

Hi John, If we could have the option of up to 8k without causing any further issues (like FPS drops) it would be better then 512 chars of course to be future proof. 🙂 Whether it is FPS relevant i cannot judge of course. Thanks for you fast reply and best regards, Joe

Hi John, Got it well running for all light potentiometers with at least acceptable code style. Before we map that into our A32nx LINDA module and add the documentation i have one question. When i was trying to concat the calculator codes to use one potentiometer axis for multiple dimmers, it was working fine until i reached the 255 character limits. Is that something limited by MS/Asobo within the SDK or is that a limit in FSUIPC? Any chances to open up that limit? Thanks a lot and all the best, Joe

Cool. That helps. I'll give it a try. Thanks for the fast response.

Well as i percieve it, an aircraft.cfg contains everything to decide whether to choose the Asobo or the FBW profile for instance. The Asobo is clearly identified via the base_container = "..\Asobo_A320_NEO" [VERSION] major = 1 minor = 0 [VARIATION] base_container = "..\Asobo_A320_NEO" [FLTSIM.0] title = "Airbus A320 Neo Asiana airlines" ; Variation name model = "MAIN" ; model folder while everything for the FBW is mentioned as " base_container = "..\FlyByWire_A320_NEO" [VERSION] major = 1 minor = 0 [VARIATION] base_container = "..\FlyByWire_A320_NEO" ;===================== FLTSIM ===================== [FLTSIM.0] title = "Airbus A320 NX ANA All Nippon Airways JA219A SoccerYCA " ; Variation name model = "JA219A" ; model folder But as you can see matching on the title does either not work without matching it manually.That is something Andrew and i would like to avoid to lower the entry hurdle to work more with FSUIPC and LINDA. I'm member of the german Flight Simulation Club FSC e.V and i notice quite often that our members struggle with all that ini, offset thingies etc. and require lots of support. So why not making it easier for the users - and us as well. 🙂 Anyway... The mappings for the Asobo A320 and for the FBW A320 are in wide areas simply incompatible. So focussing on the base container (or what Andrew mentioned as airfile) would make it imho ways easier. Some more examples based on liveries i downloaded from flightsim.to. You wanna guess based on the title (i assume Aircraft 0x3D00) , which plane they are for? title = "Airbus A320 Neo Qantas2016 8K" ; Variation name for FlyByWire_A320_NEO title = "Airbus A320 Neo (FBW) Lufthansa (Dirty)" ; Variation name for FlyByWire_A320_NEO title = "Regierungsflieger" ; Variation name for FlyByWire_A320_NEO (automatically converted livery) title = "Regierungsflieger" ; Variation name for Asobo_A320_NEO title = "Airbus A320 Neo FEDEX Airlines" ; Variation name for Asobo_A320_NEO title = "FWB Delta Airlines N325US Dirty" ; Variation name for FlyByWire_A320_NEO title = "Airbus A320 Neo Vistara Airlines" ; Variation name for Asobo_A320_NEO title = "Airbus A320Neo Spirit Airlines" ; Variation name for FlyByWire_A320_NEO title = "Airbus A320 Neo Aegean Neo" ; Variation name for Asobo_A320_NEO title = "Airbus ACJ320neo" ; Variation name for Asobo_A320_NEO title = "Airbus A32NXneo Flytiger Airlines VA HK0987" ; Variation name for FlyByWire_A320_NEO title = "a320-livery-VUELING EC-MNZ_a32nx" ; Variation name for FlyByWire_A320_NEO title = "FWB Air Canada C-GUIF" ; Variation name for FlyByWire_A320_NEO title = "Airbus A320Neo LUFTHANSA" ; Variation name for FlyByWire_A320_NEO So if there is an option somehow to refer to the base container / airfile instead of the livery title, it would imho make sense to take that instead of the wierd titles. A lot of livery painters seem to be unaware which effect a title not sticking to a naming convention will cause for the users. So if we're able to make FSUIPC / LINDA / Modules more resilient against those errors, everybody would benefit from it. We with less support effort, and the users with easier to use systems. Right? Hopefully i didn't get it wrong. Joe

So... Tried to get it running with -- Dimmer values function setDimmer(offset, value) -- inverted connected potentiometer so -16384 is max while 16384 is provided as min. 🤦 percentValue = tostring(100 - round((value + 16384) / 327.68)) _log(".---. ".. tostring(offset) .. " in %: " .. " " .. percentValue .. " %" ) if (offset == 26304) then _log(".-.-.-.- Cpt. PFD brt " .. percentValue .. " %" ) ipc.execCalcCode("@ 10.23 / " .. percentValue .. " max 100 min 88 (>K:2:LIGHT_POTENTIOMETER_SET)") elseif (offset == 26305) then _log(".-.-.-.- Cpt. MFD brt " .. percentValue .. " %" ) ipc.execCalcCode("@ 10.23 / " .. percentValue .. " max 100 min 89 (>K:2:LIGHT_POTENTIOMETER_SET)") end end -- registering Dimmer value changed events for offsets event.offset(x66C0, "SD", "setDimmer") -- Cpt. PFD brt on x66C0 event.offset(x66C1, "SD", "setDimmer") -- Cpt. MFD brt on x66C1 And it fires correctly the events. and regarding the documentation i wanted to run it for multiple events No matter which potentiometer i turn, i get always both events fired. And if i log from within the called function, the offset is always converted to decimal (which would not be a problem if afterwards the lua would fetch it right.) If i run it (slightly converted from _log to print) it seems to be fine... see: jdoodle.com/ia/m6y or https://www.jdoodle.com/iembed/v0/m6y Probably one of you has an hint, what's wrong with my code...

Great to hear that you had such an flexible addition already in mind. It's so valuable to have so engaged people in the community! Kudos! I'll check your proposal. It sounds promising.