Jump to content
The simFlight Network Forums

Toggle Taxi Light with Lua Script


Recommended Posts

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
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
 
 
 
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 3 weeks later...

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

 

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

 

 





Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • 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.