Jump to content

Dataref for alarm light


Recommended Posts

I am not at my sim computer now.

 

but looking at the provided documentation, these below looks promising

ixeg/733/caution/caution_ap_rst_act

ixeg/733/caution/caution_at_rst_act

ixeg/733/caution/caution_fmc_rst_act

 

Hope this helps, otherwise let me know i can help you out when at the sim via datareftool

Link to post
Share on other sites

It seems as though IXEG have not exposed these lights via datarefs.

The majority of IXEG annunciators and indicators are exposed as datarefs with _ann or _ind at the end of the dataref name... but I couldn't find any for AP, AT and FMC alerts.

Maybe if you ask @Litjan nicely they can look into adding it in a future update. ;)

Link to post
Share on other sites

Great, I'm waiting for updates.

I still have a problem with these buttons, after declaring in FlyWithLua


dataref ("IXEG_ATAlarm", "ixeg/733/caution/caution_at_rst_act", "writable")

the button as if it were pressed all the time (clicking sound is heard) With other buttons, e.g. on Overhead there is no such problem,

Edited by dkdomino
Link to post
Share on other sites

Not sure why these datarefs have this behaviour... I have come across this in some other 3rd party aircraft as well. The moment you reference a dataref as "writable" then you get the constant repeating as if you're holding down a button.

The only workaround I could find is to use "Classic code" in your FlyWithLua script.
The recommended way is to use a magic metatable. (You can read up on this in the FlyWithLua manual)
Here's a sample of using a magic metatable:

IXEG_ATAlarm = dataref_table("ixeg/733/caution/caution_at_rst_act") --Creates the Lua magic metatable

logMsg("AT Alarm value is " .. IXEG_ATAlarm[0]) -- Prints the current value of the dataref in the Log.txt file of xplane
IXEG_ATAlarm[0] = 1 --Sets the value of dataref to 1

Note that you have to reference the table variable with a zero index for all datarefs that are not arrays.

Also keep in mind that for this particular dataref when you set the value to 1 it is like pressing the button once, but it will stay in the pressed position. You have to set it back to 0 to release it again. The problem with this is that when you set it to 1 and then back to 0 in your script, the execution is so fast that it will in effect ignore the release of the button. You'll need a flight loop callback, keep track of when you've set the value to 1 and after enough time has elapsed (+- 100ms is usually enough), set the value back to 0.

Hope this helps...

PS: Maybe if you ask @Litjan nicely (again) they can look into adding some custom commands for cockpit builders to avoid having to use "workarounds". ;)

Link to post
Share on other sites
On 4/19/2020 at 6:24 AM, dkdomino said:

Great, I'm waiting for updates.

I still have a problem with these buttons, after declaring in FlyWithLua



dataref ("IXEG_ATAlarm", "ixeg/733/caution/caution_at_rst_act", "writable")

the button as if it were pressed all the time (clicking sound is heard) With other buttons, e.g. on Overhead there is no such problem,

All our actuator manipulators are instantiated as objects from the same template object, so having a "few exceptions" is quite odd and I haven't the faintest what the issue may be with regards to our own code base, if at all.   If you are using FlyWithLua to overcome 'deficiency of datarefs' from our end, then please let me know as we are now working to expose many more datarefs / commands.

-tkyler

Link to post
Share on other sites

Hi Tom,

I can confirm that the following datarefs are not working as expected:

ixeg/733/caution/caution_ap_rst_act
ixeg/733/caution/caution_at_rst_act
ixeg/733/caution/caution_fmc_rst_act

Whenever you reference them as a dataref() from within a FlyWithLua script and you set them as writable you get constant "clicking" sound in the cockpit.

Also, there are no indicators for when the lights are on on these buttons. I would imagine that if you really want to be pedantic then you should have 2 indicators for the AP and AT buttons... red and orange. :)

One thin I would like to mention is the following:

Could you make sure that whenever you create a command, especially for buttons and swithces, that they will work correctly when using the command_once() function? I have seen in some 3rd party planes (not the IXEG) as well as some standard X Plane commands that they don't always work as expected when you execute them with command_once(). As long as you bind them to a keyboard or joystick button, or if you programatically execute the command_begin() followed by a short delay and then the command_end, then they work fine.

Just a thought...

Link to post
Share on other sites
4 hours ago, jfjoubert said:

O, and ixeg/733/fuel/fuel_qty_test_act dataref is also not working properly.

to reiterate.......by not working properly, you mean the Fly With Lua issue?   I press it in sim and it works as expected for me.  

-tkyler

Link to post
Share on other sites
8 hours ago, tkyler said:

to reiterate.......by not working properly, you mean the Fly With Lua issue?   I press it in sim and it works as expected for me.  

-tkyler

Hi Tom,

Apologies, I should have been more clear... this issue is only when trying to use these datarefs from a FlyWithLua script.

Link to post
Share on other sites
  • 4 weeks later...

....for those interested, we are probably not going to get the datarefs and commands we want to in the next update; however, we are not averse to very short cycle updates.  Because this update had such a backlog of important things, its taken a while and we must focus on those, but now that we are essentailly "caught up", will be able to implment improvements rather quickly and are targeting another update in less than a month to include many more commands and datarefs for hardware.

-tkyler

  • Like 1
Link to post
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.

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...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...