Jump to content
The simFlight Network Forums

LVAR params out of range?


Recommended Posts

I thought I knew what I was doing, but maybe not!

For Leonardo's new Maddog X, here is the relevant (for this discussion) part of their  MaddogX_interior.xml file:

    <PartInfo>
        <Name>CM1_winglightl_switch1</Name>
        <AnimLength>20</AnimLength>
        <Animation>
            <Parameter>
                <Code>(L:CM1_winglightl_switch1, enum) 10 *</Code>
            </Parameter>
        </Animation>
        <MouseRect>
            <Cursor>Hand</Cursor>
            <MouseFlags>LeftSingle+RightSingle+WheelDown+WheelUp</MouseFlags>
            <CallbackCode>
                (M:Event) 'LeftSingle' scmi 0 == if{ 536870912 0 + (&gt;L:ext_lights_event,number) }
                (M:Event) 'RightSingle' scmi 0 == if{ 2147483648 0 + (&gt;L:ext_lights_event,number) }
                (M:Event) 'WheelDown' scmi 0 == if{ 536870912 0 + (&gt;L:ext_lights_event,number) }
                (M:Event) 'WheelUp' scmi 0 == if{ 2147483648 0 + (&gt;L:ext_lights_event,number) }
            </CallbackCode>
        </MouseRect>
    </PartInfo>
    <PartInfo>
        <Name>CM1_winglightr_switch1</Name>
        <AnimLength>20</AnimLength>
        <Animation>
            <Parameter>
                <Code>(L:CM1_winglightr_switch1, enum) 10 *</Code>
            </Parameter>
        </Animation>
        <MouseRect>
            <Cursor>Hand</Cursor>
            <MouseFlags>LeftSingle+RightSingle+WheelDown+WheelUp</MouseFlags>
            <CallbackCode>
                (M:Event) 'LeftSingle' scmi 0 == if{ 536870912 1 + (&gt;L:ext_lights_event,number) }
                (M:Event) 'RightSingle' scmi 0 == if{ 2147483648 1 + (&gt;L:ext_lights_event,number) }
                (M:Event) 'WheelDown' scmi 0 == if{ 536870912 1 + (&gt;L:ext_lights_event,number) }
                (M:Event) 'WheelUp' scmi 0 == if{ 2147483648 1 + (&gt;L:ext_lights_event,number) }
            </CallbackCode>
        </MouseRect>
    </PartInfo>

In the attached MD80Assigns.lua file, you can see how I have my script coded for this landing lights action.  When I press the switch, everything works fine.  The 'ext_lights_event' LVAR is written using the 'LeftSingle' parameters - 536870912 for the left switch, and 536870913 for the right - and both switches go to the EXT ON position.

When I release the switch, the 'RightSingle' parameters are sent - 2147483648 [2^31] for the left switch, and 2147483649 [2^31 + 1] for the right.  However, only the left switch moves back to the off position.  The right switch does not respond at all.  The attached lua log file doesn't show any error (I don't think).

This observation is consistent across all of the functions I've defined:  Parameters that are <= 2^31 seem to work properly.  Those greater than this value are apparently not sent, although the script is executing.

I know I'm probably missing something simple, so I apologize in advance for that.  But I've reached the limits of my knowledge and troubleshooting skills (which are meager to begin with!).  Any suggestions would be greatly appreciated.  Thanks!

MD80Assigns.lua MD80Assigns.log

Link to comment
Share on other sites

10 hours ago, Moderate Chop said:

When I release the switch, the 'RightSingle' parameters are sent - 2147483648 [2^31] for the left switch, and 2147483649 [2^31 + 1] for the right.  However, only the left switch moves back to the off position.  The right switch does not respond at all.  The attached lua log file doesn't show any error (I don't think).

This observation is consistent across all of the functions I've defined:  Parameters that are <= 2^31 seem to work properly.  Those greater than this value are apparently not sent, although the script is executing.

This doesn't surprise me as the maximum value of an int/long int is 2^31-1. But the callback code is adding either 536870912 (left single) or 2147483648 (right single) to the value of L:ext_lights_event (although I don't fully understand that code!), so I don't think you should be setting this lvar to such values...

Try looking at what that lvar actually holds (using the lvar logging menu item) and see how that changes when you set/change the landing lights in the UI.

If the aircraft is using integer values outside if the int range (i.e unsigned int values) then I don't think these can be used via lua.

You could also try setting the lvar value using the Add-ons->WASM-> Set Lvar... menu item - can you set such values from there?
 

Link to comment
Share on other sites

4 hours ago, John Dowson said:

You could also try setting the lvar value using the Add-ons->WASM-> Set Lvar... menu item - can you set such values from there?

I've tried this here and this does work (I am just using some lvars for the A320 when not loaded for this test):

A320_FCU_SHOW_SELECTED_HEADING = 2147483649.000000
A320_NE0_FCU_STATE = 2147483648.000000

So it does look like this might be an issue with the lua handling, or how the lua numbers are passed to the FSUIPC C lua library.
I will look into this in further detail when I get time (most probably not until next week I'm afraid), but in the mean-time you could maybe try adding the lvar to a free user offset and then updating the lvar by writing to the offset instead.

John

Link to comment
Share on other sites

Posted (edited)

Thank you very much for your replies and suggestions, John.  I will look into this later today and see if I can make progress.

Later...

I don't think the LVAR ext_lights_event actually has a value - it always reports '0' when I list the LVARs via the WASM menu, regardless of the switch positions.  It just seems to be a container for an array of other actions, triggered by the parameter you send.

Using Add-ons->WASM-> Set Lvar... behaves just like the lua script, or the assignments in the Assignments --> Buttons & Switches... menu item.

As a workaround, user Andy Digital on the MaddogX forums suggested subtracting the indicated interval and sending the negative of the result.  So instead of 2147483649 send -2147483647.  And this indeed seems to work!  This is because of some int overflow wrap around I do not understand(?).  Anyway, it works, and I'll use this technique for now.  Thanks!

Eric

Edited by Moderate Chop
Follow on info.
Link to comment
Share on other sites

On 5/9/2022 at 4:05 AM, Moderate Chop said:

This observation is consistent across all of the functions I've defined:  Parameters that are <= 2^31 seem to work properly.  Those greater than this value are apparently not sent, although the script is executing.

I have just checked this with a simple lua script:

Quote

B2D = 2147483648    -- 2^31
ipc.writeLvar("A320_FCU_SHOW_SELECTED_HEADING", B2D)
ipc.writeLvar("A320_NE0_FCU_STATE", B2D+1)

And when I run this and list the lvar values I see:

A320_FCU_SHOW_SELECTED_HEADING = 2147483648.000000
A320_NE0_FCU_STATE = 2147483649.000000

So values > 2^31 are being sent and applied correctly. I therefore suspect that it is the aircraft model that is not accepting such values.
You can also verify that the value is being sent and applied correctly by setting Debug (or maybe Trace) level logging in the FSUIPC WASM module and check the FSUIPC_WASM.log file to see what values the WASM is applying (see the Advanced User manual for details).

John

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

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