GFDisplay Support Question

[Skittles]

Mr. Dowson,

Did I hear correctly... you're no longer supporting GFDisplay? Is there something else I can use?

Joe

[Pete Dowson]

Did I hear correctly... you're no longer supporting GFDisplay? Is there something else I can use?

Yes, the gfd ("GoFlight Devices") library in the Lua plug-in support, which is incorporated into FSUIPC3, 4 and WideClient. (Check for updates in Download Links subforum). In fact I've just added support for the new GF-WP6 unit, but I'm waiting for one to arrive so I can test it properly before publishing the updates for that officially.

The Lua plug-in method is more flexible and powerful, and, I think, easier to understand. I don't even understand any more much of what I did in GFdisplay myself! ;-)

Regards

Pete

[Skittles]

Do you offer Lua programming help?

If not can you recommend someone or something. I'm still browsing through the on-line User Manual.

I've looked through the example gfdDisplay.lua and GFpower.lua files and I think I'm getting the basics so far.

I understand the purpose of using event driven script, but as usual I gotta do things differently. I understand that any .lua files in the modules directory will show up in the drop down lists. Do I have to make a separate file for each control?

Using GFDisplay, I have my GF-46 displaying the AC Heading and Speed. I'm thinking I need a lua file to run constantly but I haven't figured out how to do that, I guess I have more reading to do.

Your suggestion to use events seems reasonable if I can figure out how to setup the functions, then it will "monitor" the mag heading offset and when it changes, call the function.

Thanks for everything,

Joe

[Pete Dowson]

Do you offer Lua programming help?

I can answer specific questions. You will also find lots of examples in the User Contributions subforum -- you might even find the very thing you are looking for. Also check out the package called "Linda" (see first message in this Forum).

You should find it much clearer and more straight-forward than the rather arcane parameters used by GFDisplay.

I understand the purpose of using event driven script, but as usual I gotta do things differently.

You wouldn't use events in any case for simple responses to assigned controls. Events are for things you want to happen on changes in FS, like lighting indicators when an offset changes. If you only want things to happen when you press keys or buttons or turn switches then straight Lua scripts are fine.

I understand that any .lua files in the modules directory will show up in the drop down lists.

Yes. In fact they'll each cause several entries -- Lua <name> to just run the script, LuaDebug <name> to run it with a trace log, and others to kill a looping Lua, send it a flag or a parameter.

Do I have to make a separate file for each control?

For button actions, if they are doing completely different functions then it is more efficient, yes, because they have to be loaded, compiled and executed each time you press the related button. However, if you have a group of related functions using similar or common Lua code, then the one larger Lua can be called, just with different parameter values supplied for different functions. Look at the examples by Guenseli in the User Contributions subforum for this sort of thing.

Using GFDisplay, I have my GF-46 displaying the AC Heading and Speed. I'm thinking I need a lua file to run constantly but I haven't figured out how to do that, I guess I have more reading to do.

A Lua using events will run continuously unless it executes an ipc.exit function call. Or you can simply have a never-ending loop -- but in that case always include an ipc.sleep call to stop it hogging resources. (e.g. sleep 50 msecs for a 20 per second update rate). Events are better because they use less resources, You can update displays from FS values by simply having an event which calls a function when a specific offset changes. The new value of the offset is provided to the function, so all it has to do is display it. Very compact too. It would look like this:

function updateXXX(offset, val)

gfd.setdisplay (.... ) --using val after formatting

end

event.offset(0x????, "type", "updateXXX")

In the one Lua you can have events for different offsets and functions to process each one. The Lua can either be loaded by naming it "ipcReady.lua", whichl oads when FS is ready to fly, or loaded BY the ipcReady.lua by using the ipc.runlua function. For continuously running Luas for specific aircraft they can be loaded automatically by adding them to [Auto....] sections in the FSUIPC INI file.

Your suggestion to use events seems reasonable if I can figure out how to setup the functions, then it will "monitor" the mag heading offset and when it changes, call the function.

Functions are just a line saying "function <name>(parameters)" and another saying "end", with Lua code in between. To simply update a display that might be only one line, or at most two if you need to do some computation on the value first.

Regards

Pete