daveaust

You deserve the compensation. If it wasn't for you all flight sim'ing would be much less interesting.

I have paid fsuipc4. Need fsuipc5 for P3Dv4. Do I need to completely re-purchase? If so, any discount for previous patrons?? dave austerman

Thanks Paul, that answers my question and makes total sense. I was stuck on the premise that the guid would change sometimes which sounded like it would spoil my little fsuipc party. I have made sure to label and keep all usb plugs going to the exact same plugs on my hubs. I am collecting a bunch these days building my NG cockpit. I do know that on my SIOC devices they will change up on different ports so this is much nicer. Maybe they can start using guid entries someday...

If I'm an idiot just tell me. I know you guys can straighten me out in mere moments. I have been reading the fsuipc manual and numerous posts regarding letter assignment and "dynamic adjustment." 1. Windows assigns a guid to a physical(or virtual) joy device 2. Fsuipc picks this entity up and a number is associated with the guid, 0-x 3. Auto assign associates a letter with the device by using the unique guid of that device 4. The lettering/guid scheme stays constant and present in the .ini as a device is unplugged and replugged retaining guid regardless of number assignment that shows back up in the .ini file (is this true?) 5. all letter references in subsequent usage stay intact for that device This all makes sense. I love it. It's great and wonderful. I haven't experimented like I need to because am in between functioning cockpit status. My confusion is simply that I also understand that when a device "X" is unplugged and reconnected to a DIFFERENT physical port on a hub or machine, the guid can or will change for joy device "X". So if you have a guid that changes, doesn't that then destroy the guid link from number to letter association in fsuipc.ini? I am missing something here about windows or fsuipc behavior. Thanks, Dave

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

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...

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.

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

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...

FYI I have been using the gfd.SetLight/ClearLight commands for on/off sets...

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

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