oskrypuch

That is a negative -- to "Using...GFDEV64.DLL" in the LOG file. Had a look, and indeed that DLL is not in the modules directory. I could have sworn I had put it there. Found it eventually in the GoFlight directory, so it got dumped into the wrong spot. All working now. Thanks for helping out. * Orest

Is there anyone that has been successful in making definitions in FSUIPC, of GoFlight buttons, running in P3D v4? * Orest

I have been reading this thread with interest. My problem is that no simple buttons and switches from Go-Flight modules are recognized in registered FSUIPC in P3D v4.1. Everything worked fine in P3D v3.4. Buttons are correctly recognized by FSUIPC from Saitek yoke and pedals and quadrant. I purchased and installed FSUIPC v5.121b. Everything else seems to be working. I installed the latest GFConfig as referenced above. Curiously there is NO v4 tab, just one P3D tab. I changed the directory to the new v4 install. The GoFlight bridge DLL is in the P3D v4 dll.xml file. But, there was no GFdev64.dll anywhere. I downloaded that file from the link above, and put it in the P3D v4 modules directory, along with the FSUIPC files. Still, makes no difference. Buttons are not recognized in the FSUIPC buttons assignments page, for GoFlight Modules. What am I doing wrong? * Orest

Isn't it great!! I'm delighted myself too. It just took a bit of persistence & thought, and a lot of head scratching. * Orest

Couldn't wait until tonight, checked at lunch. DELETED the modules\DLL directory, with the copied in 430W simulator files (the alternate solution) The 430W files had already been deleted from the .EXE directory (the initial solution) INSTALLED the new FSUIPC DLL (4812b) Started up FSX, no error messages, no "files not found" message. Selected an aircraft with the 430W installed, all worked as it should. This has finally been put to rest! * Orest

Outstanding Pete. A very satisfying end to a bit of a head scratcher. Will test that tonight, and report. * Orest

tick, tick, tick ... YES, #2 works as well. Erased all those moved files from the RXPGN1AE.exe (c:\Users\yourname\AppData\Local\Reality XP\RXPGnsSim\) directory and then moved all the contents of the original trainer directory (C:\Garmin\GNS400W\Trainer\*.*), instead to that new modules\DLL directory. Works just fine indeed! EXCELLENT!! The villagers are singing and dancing in the streets! * Orest

Yes, a real A-HA moment for sure! Sweet when you hit it. For me #1 works, will try #2 as well, as it is a little cleaner. * Orest

Bummer. What were you experiencing before? Does your default bootup aircraft, have any RXP modules installed? * Orest

I'm still not sure what is triggering this, and what role the two different versions of FSUIPC are playing. This error has been triggered by other issues as well (totally unrelated to FSUIPC), from my google searches. It may be some sort of timing change during initial load, with different programs or different versions of programs running, who knows. I am going to have a good look at the RXP registry entries, and see if cleaning all those out and reinstalling it might also fix this. Kind of hard to link swapping in a different version of a different program (FSUIPC in this instance) as somehow affecting this lookup. We will probably never know the mechanism. What is clear, is that this is not a single one-off issue, as a number of folks have been affected. The good side, is that all my RXP stuff is back now, and that anyone else that is similarly affected, are also likely to be able to get their setup fixed up as well. * Orest

FIXED! See this thread ... http://forum.simflig...e-to-fsuipc-48/ * Orest

FIXED!!! The cdp_annun_box_sim.dll that "can't be found", is part of the Garmin trainer software, that RXP in turn encapsulates. No idea why, but with newer versions of FSUIPC (in my setup) the path to the Garmin trainer software, defined in the RXP.INI file for each aircraft is not correctly parsed, or ignored. So, when RXPG1AE.EXE (the encapsulator) tries to find the trainer, but can't, you get the error message. The encapsulator is run, when the RXP gauge file loads. If the gauge is installed in your default startup aircraft, FSX will hang, and not start. Otherwise it will just not load the app correctly in loading an aircraft with the gauge, but the aircraft will still starup. The 430W frame will pop up, but it will remain black, as if it could not power up. The solution is dead simple. You just need to copy all of the trainer files into the same directory where RXPG1AE.EXE lives. It then finds all the dlls it needs, and it works. Trainer files are installed into something like: C:\Garmin\GNS400W\Trainer\*.* RXPG1AE.exe is found here, in my setup ... c:\Users\yourname\AppData\Local\Reality XP\RXPGnsSim\ Eureka - wow. How simple. * Orest

For anyone interested, this thread may help ... http://www.simforums.com/forums/gns430-530-cdp-annun-box-simdll-is-missing_topic40362.html?KW=cdp_ I am going to give it a shot tonight. * Orest

Andy, An odd comment, really, but I am surely glad you are not having a problem. I have no doubt that If the problem was more widespread, a solution, or at least the cause or trigger, would be more likely to be found. Not a criticism, just a practical observation. * Orest

This problem remains unsolved, and RXP support is silent on it. It is somewhat uncommon, but not unique to my setup (obviously). If I want to run the 430 RealityXP, I need to copy in an old DLL version of FSUIPC. Pete, I know you don't like to pull old versions out of the archives, but what might help is to be able to uninstall/install the minor updates one by one (starting at the last working 4.6x), until that error appears. That would at least narrow down what if any change in FSUIPC triggered this. * Orest

Thanks. So, just to confirm, an aircraft can only belong to, at most, one profile -- correct? * Orest

I searched through the docs, but didn't find an explicit note. What I want to do is create a couple layers of overlapping profiles. For example, here might be a typical array of profiles ... [Profile.Level D B767-300ER] 1=Level D Simulations B767-300ER - United Airlines NC 2=Level D Simulations B767-300ER - United [Profile.FT Embraer 170] 1=Embraer 170 United Express 2=Embraer 170 Air Canada [Profile.PMDG 737-800] 1=Boeing 737-824NGX United Airlines (Merger) Winglets 2=PMDG 737-800NGX PMDG House Winglets 3=Boeing 737-8CTNGX WestJet Winglets To that setup, I might want to add aother profile, let's say we call it Boeing ... [Profile.Boeing] 1=Level D Simulations B767-300ER - United Airlines NC 2=Level D Simulations B767-300ER - United 3=Boeing 737-824NGX United Airlines (Merger) Winglets 4=PMDG 737-800NGX PMDG House Winglets 5=Boeing 737-8CTNGX WestJet Winglets The goal would be to avoid having to, make the same assignments for common items for both the 737 and 767, in their profiles, I could just make that Boeing "common" assignment, only once in the Boeing profile. I could not put that common assignment in the general non-profile list, as it does not apply to all aircraft, just those. SImilarlly, you could have a JET and/or a TURBOPROP profile. Is this a valid construct, or can an aircraft only belong to ONE profile? * Orest

I just had this happen to me. Lost control of the yoke axises as well as a number of its buttons, after assigning within a profile, a spoiler and flap axis to the quadrant. I was going to post, but glad its fixed already! * Orest

Your question as to how RXPG1AE.EXE is started is a good one, and I don't have an answer to that. Yes, I tried hiding the DLL.XML, and reinstalling FSUIPC and RXP. Same diabolic error with the current version of FSUIPC. With the older FSUIPC 4.6x version, it runs fine. I only encountered the error when I updated to the 4.7 family, which was triggered by my interest in LUA. RealtyXP has ignored my support ticket, as far as I can tell. The condition is triggered somewhere around 4.74x, from the other reports I've read. The version of RXP doesn't make a difference, it has not been updated in a year in any case. I think at this point I am just going to have to resign myself to the fact that in my setup (the problem is far from universal) I can't run FSUIPC 4.7x and RXP at the same time. If I want to run the RealityXP software, I will have to swap in the older version of FSUIPC that I still have archived, and reinstall RXP. Not sure what else to try. * Orest

Whoops, I thought that was something new. * Orest

Excellent, looks like just the primer I need, for the FS specifics. I'm a programmer from way back. * Orest

Using skittles' LUA tutorial, Where might this creature be? * Orest

Well, still no joy, now with 4.754. There is an EXE.DLL file, but that file is not in it. Here are the contents ... <?xml version="1.0" encoding="windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>exe.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> <Name>Couatl</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>fsdreamteam\couatl\couatl.exe</Path> </Launch.Addon> <Launch.Addon> <Disabled>False</Disabled> <Name>GoFlight FSX Data Bridge</Name> <ManualLoad>False</ManualLoad> <Path>C:\Program Files (x86)\GoFlight\GFDevFSX.exe</Path> <CommandLine></CommandLine> </Launch.Addon> </SimBase.Document> Seems that that DLL is accessed by something else to start it up. * Orest

I have submitted a support ticket to RealityXP. * Orest

I tried both of the below by editing the InitDelay=0 line in FSUIPC.ini, no change to behavior, same error message with RXP 430W installed. InitDelay=10 InitDelay=110