Toggle Taxi Light with Lua Script

kdlovell · January 13, 2016

Hello,

I have been reading through the forums on how to toggle the lights in the 0D0C offset. My goal is to use a lua event to appropriately set the taxi light based on the Aerosoft Airbus Lvar. I understand each light is controlled by a separate bit and normally this would be done using AND and OR logic. However, based on what I have been reading in the forums and the Lua Library doc, the setbitsUW and clearbitsUW should work in place of using the AND and OR logic. Unfortunately, in all of my testing it seems to reset all of the other light offsets rather than just operate on the taxi light. I have also tested a one line script using setbitsUW to toggle the taxi light in the default 737 with the same result.

Am I using the code below incorrectly? Do I need the AND and OR logic when using the setbitsUW and clearbitsUW

-- set the pollrate to 250ms = 4 times per second

pollrate = 250

function writeTaxi(varname, value)

if value == 1 then

ipc.setbitsUW(0x0D0C, 8)

else

ipc.clearbitsUW(0x0D0C, 8)

end

-- create an event listener to monitor the LVAR

-- this will call the function above when the LVAR changes

-- Aerosoft Airbus Taxi Light

event.Lvar("L:AB_TAXI_LT", pollrate, "writeTaxi")

Thank You

Pete Dowson · January 13, 2016

I have been reading through the forums on how to toggle the lights in the 0D0C offset. My goal is to use a lua event to appropriately set the taxi light based on the Aerosoft Airbus Lvar.

If the Aerosoft lights are handled by an LVar, don't you need to write to that LVar to change it, not 0D0C? The latter collects together all of the default FS-implemented light switches.

I understand each light is controlled by a separate bit and normally this would be done using AND and OR logic. However, based on what I have been reading in the forums and the Lua Library doc, the setbitsUW and clearbitsUW should work in place of using the AND and OR logic.

Correct. If you are programming your own application using the regular FSUIPC interface you'd need to read 0D0C, change a bit using AND, OR or XOR, and write it back, hoping no one else had changed it in the meantime. But from Lua the setbits, clearbits and togglebits do it for you with no intervening changes guaranteed.

Unfortunately, in all of my testing it seems to reset all of the other light offsets rather than just operate on the taxi light. I have also tested a one line script using setbitsUW to toggle the taxi light in the default 737 with the same result.

Strange. If this were happening many things would be going wrong -- the technique is used extensively.

Am I using the code below incorrectly?

No, that looks fine. Please try two things:

1. Monitor 0D0C using the Monitor option, right-hand side of the Logging tab.

2. Enable Lua debug/trace option, in the Logging tab (do this before starting your plug-in).

Let me see the log please.

[LATER]

Just tested here with FSUIPC 4.929, and those functions definitely still work fine.

Pete

kdlovell · January 13, 2016

Hi Peter,

Thanks for the response. I should have mentioned that the reason I am trying to accomplish this is so that a virtual airline acars system can read the taxi light from FSUIPC when the Aerosoft Airbus is used.

I created a simpler example and turned on the logging as you suggested:

Sim: FSX Steam Edition

FSUIPC: 4.949

Aircraft: Default 737-800

Steps:

1) Load Aircraft and turn on all lights except taxi light

2) Run Lua script

Result: Taxi light turns on and all other lights turn off

Expected Result: Taxi light turns on and all others remain as is

Lua Script:

ipc.sleep(100)

ipc.display("Turning on Taxi Light...")

ipc.sleep(2000)

ipc.setbitsUW(0x0D0C, 8)

ipc.display("Done")

ipc.sleep(2000)

Lua Debug Log:

********* LUA: "test" Log [from FSUIPC version 4.949] *********

156203 System time = 13/01/2016 08:16:01, Simulator time = 11:14:15 (16:14Z)

156203 LUA: beginning "D:\Program Files (x86)\Steam\steamapps\common\FSX\Modules\test.lua"

160421 LUA: ended "D:\Program Files (x86)\Steam\steamapps\common\FSX\Modules\test.lua"

160421 System time = 13/01/2016 08:16:06, Simulator time = 11:14:19 (16:14Z)

********* LUA execution terminated: Log Closed *********

FSUIPC Log:

********* FSUIPC4, Version 4.949 by Pete Dowson *********

fsx.exe version = 10.0.62615.0

Reading options from "D:\Program Files (x86)\Steam\steamapps\common\FSX\Modules\FSUIPC4.ini"

Running inside FSX Steam Edition on Windows 8.0

Module base=55FF0000

User Name="Keith Lovell"

User Addr="keithlovell@metrocast.net"

FSUIPC4 Key is provided

WideFS7 Key is provided

62 System time = 13/01/2016 08:13:25

62 FLT UNC path = "C:\Users\Keith\Documents\Flight Simulator X Files\"

62 ------ Module Version Check ------

62 acontain.dll: 10.0.62615.0

62 api.dll: 10.0.62615.0

62 controls.dll: 10.0.62615.0

62 fs-traffic.dll: 10.0.62615.0

62 G3D.dll: 10.0.62615.0

62 sim1.dll: 10.0.62615.0

62 visualfx.dll: 10.0.62615.0

62 weather.dll: 10.0.62615.0

62 window.dll: 10.0.62615.0

62 ----------------------------------

93 Trying to connect to SimConnect Steam ...

93 FS UNC path = "D:\Program Files (x86)\Steam\steamapps\common\FSX\"

390 ---------------------- Joystick Device Scan -----------------------

390 -------------------------------------------------------------------

406 LogOptions=00000000 00000001

406 -------------------------------------------------------------------

406 ------ Setting the hooks and direct calls into the simulator ------

406 --- CONTROLS timer memory location obtained ok

406 --- SIM1 Frictions access gained

406 --- FS Controls Table located ok

406 --- Installed Mouse Macro hooks ok.

406 --- Wind smoothing fix is fully installed

406 --- All links checked okay

406 -------------------------------------------------------------------

406 SimConnect_Open succeeded: waiting to check version okay

406 Trying to use SimConnect Steam

4015 Running in "Microsoft Flight Simulator X", Version: 10.0.62615.0 (SimConnect: 10.0.62615.0)

4015 Initialising SimConnect data requests now

4015 FSUIPC Menu entry added

4031 D:\Program Files (x86)\Steam\steamapps\common\FSX\flights\other\FLTSIM.FLT

4031 D:\Program Files (x86)\Steam\steamapps\common\FSX\SimObjects\Airplanes\Aircreation_582SL\Aircreation_582SL.air

7453 Weather Mode now = Theme

21765 D:\Program Files (x86)\Steam\steamapps\common\FSX\SimObjects\Airplanes\B737_800\Boeing737-800.air

59000 Aircraft="Boeing 737-800 Paint1"

59000 System time = 13/01/2016 08:14:24, Simulator time = 11:13:32 (16:13Z)

66078 Starting everything now ...

82781 Advanced Weather Interface Enabled

129703 LogOptions changed, now 80000000 00000001

129718 Monitor IPC:0D0C (U16) = 2

144109 Monitor IPC:0D0C (U16) = 6

144109 SimRead: 0D0C="LIGHT LANDING"

INT32: 1 (0x00000001)

148093 Monitor IPC:0D0C (U16) = 262

148093 SimRead: 0D0C="LIGHT LOGO"

INT32: 1 (0x00000001)

150093 Monitor IPC:0D0C (U16) = 278

150093 SimRead: 0D0C="LIGHT STROBE"

INT32: 1 (0x00000001)

158375 Monitor IPC:0D0C (U16) = 8 <================ This is where the Lua script was run

164937 Sim stopped: average frame rate for last 35 secs = 92.3 fps

168671 System time = 13/01/2016 08:16:14, Simulator time = 11:14:23 (16:14Z)

168671 *** FSUIPC log file being closed

Minimum frame rate was 75.8 fps, Maximum was 122.2 fps

Minimum available memory recorded was 3015Mb

Average frame rate for running time of 51 secs = 99.7 fps

Memory managed: 27 Allocs, 27 Freed

********* FSUIPC Log file closed ***********

Thank you again for your time.

Keith

Pete Dowson · January 13, 2016

1) Load Aircraft and turn on all lights except taxi light

2) Run Lua script

Result: Taxi light turns on and all other lights turn off

Expected Result: Taxi light turns on and all others remain as is

Lua Script:

ipc.sleep(100)

ipc.display("Turning on Taxi Light...")

ipc.sleep(2000)

ipc.setbitsUW(0x0D0C, :cool:

ipc.display("Done")

ipc.sleep(2000)

Lua Debug Log:

********* LUA: "test" Log [from FSUIPC version 4.949] *********

156203 System time = 13/01/2016 08:16:01, Simulator time = 11:14:15 (16:14Z)

156203 LUA: beginning "D:\Program Files (x86)\Steam\steamapps\common\FSX\Modules\test.lua"

160421 LUA: ended "D:\Program Files (x86)\Steam\steamapps\common\FSX\Modules\test.lua"

160421 System time = 13/01/2016 08:16:06, Simulator time = 11:14:19 (16:14Z)

********* LUA execution terminated: Log Closed *********

FSUIPC Log:

Hmm. Very very strange.

I'll try your test, exactly.

Incidentally, you apparently did not turn on the Lua debug/trace option. And you don't want a separate Lua log as the idea is to make the Lua steps inter-relate to the monitoring action. Don't use "Luadebug" to start the plug-in, just start it normally, with a keypress or button.

[LATER]

Okay. I've reproduced the problem you describe. I don't know why I got a different result on my first test.

I'm checking now to see what could have got messed up.

Pete

Pete Dowson · January 13, 2016

Okay. Found it. It's the same with all the togglebits, setbits and clearbits variations! I don't know why it seemed okay when I tested it earlier. And it seems amazing that it's actually been wrong for years and no one has mentioned it till now!

The problem was that originally the same Lua code was used for FSUIPC3 and FSUIPC4. Now FSUIPC3 only has one memory space for offsets, and they are all read and written there. But because SimConnect is asychronous in operation I had to have two such memory spaces -- one for writing into and the other for the results returned (often a little later) from SimConnect.

I adapted all of the Lua code to handle this -- EXCEPT for these functions! They were reading and writing the write area, where they should read from the read area, do the changes, and write to the write area.

The FSUIPC Offset controls for the same functions work fine because that part wasn't based on original FSUIPC3 code!

I've fixed it in version 4.949c, available (DLL only for now) in the Download Links subforum shortly (about 30 minutes or so ...).

Thanks & Regards

Pete

kdlovell · January 13, 2016

Thank you Pete, I appreciate the confirmation that I am not crazy after all! I couldn't understand why I was having issues after reading through the forums for hours trying to figure this out.

Once again you have proven your legendary status in the sim community :)

Thanks,

Keith

Pete Dowson · January 13, 2016

Unfortunately I cannot at present get access to the Forum repositories in order to upload the corrected version. Seems that when all the SimFlight forums went down yesterday for an "upgrade" not everything was reinstalled correctly. I'm waiting for this to be fixed and will upload 4.949c as soon as I can.

Pete

Pete Dowson · January 13, 2016

Whilst awaiting some fix to my access rights to the Download section of the Forum, you can get FSUIPC 4.949c from Dropbox via this link:

Petes Downloadable Files

Pete

kdlovell · January 13, 2016

Thanks! I'll be testing this out tonight after work.

Keith

kdlovell · January 13, 2016

TESTED: Works like a charm!

Thanks Pete

Keith

aua668 · January 30, 2016

Hi Pete,

Since that change in 4.949c I have a problem with the ipc.togglebits function. At my Dodosim B06 helicopter I used

ipc.togglebits(0x029C,0x01)

for toggling the pitot heat switch. And with the FSUIPC versions before, also the switch in the panel moved.

Since 4.949c in P3D 2.5 the offset ist toggled, but the switch in the panel doesn't move anymore. If I use alternatively the ipc.control(65858) for toggling the pitot heat, the switch moves again. It looks like, that with the change you made, that there is a different behaviour than before. Toggling the bit has a different effect than calling the ipc.control for the gauge.

I could see the same effect at the GPS/NAV button. Maybe others are also working different now.

Best regards

Reinhard

Pete Dowson · February 7, 2016

Since that change in 4.949c I have a problem with the ipc.togglebits function. At my Dodosim B06 helicopter I used

ipc.togglebits(0x029C,0x01)

for toggling the pitot heat switch. And with the FSUIPC versions before, also the switch in the panel moved.

Since 4.949c in P3D 2.5 the offset ist toggled, but the switch in the panel doesn't move anymore. If I use alternatively the ipc.control(65858) for toggling the pitot heat, the switch moves again. It looks like, that with the change you made, that there is a different behaviour than before. Toggling the bit has a different effect than calling the ipc.control for the gauge.

I could see the same effect at the GPS/NAV button. Maybe others are also working different now.

Since the fix correctly operates by changing only the bits you specify, whereas previously, because of the bug, it affected other bits too, I suspect that one or other of the other bits are needed to change the visible switch. Try toggling all bits (255). It may be something to do with the way the gauges in that add-on are programmed.

BTW, when 029C is written, no matter how, FSUIPC checks whether he value has changed, and if soit sends the control "Pitot heat set" (control number 66074)with a parameter of 1 if 029C is non-zero, or 0 if it is now zero. That is not changed by the Lua "togglebits" fix.

I cannot understand what the gauge in your add-on can be doing to take different actions internally to that on the visible switch. That sort of thing might happen with mouse macros, but I can't see how it can react differently with standard FS controls.

Pete

kdlovell · February 7, 2016

Hi Pete,

Do you have an idea when this version of FSUIPC will be released on the download page? I'm just planning my code updates to line up with the new version's availability.

Thanks,

Keith

Pete Dowson · February 8, 2016

Do you have an idea when this version of FSUIPC will be released on the download page? I'm just planning my code updates to line up with the new version's availability.

Which version? 4.949c? It is there, in the Download Links subforum, and has been for a while. The main installer is still 4.949, 4.949a/b/c were minor updates which didn't justify a new installer build, that's all.

Pete

aua668 · February 8, 2016

Since the fix correctly operates by changing only the bits you specify, whereas previously, because of the bug, it affected other bits too, I suspect that one or other of the other bits are needed to change the visible switch. Try toggling all bits (255). It may be something to do with the way the gauges in that add-on are programmed.

Pete,

I tested with the following code:

ipc.writeUB(0x029C,0x01)
ipc.sleep(1000)
ipc.writeUB(0x029C,0x00)

And guess: everything works. The switch moves and the pitot is set on and off. With ipc.togglebitsUB(0x029C,0x01) it does not move - independent which bits I toggle. I tried with all bits. I traced with FSInterrogate and the correct bits were toggled. But the Switch doesn't move. And I also traced it in the FSUIPC.log:

  1075408 Monitor IPC:029C (U8) = 0x0
  1087249 Monitor IPC:029C (U8) = 0xFF
  1088715 Monitor IPC:029C (U8) = 0x0
  1089823 Monitor IPC:029C (U8) = 0xFF
  
  1090665 Monitor IPC:029C (U8) = 0x0
  1097545 Monitor IPC:029C (U8) = 0x1
  1098543 Monitor IPC:029C (U8) = 0x0

As a gauge can't react on offsets but only on key events, it seems, that by ipc.togglebitsUB the event PITOT_HEAT_TOGGLE is not triggered. But by simply writing to that offset it's fired obviously

I did trace the events fired and at writing the offset I find the PITOT_HEAT_TOGGLE event in the log:

  1768489 *** EVENT: Cntrl= 65858 (0x00010142), Param= 0 (0x00000000) PITOT_HEAT_TOGGLE

But with the togglebits function no event is written in the log.

Rgds

Reinhard

aua668 · February 8, 2016

Hi,

I tested it now also with a default C172 - same result. While ipc.write triggers the switch, the togglebits function doesn't.

Rgds

Reinhard

Pete Dowson · February 9, 2016

I tested it now also with a default C172 - same result. While ipc.write triggers the switch, the togglebits function doesn't.

Okay. Thanks. I'll check it here.

Pete

Pete Dowson · February 9, 2016

I tested it now also with a default C172 - same result. While ipc.write triggers the switch, the togglebits function doesn't.

Found it. This is another very long-standing bug which affects not only the togglebits functions but also the setbits and clearbits functions. Basically the problem was it was changing both the memory area for "Writes" AND that for "Reads", so the part of the code detecting changes to offsets never saw any. Of course they should read the read copy and write the write copy!

The earlier bug effectively masked this one!

Fixed in 4.949e, now provided in Download Links.

Sorry I didn't see this earlier. It was the problem of two different bugs affecting the same functions!

BTW this statement from earlier also led me astray:

"Since 4.949c in P3D 2.5 the offset ist toggled, but the switch in the panel doesn't move anymore."

I couldn't see how it was possible to separate the two actions. It sounds like your add-on aircraft is, itself, reading the offset as well as obeying the FS control event?

Pete

Pierre-Jean · February 9, 2016

Hi Pete, hi All here.

I'm very interesting for this thread here.

Fantastic Job Pete, fantastic ...

You "juggle" with bytes and scripts with a selfless manner and great competence.

Congratulations Mr. Dawson for this sharing and what we would do without you ...

Regards,
-
Pierre-Jean

aua668 · February 9, 2016

Pete,

I tested now version 4.949e with several aircrafts. And it worked absolutely fine!

Thanks for checking and fixing this issue so quickly.

Best regards

Reinhard

aua668 · February 11, 2016

Hi,

I just want to provide feedback to other users, that with the correction of the setbits, clearbits and togglebits functions there might be some other side effects, which were not visible by the bug.

I have several hardware switches with LEDs, which I connected to FS with some small LUA scripts. All these scripts are event triggered and have two major elements:

a switch function triggered by the hardware switch via event.button
a display function triggered by monitoring an offset via event.offset writing to an user offset, which is controlling my LEDs

Under these I had some switches driving standard FS lights via offset 0x0D0C. As this was an quite old code from FS9 times, I had used event.offset, as event.offsetmask have not been available in that version. So whenever one of the switches was switched, the event offset in all modules fired. I checked in the display function for the bit for the specific light and set or cleared the bit in my LED ouput offset. This worked, as writing and reading was done to the same memory location (by the bug now fixed). So setting and clearing bits - even if done in within a short time frame (as all events fired at the same moment) did work.

By using now different read and write memory locations and the asynchronous behavior of simconnect suddenly this did not work any longer. But it's an easy fix. i had just to change to the event.offsetmask function and now everything is fine again.

So as a conclusio:

If you have used event.offset for an offset like the 0x0D0C (lights) in several areas of your code, you should change them to event.offsetmask to avoid some side effects after this bug fixing.

Maybe this helps some other people, experiencing some strange behaviour after this change.

Best regards

Reinhard

Sign In

Toggle Taxi Light with Lua Script

Recommended Posts

kdlovell

Pete Dowson

kdlovell

Pete Dowson

Pete Dowson

kdlovell

Pete Dowson

Pete Dowson

kdlovell

kdlovell

aua668

Pete Dowson

kdlovell

Pete Dowson

aua668

aua668

Pete Dowson

Pete Dowson

Pierre-Jean

aua668

aua668

Create an account or sign in to comment

Create an account

Sign in

Browse

Activity

Important Information