Need some help with GFDisplay

[Jackson5]

Hello everyone,

Can someone help me with this?

I want to light up one of the LED's on a GF-T8 panel when I turn on the Smoking sign. I now do that with FSUIPC buttons & Switches via PM RJ glass cockpit offset x04f4, parameter x000001A5 (22). When I flip the switch, the sign goes on, but of course the led on the GF-T8 stays off.

So I found Pete's program GFDisplay, and must have read the pdf manual about ten times now, but I still don't understand how to do it.

Can you help me with the above example (I want to do more buttons, but once I have a clear example I'll figure it out)?

-What needs to be in the GFDisplay ini

-Once its there, do I only have to run GFDisplay, or do adjustments need to be made to FSUIPC too?

Sorry for being so dumb to not figure it out myself...

BR

Jaap

[Pete Dowson]

I want to light up one of the LED's on a GF-T8 panel when I turn on the Smoking sign. I now do that with FSUIPC buttons & Switches via PM RJ glass cockpit offset x04f4, parameter x000001A5 (22). When I flip the switch, the sign goes on, but of course the led on the GF-T8 stays off.

Is your T8 on the same PC as FS? If so it would be easier with a Lua plug-in. since implementing GoFlight display support in the Lua libraries I'm not really wanting to support GFDisplay much. It's parameter files are pretty difficult compared to the nice easy flexible Lua system.

Regards

Pete

[Jackson5]

Yes, it is on the same PC as FS.

What about this LUA? How does this work and what do I need to use it? It seems even more difficult than GFDisplay to me.

I have visited the LUA site and downloaded LUA 5.1.4., but if I understand it right I do not need this ? I couldn't even figure out how to install it.....

Also I looked at your zipfile LuaPlugins with examples, it looks a little like the Opencockpits language, that btw. also goes way over my head if I would have to write that without the config_Sioc program.

Can you point me in the right direction?

Thanks,

Jaap

[Pete Dowson]

What about this LUA? How does this work and what do I need to use it? It seems even more difficult than GFDisplay to me.

Have you looked at the documentation I supply and the GoFlight examples? Have you bothered to try the GF display test Lua plug-in I supply?

I have visited the LUA site and downloaded LUA 5.1.4., but if I understand it right I do not need this ? I couldn't even figure out how to install it.....

DON'T install anything!!! Everything you need is built into FSUIPC! The only thing you might want to visit the website for is to read the manual on the Lua language, but for the very simple things you want to do this is really not necessary. The examples in your FSUIPC package should easily be enough.

I don't understand why you ignore everything supp;lied with FSUIPC and already installed into your system and go off half-cocked. Can you tell me how you decided to do such a thing please? Lua details have been supplied and installed with FSUIPC for well over a year now and no one else has done this! Have you read nothing I've done? :-(

Can you point me in the right direction?

Look at the GoFlight examples, try the GF display test.

To light one LED on a T8 would be one line. To read one offset would be one line. The whole thing might be 4 or 5 lines. I can help, but not if you don't even try. It is MUCH simpler than GFDisplay, and much more flexible too. But if you prefer GFDisplay, I wonder how you gauge complexity -- evidently oppositely to me!

Pete

[Jackson5]

Have you looked at the documentation I supply and the GoFlight examples? Have you bothered to try the GF display test Lua plug-in I supply?

I did now.....

DON'T install anything!!! Everything you need is built into FSUIPC! The only thing you might want to visit the website for is to read the manual on the Lua language, but for the very simple things you want to do this is really not necessary. The examples in your FSUIPC package should easily be enough.

Don't install. Clear!

I don't understand why you ignore everything supp;lied with FSUIPC and already installed into your system and go off half-cocked. Can you tell me how you decided to do such a thing please? Lua details have been supplied and installed with FSUIPC for well over a year now and no one else has done this! Have you read nothing I've done? :-(

I am sorry I never really bothered to read any of the supplied documentation, but I did not have the need to because I always used FSUIPC in the simplest way, by using the buttons and axes programming from the modules menu, also because some programs I use require it (although unregistered) and that's about it.

That way always worked fine for me, until I wanted to do something with my GF modules that was not possible from within the FSUIPC menu. That is why I first came upon GFDisplay. Furthermore I have been using an older verion of FSUIPC, and never felt the need to upgrade because it worked fine. Until everything crashed and I decided to get all new versions for all my software.

I am sorry if I have offended you.

Look at the GoFlight examples, try the GF display test.To light one LED on a T8 would be one line. To read one offset would be one line. The whole thing might be 4 or 5 lines. I can help, but not if you don't even try. It is MUCH simpler than GFDisplay, and much more flexible too. But if you prefer GFDisplay, I wonder how you gauge complexity -- evidently oppositely to me!

I do not specifically prefer GFDisplay, but simply did not know of lua programming. At first I thought this was for FSX only...

I've been at it most part of the day and tried the GFDisplay.lua. This lights up all my Modules in different ways. I also tried GFPower, because that interests me to get a real cold and dark cockpit, but this crashed my Flightsim completely about one minute after turning on the power and avionics.

So I tried to start simple by trying to light up all the leds on one of my modules. From the LUA GFD library reference I took gfd.setlights and came up with this:

gfd.setlights=GFT8, 1, on and saved that as GFLEDTEST with extension lua. Copied it to the modules folder and started flightsim. Assigned a button for lua GFLEDTEST and lua kill GFLEDTEST. Pushed the assigned first button, but nothing happened.

Tried several combinations, and checked the FSUIPC log in between. I had some entry's like: ' "=" expected near GFT8', and 'malformed number near on' while trying, but with the line as above there are no failure entry's, but I did not succeed in lighting anything either.

Obviously I doing something wrong, and I'm almost afraid to ask, but what?

I have also tried this:

if ipc.readUD(0x04F4)==1

then

gfd.SetLight=GFT8, 1, 2

else

gfd.clearlight=GFT8, 1, 2

end

But this did not work, as you would probably see immediately. (I wish I would..)

Regards,

Jaap

[Pete Dowson]

I've been at it most part of the day and tried the GFDisplay.lua. This lights up all my Modules in different ways.

It's only a test program, sent to all my GoFlight Beta testers to make sure all the displays GF offer can be handled. At the time I had no GF devices with displays. I only have a GF-46 now.

However, if you look at the Lua code inside you'll see the lines which send stuff to the display. That's why I quoted it as an example.

I also tried GFPower, because that interests me to get a real cold and dark cockpit, but this crashed my Flightsim completely about one minute after turning on the power and avionics.

One minute? No idea what it could be doing then. It will only do things when something changes (battery on/off, avionics on/off, or electrical failure,

Can you tell me, please, what version of FSUIPC you are using (i.e. the version number)? Because the only time I've ever known any Lua program to crash FS was when one is repeatedly called faster than it can be executed. That bug was fixed a few versions ago. If you aren't using the latest (see the Announcements above for details), please update.

So I tried to start simple by trying to light up all the leds on one of my modules. From the LUA GFD library reference I took gfd.setlights and came up with this:

gfd.setlights=GFT8, 1, on

Where did you get that syntax from? Are you looking in the examples or in the documentation at all? It should of course be in the form:

gfd.SetLights(model, unit, on, off)

exactly as shown in the document called "FSUIPC Lua Library". Please do refer to that. This command can set and clear all 8 lights at the same time, so it is probably not the one you want. To change only one light you'd use

gfd.SetLight(model, unit, id)

Even well-practised programmers have to refer to documentation. There's no point ever in guessing what to write! ;-)

Tried several combinations, and checked the FSUIPC log in between. I had some entry's like: ' "=" expected near GFT8', and 'malformed number near on' while trying, but with the line as above there are no failure entry's, but I did not succeed in lighting anything either.

The form "x = y" is an assignment. It assigns the value y to the variable x. The line "gfd.setlights=GFT8, 1, on" merely changes the gfd.setlights function to be, instead, a variable with value "GFT8". The other two values, 1 and on, are discarded as you provided no other variables for them to be assigned to.

I have also tried this:

if ipc.readUD(0x04F4)==1

then

gfd.SetLight=GFT8, 1, 2

else

gfd.clearlight=GFT8, 1, 2

end

Apart from the fact that you are assigning values to what was a function before you messed it up, instead of calling the function, you should note, if you refer to Project Magenta's documentation, that offset 04F4 does NOT contain "1" for any seat belt or other such value. 04F4 is where PM commands are WRITTEN -- writing 1 sets MAP mode on the ND. And, yes, I had to refer to PM's documentation for that -- why don't you please look these things up yourself? I never remember any of these offsets, and for PM I have to go to their website to check.

Also it says 04F4 is 2 bytes, which being 2 x 8 = 16 bits, makes it a Word (W) not a DWORD which is 4 bytes. Your read would read 04F4 and 04F6 together.

04F4 doesn't tell YOU anything about PM, it is used ONLY to tell PM to do things. There's no point in reading it at all. It's "write only".

I just did a search through the PM offsets (on their website) for seat belts and found this:

[b]04FE [/b]  2   PFD Various ([b]Read Only[/b])

Bit 0 Windshear
1 Below G/S
2 Caution
3 Warning
6 Eight Mode ND Active
[b]7 Seatbelt Sign[/b]
8 No Smoking Sign
9 Weather Radar (Captain)
10 EGPWS/Terrain (Captain)
11 TCAS Active (Captain)

13 TCAS WARNING
14 TCAS ALERT

So if you are testing it you'd need the read the WORD at 04FE and test it for bit 2^7 (value 128).

The whole Lua program for monitoring that offset and changing the seat belt and no smoking lights would be:

function operatelights(off, val)
    if logic.And(val, 128) then  -- 128 = 2^7, bit 7 = seat belts
       gfd.SetLight(GFT8, 1, 2)
    else
       gfd.ClearLight(GFT8, 1, 2)
    end

    if logic.And(val, 256) then   -- 256 = 2^8, bit 8 = no smoking
       gfd.SetLight(GFT8, 1, 3)  -- assuming light 3 is your non smoking switch light
    else
       gfd.ClearLight(GFT8, 1, 3)
    end

  -- you could add tests for more bits in 04FE here
end

event.offset(0x04FE, "UW", "operatelighhts")

I've assumed you really do mean GFT8 unit 1? If you have two the first will be 0, the second 1 and so on.

This Lua plug-in, unlike one which you call when pressing a key or button, simply sits and waits in the background for the offset to change. Save it as, say, "myt8.lua", then create an "ipcReady.lua" program (which will automatically run when FS is ready to fly) with only this line in it:

ipc.macro("Lua myt8")

which will run the T8 lights program for you.

If you want to do more "event" driven programs, with different offsets, just run these from the same ipcReady.lua file.

Regards

Pete

P.S. I can't test that Lua program here for you, but if you do get any errors logged they should either be obvious, or ask. Note I'm away on holiday from this Thursday for a week or so.

[Jackson5]

It's only a test program, sent to all my GoFlight Beta testers to make sure all the displays GF offer can be handled. At the time I had no GF devices with displays. I only have a GF-46 now.

However, if you look at the Lua code inside you'll see the lines which send stuff to the display. That's why I quoted it as an example.

I understood that, and it was nice to see the test procedure go by. And I did take a look at the lines, but that did not really clear things up for me....

One minute? No idea what it could be doing then. It will only do things when something changes (battery on/off, avionics on/off, or electrical failure,

Can you tell me, please, what version of FSUIPC you are using (i.e. the version number)? Because the only time I've ever known any Lua program to crash FS was when one is repeatedly called faster than it can be executed. That bug was fixed a few versions ago. If you aren't using the latest (see the Announcements above for details), please update.

I use FSUIPC version 3.982. What I did was assign a temporary free button to start the lua program, turned everything off (batt, avionics etc), started the lua and turned on the batt. switch (GFT8). My PM displays went on, so did my GF-MCP (at low brightness as defined in the lua). Then I switched the avionics on (GFT8) and saw my GF-LGT light up, the brightness on the MCP went up and the avionics on PMRJ went on too. That was cool! Next I did nothing anymore, just watched my instruments. After a little while FS crashed, the screen turned black and FS came with an "FS encountered an error and needs to be restarted" or something like that.

Where did you get that syntax from? Are you looking in the examples or in the documentation at all? It should of course be in the form:

gfd.SetLights(model, unit, on, off)

exactly as shown in the document called "FSUIPC Lua Library". Please do refer to that. This command can set and clear all 8 lights at the same time, so it is probably not the one you want. To change only one light you'd use

gfd.SetLight(model, unit, id)

Even well-practised programmers have to refer to documentation. There's no point ever in guessing what to write! ;-)

I thought the () were to indicate that something has to be filled in there, and leave out the () afterwards. Wrongly interpreted! I have a very hard time trying to understand this all, numbers, equasions and all that stuff doesn't get through to me. I just now figured out how to get a value from an offset from your explanation about x04FE : 2^7 means 2x2x2x2x2x2x2

It's clear that for doing these things, documentation is needed, and I have it all printed out and laying next to me. All FSUIPC offsets, including the PM ones, the LUA library references, FSUIPC docs, etc. But for me it's hard to get, that's the way it is, and also English is not my native language, so every once in a while I might translate some things in the wrong way. :oops:

Apart from the fact that you are assigning values to what was a function before you messed it up, instead of calling the function, you should note, if you refer to Project Magenta's documentation, that offset 04F4 does NOT contain "1" for any seat belt or other such value. 04F4 is where PM commands are WRITTEN -- writing 1 sets MAP mode on the ND. And, yes, I had to refer to PM's documentation for that -- why don't you please look these things up yourself? I never remember any of these offsets, and for PM I have to go to their website to check.

Also it says 04F4 is 2 bytes, which being 2 x 8 = 16 bits, makes it a Word (W) not a DWORD which is 4 bytes. Your read would read 04F4 and 04F6 together.

04F4 doesn't tell YOU anything about PM, it is used ONLY to tell PM to do things. There's no point in reading it at all. It's "write only".

Correct, it should have been 22 instead of 1. I see now that I took the wrong offset, had to turn a page for that, because the descriptions of offset 04f4 were on the page before all the functions that I had laying open.

It indeed says Glass Cockpit ND modes(write only)(*was* read ass well) :oops: So its offset x04fE that I must use.

I've assumed you really do mean GFT8 unit 1? If you have two the first will be 0, the second 1 and so on.

This Lua plug-in, unlike one which you call when pressing a key or button, simply sits and waits in the background for the offset to change. Save it as, say, "myt8.lua", then create an "ipcReady.lua" program (which will automatically run when FS is ready to fly) with only this line in it:

ipc.macro("Lua myt8")

which will run the T8 lights program for you.

If you want to do more "event" driven programs, with different offsets, just run these from the same ipcReady.lua file.

Your assumption was correct, I found out that GF numbers the modules from 1 and on. Also switch 3 was correctly assumed, only the other way around: switch 2 is smoking signs, and 3 Seatbelt signs. Also I understand the bit about the ipc.macro.

I have tested the lua as you put it here, and it worked, but with a few strange effects: when I flip either switch (smoking or belts), both lights come on, and they never go off, until I flip another switch on the same panel (battery as example). I remembered reading somewhere that GoFlight is very picky about handling functions on modules that have both Gofllight and FSUIPC actions programmed. As this is the case with this particular Module, I moved the buttons and lights to a module that is not used by Goflight and now the lua looks like this:

function operatelights(off, val)

    if logic.And(val, 256) then   -- 256 = 2^8, bit 8 = no smoking
       gfd.SetLight(GFP8, 2, 2)  -- Smoking Led
    else
       gfd.ClearLight(GFP8, 2, 2)
    end

    if logic.And(val, 128) then  -- 128 = 2^7, bit 7 = seat belts
       gfd.SetLight(GFP8, 2, 3)  -- Seatbelt Led
    else
       gfd.ClearLight(GFP8, 2, 3)
    end

  -- you could add tests for more bits in 04FE here
end

event.offset(0x04FE, "UW", "operatelights")

But whenever I press either button both lights come on, and now because there is no GoFlight programmed button on that module, they never go off until I shut down FS. Nothing I know can make me figure out where this goes wrong.

To get the "no smoking" sign on I use FSUIPC tab buttons & Switches: PM GC keys (byParam) param.22. This turns on the sign in both PMRJ displays

But either way I try it, the leds on the GF panel both go on, and stay on still.....

So close, but still no cigar......

I'll keep staring and trying.

Thanks so far.

Regards, Jaap

[Pete Dowson]

I understood that, and it was nice to see the test procedure go by. And I did take a look at the lines, but that did not really clear things up for me....

No, it isn't the best one as an example. I really meant scan through the GF exapmles provided.

By now I'd hoped to have produced a really good, well commented example, for something like the GF-MCP Pro. But I need the device to do that. GoFlight promised to send me one -- in January -- and it hasn't arrived yet! (I'll remind them when I get back from holiday).

I use FSUIPC version 3.982.

Hmmm. Shouldn't have crashed then.

What I did was assign a temporary free button to start the lua program, turned everything off (batt, avionics etc), started the lua and turned on the batt. switch (GFT8).

You started "GFPower" more than once? Ouch. Whilst it shouldn't crash FS (I'll test that), it isn't the thing to do. GFPower should be run once, at the start of FS (load it via a macro call in ipcReady.lua). It sits there watching various events.

One of the events is a change in battery voltage, which, once you switch things on, will be changing all the time. I'm wondering if that would do it, especially if you are running the thing more than once. I'll have to do some tests on that -- when I come back from holiday.

Note also that the GFdisplay plug-in does NOT terminate. You need to kill it, or reload FS. It sits there monitoring GF buttons and knobs.

FS came with an "FS encountered an error and needs to be restarted" or something like that.

If it happens again, please see if you can get more details. The module name and address or offset would be useful.

Correct, it should have been 22 instead of 1. I see now that I took the wrong offset, had to turn a page for that, because the descriptions of offset 04f4 were on the page before all the functions that I had laying open.

For offset references I find a printed copy rather difficult to use. Keep a copy in your Documents folder. Then you can get it up on screen and use Search. That's how I found 04FE, by searching for "Seat".

I have tested the lua as you put it here, and it worked, but with a few strange effects: when I flip either switch (smoking or belts), both lights come on, and they never go off, until I flip another switch on the same panel (battery as example).

Odd.

I moved the buttons and lights to a module that is not used by Goflight and now the lua looks like this:

That looks right.

But whenever I press either button both lights come on, and now because there is no GoFlight programmed button on that module, they never go off until I shut down FS. Nothing I know can make me figure out where this goes wrong.

THat sounds very familiar. I'm sure it was a bug found and, I thought, killed. I'll have another look. Don't change anything else yet.

To get the "no smoking" sign on I use FSUIPC tab buttons & Switches: Offset Dword setbits with Offset x04f4 and value 22 wich becomes x000001a5.

But 04F4 doesn't operate in "bits", it uses numerical values. You should be using Offset word set. Setbits OR's in the bits in the parameter into whatever was there before. That only works if there was zero bits set before.

Only use "setbits", "clearbits" and "togglebits" with offsets which have different bits assigned for different things, not when there's a numerical value to be written instead.

After I read your explanation about Words and Dwords I realized that this might be wrong too, because x04f4 is a Word instead of a Dword, right?

Yes.

Anyway either way I try it, the leds on the GF panel both go on, and stay on still.....

That might be me. I'm checking now ...

[LATER]

Stupid me! I should take my own advice and look things up! I use the C language everyday, almost constantly, and I am so used to the way it works that the differences in Lua sometimes escape me for a while.

The problem is that in C anything non-zero is "true" and zero is false. But in Lua everything except "false" is "true"! Statements like:

logic.And(val, 256)

return a number: 0 if the bit isn't set, and 256 if it is. It logically ANDs the two values. So I need to test for them being non-zero, that's all.

Sorry! Here's the correct code:

    function operatelights(off, val)

        if logic.And(val, 256) ~= 0 then   -- 256 = 2^8, bit 8 = no smoking
           gfd.SetLight(GFP8, 2, 2)  -- Smoking Led
        else
           gfd.ClearLight(GFP8, 2, 2)
        end

        if logic.And(val, 128) ~= 0 then  -- 128 = 2^7, bit 7 = seat belts
           gfd.SetLight(GFP8, 2, 3)  -- Seatbelt Led
        else
           gfd.ClearLight(GFP8, 2, 3)
        end

      -- you could add tests for more bits in 04FE here
    end

    event.offset(0x04FE, "UW", "operatelights")

It was doubly disconcerting because the symptoms were almost identical to a bug I thought I'd fixed months ago.

Regards

Pete

[Jackson5]

No, it isn't the best one as an example. I really meant scan through the GF exapmles provided.

By now I'd hoped to have produced a really good, well commented example, for something like the GF-MCP Pro. But I need the device to do that. GoFlight promised to send me one -- in January -- and it hasn't arrived yet! (I'll remind them when I get back from holiday).

I tried a couple of them and scanned the lines. Some things I do see, but other things are a complete blur at this time. I guess I have to grow and learn.

Goflight seems to let more people down lately, I guess setting up their new website gave them more problems then expected.....

You started "GFPower" more than once? Ouch. Whilst it shouldn't crash FS (I'll test that), it isn't the thing to do. GFPower should be run once, at the start of FS (load it via a macro call in ipcReady.lua). It sits there watching various events.

One of the events is a change in battery voltage, which, once you switch things on, will be changing all the time. I'm wondering if that would do it, especially if you are running the thing more than once. I'll have to do some tests on that -- when I come back from holiday.

Note also that the GFdisplay plug-in does NOT terminate. You need to kill it, or reload FS. It sits there monitoring GF buttons and knobs.

I think I did not start GFPower more than once, only after I had assigned a button to start the lua, and reset FS I started the lua. But as I understand correctly, it should be started together with FS via ipc.Ready.lua only? Then I will try that again, because it is a very interesting lua to me!

If it happens again, please see if you can get more details. The module name and address or offset would be useful.

I will

For offset references I find a printed copy rather difficult to use. Keep a copy in your Documents folder. Then you can get it up on screen and use Search. That's how I found 04FE, by searching for "Seat".

True, but my FS setup is for FS only, and all the other things I do are on a small laptop, so working with more programs at the same time can get a bit messy then, opposed to working on a three bigscreen machine (my FS PC)

But 04F4 doesn't operate in "bits", it uses numerical values. You should be using Offset word set. Setbits OR's in the bits in the parameter into whatever was there before. That only works if there was zero bits set before.

Only use "setbits", "clearbits" and "togglebits" with offsets which have different bits assigned for different things, not when there's a numerical value to be written instead.

Ok, I wll try to understand that. In the mean time I changed it and edited my post immediately, but at the same time you were probably already answering it (wow, fast!) This time I use PM GC Keys(by Param) with parameter 22 and 23, and that works correct. Now I understand why whenever I was using the No Smoking or Seatbelts button, some glitch alwas happened on my GC displays (little jump but no noticable difference)

[LATER]

Stupid me! I should take my own advice and look things up! I use the C language everyday, almost constantly, and I am so used to the way it works that the differences in Lua sometimes escape me for a while.

The problem is that in C anything non-zero is "true" and zero is false. But in Lua everything except "false" is "true"! Statements like:

logic.And(val, 256)

return a number: 0 if the bit isn't set, and 256 if it is. It logically ANDs the two values. So I need to test for them being non-zero, that's all.

Wow, you got me there. I think I have to read that 10 times before I even begin to comprihend... :oops:

Sorry! Here's the correct code:

    function operatelights(off, val)

        if logic.And(val, 256) ~= 0 then   -- 256 = 2^8, bit 8 = no smoking
           gfd.SetLight(GFP8, 2, 2)  -- Smoking Led
        else
           gfd.ClearLight(GFP8, 2, 2)
        end

        if logic.And(val, 128) ~= 0 then  -- 128 = 2^7, bit 7 = seat belts
           gfd.SetLight(GFP8, 2, 3)  -- Seatbelt Led
        else
           gfd.ClearLight(GFP8, 2, 3)
        end

      -- you could add tests for more bits in 04FE here
    end

    event.offset(0x04FE, "UW", "operatelights")

It was doubly disconcerting because the symptoms were almost identical to a bug I thought I'd fixed months ago.

From my part you are now hearing a big sigh from relief! IT WORKS !!!! Boy am I glad with that, thank you so much.

I have now moved it back to the previous GFT8 panel that is combined with a couple of GF functions. The GF functions on that panel are : Batt switch, Avionics switch, Engine 1 run switch and Engine 2 run switch. The FSUIPC programmed buttons are: No smoking sign, seatbelt sign, Generator 1, Generator 2.

Of course GoFlight messes things up when I flip a GoFlight switch but that is a GoFlight issue, and when I have rearranged my Panels I will keep the FSUIPC programmed buttons on one panel, separated from the GoFlight programmed buttons.

For now I can build on your lua to also get the generator switches to light up!

Great, thanks again!

Regards,

Jaap

[Jackson5]

With the help of your lua file, I was able to make the programming for the generator switches, and as an extra the Altim Metric button:

function Generator2(off, val)

        if logic.And(val, 1) ~= 0 then 
           gfd.SetLight(GFT8, 0, 5) --Gen2 led
        else
           gfd.ClearLight(GFT8, 0, 5)
        end
    end

function Generator1(off, val)

        if logic.And(val, 1) ~= 0 then
           gfd.SetLight(GFT8, 0, 4)  --Gen1 led
        else
           gfd.ClearLight(GFT8, 0, 4)
        end
    end

function MetricDisplay(off,val)

        if logic.And(val,16) ~=0 then -- value 2x2x2x2
           gfd.SetLight(GFP8, 2, 5)  --Metric led
        else
           gfd.ClearLight(GFP8, 2, 5)
        end
    end

    event.offset(0x3AB8, "UD", "Generator2") -- Gen2
    event.offset(0x3B78, "UD", "Generator1") -- Gen1
    event.offset(0x051C, "UW", "MetricDisplay") --Shows metric values in the GC

Had some trouble because the offsets for the generators are 32 bit size 2, but with trial and error I got it. It works perfectly, and I even found that when I happen to flip a GoFlight programmed switch and thus the lua programmed lights go of, that after a minute or so doing nothing, the lights come on again. Not really as it should be, but for now I can live with that !

Next I wil try to merge your lua with mine, to make things more simple, or do you recommend to keep them apart?

BR

Jaap

[Pete Dowson]

Next I wil try to merge your lua with mine, to make things more simple, or do you recommend to keep them apart?

It isn't really important. Yes, merging them would be efficient -- unless the assorted offsets you are handling are likely to be all changing often and at once, in which case separate files would probably be more efficient. But I don't think that's the case.

Regards

Pete

[Jackson5]

I have merged the two files now, without problems. I am glad it all works now.

Thanks for your help and all your Patience.

Have a nice Vacation.

Best Regards,

Jaap