Control Bravo LEDs based on offset changes

[Blake Buhlig]

Similar to what CoolDanLuke had provided, some time back I wrote a Lua plugin that controls the Bravo LEDs, though in my case I hooked it up to various FS2020 offsets so that the LEDs more reflect the simulator state. 

https://github.com/bbuhlig/fsuipc-contrib/blob/main/bravoleds.lua

Though, my attention is presently focused more on VR flight simming, and as such I can't see the LEDs to care much about them.  But the code could at least be a reasonable place for interested others to start.

[Grendel]

Thank you Blake, unfortunately the whole Lua thing is way over my head and I can't understand at all what I need to do to get the LEDs going. It's not a big problem as the throttle works well enough without them although the landing gear lights would have appealed had I cracked it!

Thanks again,

Gary

 

[John Dowson]

1 hour ago, Grendel said:

Thank you Blake, unfortunately the whole Lua thing is way over my head and I can't understand at all what I need to do to get the LEDs going. It's not a big problem as the throttle works well enough without them although the landing gear lights would have appealed had I cracked it!

The gear lights don't seem to be working with that script, at least not for me with the G36. I will take a look when I get a chance.
Make sure you are actually running the lua by adding it to the [Auto] section of your FSUIPC7.ini file, e.g.:

Quote

[Auto]
1=Lua bravoleds

You should at least see the PARKING BRAKE light work....

Also, the lua file should be in your FSUIPV7 installation folder - you should see it listed under the [LuaFiles] section of your FSUIPC7.ini (do not add it manually there - it will be added automatically when detected).

[John Dowson]

@Grendel and @Blake Buhlig

I got the gear lights working by making the following changes:
   - Change the initialization of GearIsRetractable variable (line 211) to
        GearIsRetractable=ipc.readUB(OFFSET_IS_GEAR_RETRACTABLE);
     NB. It would be better if all of the offset variables were  initialized this way, as you won't get the correct value unless event.offset is called (i.e. when the value changes).
   - You could also add the following at the end of the script:
        event.offset(OFFSET_IS_GEAR_RETRACTABLE,"UB","offset_event")
     However, as this value doesn't change (it should be fixed!), this isn't really needed once the GearIsRetractable variable is initialized correctly.

John

 

[Blake Buhlig]

Sorry about that, I think I added the GearIsRetractable support because the gear LEDs were lit in some fixed gear aircraft I was using and I was annoyed by that.  And then I don't think I've been in any retractables lately to notice the bug.

In fixing it, I also took the opportunity to refresh the code with some new OO ideas as my Lua knowledge is growing, and uploaded it to the same link.  It's working fine for me so far albeit I still need to test the autopilot LEDs.

[Blake Buhlig]

Testing a bit more, I found and fixed a few issues and uploaded another version.  I don't have plans to touch it again unless someone finds something wrong with it.

Happy father's day!

[John Dowson]

Thanks @Blake Buhlig!

[Grendel]

Thanks to you both but I'm still unable to get any lights to illuminate on my Bravo so I assume I've done something wrong. I've copied Blake's coding into a file named bravoleds.lua and placed this in the modules folder. FSUIPC recognises this and offers me the option of assigning a button or keypress to activate it but nothing happens when I do this. Is there anything either of you can suggest? As I say, I'm using FS2004 and FSUIPC 3.999z9b.

Many thanks.

 

[Blake Buhlig]

Maybe add a simple line like  ipc.log("Hello") at the beginning of bravoleds.lua then confirm "Hello" shows up in the log file?  That way you could at least know if it is running.

I'm running FS2020 and FSUIPC7. I'm unfamiliar with FS2004 or FSUIPC 3 so can't attest to whether the offsets my code uses would be compatible.

[John Dowson]

23 hours ago, Grendel said:

I've copied Blake's coding into a file named bravoleds.lua and placed this in the modules folder. FSUIPC recognises this and offers me the option of assigning a button or keypress to activate it but nothing happens when I do this. Is there anything either of you can suggest?

It is recognised but did you add it to the [Auto] section of your FSUIPC7.ini file so that it is automatically started? See the Advanced User Guide if you don't know how to do this.
I'm also not familiar with FSUIPC3 (and it is no longer supported!). You can add logging, and maybe check the offsets being used are compatible, as @Blake Buhlig suggests,

[Grendel]

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

,

My thanks again. The file is listed in the auto section but when it loads I see the following (or a variation, it's not always 341) in the FSUIPC log;

1402766 *** LUA Error: ...ram Files (x86)\Microsoft Games\Flight Simulator 9\MODULES\Bravoleds.lua:341: unexpected symbol near 'Â'
  1402984 *** LUA Error: ...ram Files (x86)\Microsoft Games\Flight Simulator 9\MODULES\Bravoleds.lua:341: unexpected symbol near 'Â'

Presumably this refers to line 341 in the lua file but there's nothing on that line that seems to correspond to the 'unexpected symbol' message.

Any suggestions would be welcomed, thank you.

 

[John Dowson]

3 minutes ago, Grendel said:

The file is listed in the auto section but when it loads I see the following (or a variation, it's not always 341) in the FSUIPC log;

1402766 *** LUA Error: ...ram Files (x86)\Microsoft Games\Flight Simulator 9\MODULES\Bravoleds.lua:341: unexpected symbol near 'Â'
  1402984 *** LUA Error: ...ram Files (x86)\Microsoft Games\Flight Simulator 9\MODULES\Bravoleds.lua:341: unexpected symbol near 'Â'

Presumably this refers to line 341 in the lua file but there's nothing on that line that seems to correspond to the 'unexpected symbol' message.

Sounds like some hidden characters have made its way into the script. Try downloading it again. or looking at the file in an editor that can show hidden characters/symbols (e.g. Notepad++) and remove them. 341 does refer to the line number. It is strange that it reports the error for multiple lines - maybe there are multiple hidden characters.
Line 341 is also just a comment - you could try just removing that line....

[Blake Buhlig]

I'm not sure how you are downloading it, but you could try https://raw.githubusercontent.com/bbuhlig/fsuipc-contrib/main/bravoleds.lua in a browser tab, then right-click "Save As..." to save it to a file.  That's the link that comes up when I press "Raw" on the https://github.com/bbuhlig/fsuipc-contrib/blob/main/bravoleds.lua screen.

 

[Grendel]

Thank you Blake, downloading it from the new link got it going and I now have the parking brake light and the master caution light working. However I still can't get the gear lights to illuminate.

On 6/19/2021 at 1:38 PM, John Dowson said:

I got the gear lights working by making the following changes:
   - Change the initialization of GearIsRetractable variable (line 211) to
        GearIsRetractable=ipc.readUB(OFFSET_IS_GEAR_RETRACTABLE);

John, I've been trying to use your solution (above) but this hasn't cracked it for me yet. The line I've tried changing is GearIsRetractable = SimVar(0x060C,"UB",true) which is shown in the file as line 237 rather than 211. Are you able to suggest what I might be doing wrong?

Thanks,

Gary

[John Dowson]

13 minutes ago, Grendel said:

John, I've been trying to use your solution (above) but this hasn't cracked it for me yet. The line I've tried changing is GearIsRetractable = SimVar(0x060C,"UB",true) which is shown in the file as line 237 rather than 211. Are you able to suggest what I might be doing wrong?

You don't need to make any changes any more as Blake has already updated the scripts so this is not necessary (and that is also why the line numbers have changed).

Check that offset 060C is populated correctly for the aircraft that you are using, i.e. shows 1 (for retractable). You can do this using the offset logging facilities (as UB).

 

[Blake Buhlig]

The function at line 303 should get called on any relevant state change, like moving the gear handle. You could uncomment the logging code at line 304 and monitor the log, to learn what the state variables are at those events.

[Grendel]

Thanks John, 060C shows 0 rather than 1. Is there a way I can correct this?

[Blake Buhlig]

2 minutes ago, Grendel said:

Thanks John, 060C shows 0 rather than 1. Is there a way I can correct this?

In the code, everywhere it says "GearIsRetractable:isTrue()" you could change to "true".  The downside is that you will get the LED behavior even on fixed gear aircraft.

Which drove me crazy on the initial version of this I came up with, hence I added that support. But is does require a functioning offset that reports the aircraft's gear type, looks unsupported in either that aircraft or that FSUIPC .

[John Dowson]

As well as what Blake has said, before you fo that, check that the gear control offset at 0BE8 is showing the correct value (again, by logging). If it is, you can do as Blake says, with the dowsides of this approach. If offset 0BE8 is not showing the correct gear position, you are out of luck.

[Grendel]

Thank you both. The gear control offset shows a value of 255 but I don't know whether this is correct or not.

Blake, could you kindly clarify... 

21 minutes ago, Blake Buhlig said:

In the code, everywhere it says "GearIsRetractable:isTrue()" you could change to "true".

Line 254 reads "...and GearHandleIsDown:isFalse() and GearIsRetractable:isTrue()))".

Should that be altered to read "and GearHandleIsDown:isFalse() and true()"? Also should I retain the two extra closed brackets at the end of the line? Similarly lines 304 and 305?

Sorry to keep troubling you both, it feels as if I'm very close so your help continues to be much appreciated.

[Blake Buhlig]

17 minutes ago, Grendel said:

Thank you both. The gear control offset shows a value of 255 but I don't know whether this is correct or not.

My code expects that offset to be non-zero when the gear handle is down, and zero when the gear handle is up.

 

19 minutes ago, Grendel said:

Line 254 reads "...and GearHandleIsDown:isFalse() and GearIsRetractable:isTrue()))".

Should that be altered to read "and GearHandleIsDown:isFalse() and true()"? Also should I retain the two extra closed brackets at the end of the line? Similarly lines 304 and 305?

I meant this.  If you want, you can just download that version from here.

[Grendel]

Thank you very much Blake, that's solved it for me.

Gary

[Grendel]

Blake, could I trouble you with one more question?

With the gear in transit I get flashing green gear lights which extinguish or turn solid as appropriate when the movement is completed. Ideally though the lights would be solid red whilst the gear in transit. I've tried making alterations to the section copied below but nothing I've tried results in solid green (down) solid red (transit) and lights off (up). Do you have any suggestions? Thanks.

if self._is_failed then
	       set_gear_led(self._led,GEARIND_RED,(not (self:isDown() and GearHandleIsDown:isTrue())))
      else
         if self:isUp() and GearHandleIsDown:isFalse() then
            set_gear_led(self._led,GEARIND_OFF)
         elseif SimIsOnGround:isFalse() or GearHandleIsDown:isTrue() then
            set_gear_led(self._led,GEARIND_GREEN,self:isInTrans())
         else -- why is the gear handle up when the sim is on the ground?
            set_gear_led(self._led,GEARIND_RED,true)
         end
      end
   else
      set_gear_led(self._led,GEARIND_OFF)

 

[Blake Buhlig]

There are lots of ways to do this probably. Have you tried something like 

 

if self:isUp() and GearHandleIsDown:isFalse() then

  set_gear_led(self._led,GEARIND_OFF)

elseif self:isDown() and GearHandleIsDown:isTrue() then

  set_gear_led(self._led,GEARIND_GREEN)

else

  set_gear_led(self._led,GEARIND_RED)

end

[Grendel]

That's wonderful, it worked straight away.

Thank you very much indeed.

Gary