Jump to content
The simFlight Network Forums

joeherwig

Members
 View Profile  See their activity

  • Posts

    73

  • Joined

  • Last visited

  • Days Won

    2

 Content Type 

Posts posted by joeherwig

  2. Reading SimVars aka A:vars (and Z:vars) by name instead of offsets?

    in FSUIPC7 MSFS

    Posted

    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

  3. LUA: read simvars?

    in FSUIPC7 MSFS

    Posted

    @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.

    Quote

    -- $$ Map

    function LX_9050_map_scroll_west ()
        ipc.execCalcCode("(Z:B21_LX_9050_BUTTON_8_TOGGLE) 0 > if{ 0 (>Z:B21_LX_9050_BUTTON_8_TOGGLE) } els{ 1 (>Z:B21_LX_9050_BUTTON_8_TOGGLE) }")
        ipc.execCalcCode("(Z:B21_LX_9050_BUTTON_8,number) 0 == if{ 100 (>Z:B21_LX_9050_BUTTON_8, number) } els{ 0 (>Z:B21_LX_9050_BUTTON_8, number) }")
        ipc.execCalcCode("(L:SOUND_CLICK) 0 == if{ 1 (>L:SOUND_CLICK) } els{ 0 (>L:SOUND_CLICK) }")
    end

    function LX_9050_map_scroll_east ()
          ipc.execCalcCode("(Z:B21_LX_9050_BUTTON_7_TOGGLE) 0 > if{ 0 (>Z:B21_LX_9050_BUTTON_7_TOGGLE) } els{ 1 (>Z:B21_LX_9050_BUTTON_7_TOGGLE) }")
        ipc.execCalcCode("(Z:B21_LX_9050_BUTTON_7,number) 0 == if{ 100 (>Z:B21_LX_9050_BUTTON_7, number) } els{ 0 (>Z:B21_LX_9050_BUTTON_7, number) }")
        ipc.execCalcCode("(L:SOUND_CLICK) 0 == if{ 1 (>L:SOUND_CLICK) } els{ 0 (>L:SOUND_CLICK) }")
    end

    function LX_9050_map_scroll_north ()
        ipc.execCalcCode("(Z:B21_LX_9050_BUTTON_2_TOGGLE) 0 > if{ 0 (>Z:B21_LX_9050_BUTTON_2_TOGGLE) } els{ 1 (>Z:B21_LX_9050_BUTTON_2_TOGGLE) }")
        ipc.execCalcCode("(Z:B21_LX_9050_BUTTON_2,number) 0 == if{ 100 (>Z:B21_LX_9050_BUTTON_2, number) } els{ 0 (>Z:B21_LX_9050_BUTTON_2, number) }")
        ipc.execCalcCode("(L:SOUND_CLICK) 0 == if{ 1 (>L:SOUND_CLICK) } els{ 0 (>L:SOUND_CLICK) }")
    end

    function LX_9050_map_scroll_south ()
        ipc.execCalcCode("(Z:B21_LX_9050_BUTTON_5_TOGGLE) 0 > if{ 0 (>Z:B21_LX_9050_BUTTON_5_TOGGLE) } els{ 1 (>Z:B21_LX_9050_BUTTON_5_TOGGLE) }")
        ipc.execCalcCode("(Z:B21_LX_9050_BUTTON_5,number) 0 == if{ 100 (>Z:B21_LX_9050_BUTTON_5, number) } els{ 0 (>Z:B21_LX_9050_BUTTON_5, number) }")
        ipc.execCalcCode("(L:SOUND_CLICK) 0 == if{ 1 (>L:SOUND_CLICK) } els{ 0 (>L:SOUND_CLICK) }")
    end

    So obviously they already can be utilized. No need for change imho.

  4. LUA: read simvars?

    in FSUIPC7 MSFS

    Posted

    On 6/11/2021 at 11:08 AM, John Dowson said:

    You can read simulator variables that are held in offsets, using the lua ipc.readXXX functions.
    If the simvar is not yet held in an offset, you can request it to be added.

    John

    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...

    Screenshot 2022-10-08 110324.jpg

  6. Axes and Potentiometer

    in FSUIPC7 MSFS

    Posted

    20 hours ago, John Dowson said:

    Could you try the attached beta please, 7.3.9e. This should automatically re-write your ini to use the preset name when assigned to an axis, although you may have to go into the axis assignment dialog and click 'OK' to update.

    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 }-

     

  8. Axes and Potentiometer

    in FSUIPC7 MSFS

    Posted

    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

  9. Axes and Potentiometer

    in FSUIPC7 MSFS

    Posted

    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:
    LightPotentiometer_range.png.16e8a573b9ffd58a0712da544eba372e.png

    • Like 1

  11. VRInsight MCP is "toggling" on simple pushbuttons in FSUIPC. Why?

    in FSUIPC7 MSFS

    Posted

    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.
    image.png.d5d59a26b64607f76f12d8d5c990cd9d.png

    For the Parking breaks i could get a real toggle working as follows:

    image.png.0c9d96f95e04087cfa115637558ab148.png

    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

  13. FSUIPC7 small UX suggestion to make assignment of Presets / Controls easier.

    in FSUIPC7 MSFS

    Posted

    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

  16. Axes and Potentiometer

    in FSUIPC7 MSFS

    Posted

    On 2/7/2022 at 3:58 PM, John Dowson said:

    There is a version available, v7/2/16c, including an updated WASM, that has a 1k limit for the calculator code if you would like to try it. It can be found here:
        http://www.fsuipc.com/download/Install_FSUIPC7v7.2.16c.zip

    John

    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!

  19. Axes and Potentiometer

    in FSUIPC7 MSFS

    Posted

    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.

  20. Axes and Potentiometer

    in FSUIPC7 MSFS

    Posted

    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

  21. Axes and Potentiometer

    in FSUIPC7 MSFS

    Posted

    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

  23. For every Liverie a new profile?

    in FSUIPC7 MSFS

    Posted

    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

     

  24. Axes and Potentiometer

    in FSUIPC7 MSFS

    Posted

    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

    Quote

    "The function is called with the offset, so that the same
    function can, if desired, be used for more than one such event,
    and also the current (new) value in that offset."


    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...

     

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.