Jump to content
The simFlight Network Forums

GoFlight modules


Recommended Posts

Sorry to ask , but someone said that "No questions are stupid"

If i want to use Lua scripts to operate my Goflight modules, should i remove the Goflight program and keep only the GFdev.dll in my module folder

or should i keep everything and just put the Lua files in the module folder.

Actually, even if i remove the GFdev.dll from the module folder i still have all my Modules assignments active in FSX,

i even tried to remove the Fsuipc.ini file from my module folder. and FSX rebuilded one with all my Module Assg. active.

Thank you !!

Tintinrad

Link to comment
Share on other sites

I answered a version of this in the proper place when it suddenly got deleted. Then I found it in the Announcements subforum for some reason! I've moved it here, the proper place (again).

If i want to use Lua scripts to operate my Goflight modules, should i remove the Goflight program and keep only the GFdev.dll in my module folder

or should i keep everything and just put the Lua files in the module folder.

If you are taking over all functions of all attached GF devices, yes, you only need GFDev.dll. If you want the GF software to handle some of the devices you'll need to retain it and somehow tell it not to interfere with the ones you are programming separately. The GF software unfortunately does not cooperate, and thinks it owns all indicators on a device, rather than reading their states and changing only those it needs to.

Don't delete anything else, only remove the GF device drivers.

Actually, even if i remove the GFdev.dll from the module folder i still have all my Modules assignments active in FSX

GFDev.DLL is used by FSUIPC, not by the GF drivers.

i even tried to remove the Fsuipc.ini file from my module folder. and FSX rebuilded one

It is FSUIPC which creates the FSUIPC INI file. Don't delete it, there's no reason.

Originally I thought you must be talking about With FSX all modules (DLLs) it uses, like FSUIPC4 and the GF drivers (EXE or DLL) are loaded by SimConnect from wherever they are installed, not from the Modules folder necessarily. To stop them loading you'd need to edit the EXE.XML and DLL.XML files, marking them disabled. Those files are in the same folder as your FSX.CFG file.

Regards

Pete

Link to comment
Share on other sites

Thank you Pete

Sorry for posting at the wrong place (My first post)

I get it , if i want to use ONLY Lua i need to keep Gfdev.dll in the module folder and Disable GoFlight from the EXE xml and all assig . in Goflight program, Right !!

Than you again

Tintinrad

Link to comment
Share on other sites

  • 3 weeks later...

I wanted to chime in to get a clarification. By removing "GF device drivers" do you mean the assignments made via the goflight app that allows individual key assignments? I've kept GFDev in the GoFlight folder (not Modules which shouldn't matter). I only want MCP driven by Goflight software, all others by me via LUA. I'm new to LUA, not so new to FSUIPC, degree in computer science, veteran programmer and trying to piece LUA together since last Sunday so bear with me! I'm wondering if GF is diddling with my coding related to this very topic or if I'm missing something because when I set a RP48 LED in one LUA module and then set a diff LED in another LUA, the first LED goes out but condition hasn't changed. Not trying to hijack, just explaining my tie into this thread's question... thx,dave

Link to comment
Share on other sites

I wanted to chime in to get a clarification. By removing "GF device drivers" do you mean the assignments made via the goflight app that allows individual key assignments?

No. Please read my earlier reply. If you are completely taking over the Goflight devices you only need GFDev.DLL. The other Goflight modules (DLLs) or EXEs aren't needed and will just confuse the issue and may stop your Lua programs or whatever working. But if you want to only do bits in Lua or just assign some switches via FSUIPC, then you'd need both.

I've kept GFDev in the GoFlight folder (not Modules which shouldn't matter).

It won't matter if the GFConfig install path in the Registry points correctly to the folder containing GFDev. You most certainly must never put a non-FS DLL into the FS9 modules folder or it will crash FS. Having GFDev.DLL in the modules folder only applies to FSX and later.

I only want MCP driven by Goflight software, all others by me via LUA.

Isn't the Goflight driver for the MCP separate from the other drivers? If so then you could keep that loading, of course, and just dispense with the others.

...because when I set a RP48 LED in one LUA module and then set a diff LED in another LUA, the first LED goes out but condition hasn't changed.

Depends how you are setting them in the Lua. Unlike GoFlight's software FSUIPC reads the state of the LEDs before changing only the ones you want changing. You'd need to elaborate.

Regards

Pete

Link to comment
Share on other sites

Pete,

Many thanks for the quick reply. I'll won't bog you down with a million Q's. I'm pretty good at digging this stuff out with minimal guidance and then I like to find the rest of answer with experimenting and running debugs like I used to get to do.

I'm using FSX. I'm not actually sure where the hook/connection for FSX-goflight-MCP-dll is made. I just understand FSX starts the bridge GFDevFSX.exe at FSX startup and the FSUIPC-Goflight bridge is GFDev.dll (correct me if I'm mistaken).

I have each LUA setting LEDs perfectly. They just don't stay on between LUAs like I said. My gap in understanding about LUA / GF LEDs may be that point when going from one LUA to another, each setting different LEDs, do I need to do something like gfd.GetValues to re-load state of all previous LEDs so that I can re-apply their on/off status along with the new/next LED state? If so, would I use gfd.SetLights with a masking of previous states? Sorry I'm dragging this whole damn thread off track but I'm really trying to put all this together here but I'm really excited about LUA and want to get it. thx,Dave

Edited by daveaust
Link to comment
Share on other sites

Pete, nevermind the gfd.GetValues question above. I re-read and see it only pulls input states, not display states. I'll have to dig around and see what I'm missing. Seems simple but something's amiss. I'll try it with some other aircraft than this iFly jet and also see what other 'things' I can change. I like the chase...

Link to comment
Share on other sites

I'm not actually sure where the hook/connection for FSX-goflight-MCP-dll is made. I just understand FSX starts the bridge GFDevFSX.exe at FSX startup and the FSUIPC-Goflight bridge is GFDev.dll (correct me if I'm mistaken).

I don't know anything about the GFDevFSX.exe part at all. That and GFDev.dll are not connected, and they don't use each other. As you understand correctly, FSUIPC just uses GFDev.dll for the button detection and the Lua gfd library. You can drive GF modules more directly, without GFDev.dll, via the HID provisions in the Lua com library too, but it shouldn't be necessary as GFDev.dll covers pretty much all you need to do.

I have each LUA setting LEDs perfectly. They just don't stay on between LUAs like I said. My gap in understanding about LUA / GF LEDs may be that point when going from one LUA to another, each setting different LEDs, do I need to do something like gfd.GetValues to re-load state of all previous LEDs so that I can re-apply their on/off status along with the new/next LED state?

No. The GetValues function only gets the state of switches and dials. It has nothing to do with displays and indicators.

The SetLight and ClearLight functions use GFDev.dll to read the LED states, perform an OR or an AND to set or clear the bit referred to by the "id" parameter and send it back. Assuming there's nothing else talking to the device then the only way that might be able to go wrong is if the other Lua thread got in between those two actions (I don't have it protected by a critical section enclosure), but as they are only a line of C code apart this is an extremely unlikely thing to happen.

I have several different GF modules here. Just testing running these two Lua programs one after the other:

gfd.SetLight(GFRP48,0,1)

[gfd.SetLight(GFRP48,0,2)

I end up with both LEDs 1 and 2 lit, as expected.

Maybe you'd better tell me which version of FSUIPC you are using (things do change and there have been bugs corrected over the years and months), and maybe show me your code. I am using FSUIPC 4.728b at present, but any recent version will be the same in this regard. Check the Download Links subforum.

Regards

Pete

Link to comment
Share on other sites

Pete, I am running FSUIPC version 4.728 and GFDev.dll properties details shows file ver 2.0.1.1 dated 6/23/11 (is this filestamp the actual version??). Also Windows 7 installation (64bit). Just D/L'd newest versions Monday when I first started getting suspicious I was doing something wrong.

I used three LUAs to perform two tests:

First test I simply execute what I'll call "LUA1" (GFLightOn1) and LUA2 (GFLightOn2) via simple button presses.

Second test executes LUA1 then LUA2 by way of ipc.runlua command from LUA3(GFCall-1). I use the sleeps to just give my eye time to see what I think I see. LED1 then 2 if 1 goes on then off.

Heres my code. As you can see there isn't much to it.

"LUA 1":

----------------------------------------------------

-- GFLightOn1

----------------------------------------------------

gfd.SetLight(GFRP48, 0, 1)

"LUA 2":

----------------------------------------------------

-- GFLightOn2

----------------------------------------------------

gfd.SetLight(GFRP48, 0, 2)

"LUA3":

----------------------------------------------------

-- GFCall-1

----------------------------------------------------

ipc.display("Starting GFCall1.lua",5)

ipc.sleep(2000)

ipc.runlua("GFLightOn1")

ipc.sleep(2000)

ipc.runlua("GFLightOn2")

Results are the same in all scenarios. LED1 comes on correctly, then LED2 comes on correctly, BUT simultaneously LED1 extinguishes and vice-versa. My other code with event.offsets of course is acting the same. I just tried this with default MS jet,PMDG, and iFly with same results.

Please tell me I have a glaring flaw in my syntax or something easy. I just feel like I'm doing something big and stupid here.

I may try to flip different LEDs within a single LUA and see if that makes a difference although I don't want to structure things that way.

thx again,dave

Link to comment
Share on other sites

Another bit:

This single LUA module simply sequences LEDs 1 thru 4 in succession, one at a time. No concurrency.

----------------------------------------------------

-- LUA GFLightOnAll

----------------------------------------------------

gfd.SetBright(GFRP48, 0, 15)

gfd.SetLight(GFRP48, 0, 1)

ipc.sleep(1000)

gfd.SetLight(GFRP48, 0, 2)

ipc.sleep(1000)

gfd.SetLight(GFRP48, 0, 3)

ipc.sleep(1000)

gfd.SetLight(GFRP48, 0, 4)

Also ran gfdDisplay.lua and the SetLights section with on/off bitmasking works fine lighting multiple LEDs concurrently.

Somewhat suspicious of my RP48 hardware but confused by the two scenarios setlight and setlights. I've examined my installation environment backwards and forwards. All seems in order from what I can tell.

Link to comment
Share on other sites

Another bit:

This single LUA module simply sequences LEDs 1 thru 4 in succession, one at a time. No concurrency.

All your examples, cut and pasted, work fine here.

Pete, I am running FSUIPC version 4.728 and GFDev.dll properties details shows file ver 2.0.1.1 dated 6/23/11 (is this filestamp the actual version??). Also Windows 7 installation (64bit). Just D/L'd newest versions Monday when I first started getting suspicious I was doing something wrong.

I'm using the latest GFDev.DLL I've seen -- 2.0.0.1. I tried to get 2.0.1.1 when someone else mentioned it, but GF don't seem to have updated their website for the SDK for a long long time. I'm not installing all of the other guff which I don't need or want. Maybe you should try 2.0.0.1 (it's available in the Download Links subforum here)? Let me know. If they've messed the later one up I shall write to the author about it.

Also ran gfdDisplay.lua and the SetLights section with on/off bitmasking works fine lighting multiple LEDs concurrently.

"SetLights" is called directly internally by both SetLight and ClearLight. It just makes the one-bit masks for you, that's all.

Regards

Pete

Link to comment
Share on other sites

Ok thanks. I'll try the previous gfdev module tonight when I get back. Interesting to know the setlight/setlights relationship. That will shed a little bit of light on the situation as I ponder and experiment, no pun intended...

I've talked to the GFDev.DLL author who says there's no difference in this regard between 2.0.0.1 and 2.0.1.1. He also sent me the latest Beta he has, before release, and that works too.

All I can suggest is that, yes, you try 2.0.0.1, but also double check you are actually using FSUIPC 4.728 -- check the FSUIPC4.LOG and see that it confirms that in its first line.

If you still can't resolve it, and you definitely have no other programs interfering with the RP48, it is suggesting a hardware problem. But what a weird one!

Pete

Link to comment
Share on other sites

Pete, I've picked a few more clues and the smoking gun points to the hardware. I did go back to 2.0.0.1 GFDev.dll (and confirmed FSUIPC 4.728 in FSUIPC.ini) with same results and pondered the next step. My GF-46 acts normally although it only has alphaNum displays so comparisons are limited. I finally came up with the idea of treating the LEDs on my MCP-PRO just as was on the RP48. I should have done that a few days ago but didn't think of it at the time. Anyway, it works just as it should, lighting each successive LED 0->4 leaving the previous LED on. SO we were correct in that the installation was correct and there could be no other way the software could really be getting sidetracked leaving most likely a hardware or firmware issue of some kind. I like goflight but I'm not convinced that the QC is flawless like anything electrical/mechanical on this planet, anything can be flakey. Especially since it for the most part, the thing works. I'm going to try to rathole out the firmware version which someone has mentioned doing on the GF forums and see if it is way old. I'll also pop the face plate and look for any cold joints on the resistor arrays or big chips just in case it's something obvious that just effects something minor like this issue(warranty is over!). I've actually found many weird esoteric problems over the years this way. Anyway, I'm getting off track and thx for the help in reassuring me I was at least doing the basics correctly as I am getting off the ground with LUA. I'll go forward from here and update down the road just for the record. It really is an interesting issue but I actually like chasing these strange kinds of problems... many thanks for your time and expertise,dave

Link to comment
Share on other sites

Pete, I've picked a few more clues and the smoking gun points to the hardware.

Okay, thanks. I'll tell the GFDev software guy he's off the hook! ;-)

Good luck with the hardware -- but it might be worth checking with GF support as I think they have (or at least had -- new management now) a good reputation for faulty good repair/replacement, and may help even with an expired warranty -- depending how expired I suppose.

Regards

Pete

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.