Pete Dowson

Okay. Once FSX is up and running okay you should be able to load the PMDG (or a flight which loads it) without problems. Not sure about the closing though. In FSX, unlike FS9 and before, FPS isn't be most important factor, unless it is less than about 15 when it can start to make landings difficult because of the responsiveness, or lack thereof. Smoothness is more important, and FSX is capable of beeing smoother at lower frame rates than FS9. Looks fine. You can remove those extra INI lines now. I note that the time to "everything read to fly" is greater than before, by some margin. Maybe some of this is memory caching? 56036 ## Starting everything now ... Regards Pete

That looks exactly like it would if you'd never gone to "fly now" mode, as if it was still in the FS initial selection screen when you terminated it! FSUIPC can't do anything until in Flight Mode. Look: my FSX installation, using Vertex 3 SSDs on SaTA 6Gb/s ports and on an i5-2500K clocked at 4.8GHz takes at least 60 seconds to get to flight mode, and then has frame rates in the 30's or more. How you can fly at 6 fps I don't know, but it certainly looks like it never got to Flight Mode. Here are examples of what the log looks like once things start happening: 57172 ## WHYSTART: SOON: (0366=N || (0264=Y && 3365=Y)) && (3D00=Y || (0580=N && 0264=N)) 57172 ## ... and no class #32770 window! 57172 ## WHYSTART: NOTYET: (No#32770=Y && time=Y && 3365=Y && seeStart=Y && startime=N) 58000 ##: ST_SIM=start 58703 ## WHYSTART: NOTYET: (No#32770=Y && time=N && 3365=Y && seeStart=Y && startime=N) 59047 ## WHYSTART: NOTYET: (No#32770=Y && time=N && 3365=Y && seeStart=Y && startime=Y) 60531 ##: ST_SIM=start 60531 ## WHYSTART: NOTYET: (No#32770=Y && time=N && 3365=Y && seeStart=Y && startime=N) 61547 ## WHYSTART: NOTYET: (No#32770=Y && time=N && 3365=Y && seeStart=Y && startime=Y) 61734 ## Starting everything now ... Can you confirm that you did actually get to Flight Mode, with the Add-Ons menu, and the frame rate got up to flyable levels? If you did I don't understand what is going wrong. It isn't getting many if any needed signals from SimConnect -- not even the clock updates. This is why I thought it might be in Paused mode. Did you check that? You didn't say before. If you think everything is correct and 'ready to fly', I think I'll need to see a SimConnect log -- see the FAQ subforum for how to get one of those. It may get quite big, so ZIP it up and send t to petedowson@btconnect.com. I'm running out of time today. Then it will be 24th or later! Maybe. There are quite a few different problems which cause threads to hang, especially with complex addons like PMDG aircraft. One thing to try. Change the aircraft to a default one and save a new default flight. Try then resloading with default, into Flight mode, before changing back to the PMDG. I have read a lot of reports that say starting with an advanced aircraft can often cause problems. Oh, and do try with 4.85 of course. Regards Pete

As well as checking in the Download Links subforum (where interrim updates are available too), the version provided by Schiratti is actually 4.85, it is just the wording on that page hasn't been updated. I don't have control over the page, I depend on Enrico updating it. Regards Pete

Yes. the exhange of data with SimConnect is not starting. After the line 14165 \\RODNEY\FSX\SimObjects\Airplanes\PMDG 737-800NGX WL\B737-800WL.AIR there should be several standard lines like this, occurring as soon as SimConnect starts providing all the needed data: (This is from my own log). 5906 \\LEFT\FSX\SimObjects\Airplanes\B737_800\Boeing737-800.AIR 91844 System time = 13/08/2012 10:21:31, Simulator time = 10:19:59 (09:19Z) 93469 Starting everything now ... 182562 PFC Menu entry added In your case FSUIPC is not getting off the starting line. It won't be servicing any of the offsets let alone loading other DLLs. Are you starting with FS in Paused or Slew modes perhaps? Could you add these lines to the INI file (in the [General] section), please, and try again. Show me the resulting log: Debug=Please TestOptions=x800 This should give me a bit more information on why it isn't starting. Oh, and please update to 4.85. Regards Pete

Current FSUIPC is 4.85. PFCFSX.DLL is up to 4.404 but the changes from 4.40 are insignificant. Hardware isn't involved. The PFC DLL does not need to detect the hardware to produce the menu. After all, inititially it allows you to specify the serial port actually in the dalogue so it obviously cannot be dependent on the hardware. That would be very unlikely. Check the signatures (right click, then properties-digital signatures) on the DLLs. If the FSUIPC one was corrupt it wouldn't work at all and you'd get a message. Have you checked the FSUIPC4.LOG file? That's the first step. Show it to me (paste t here). Note that I am on holiday from this evening (Monday) until Friday 24th August. Regards Pete

I've no idea because I don't know what your warnings are. There are so many options in Microsoft VS that it confuses me and I've been using them for many many years! Most warnings from older programs (and UIPCHello and the Library code is 12 years old now) come from stricter and stricter "rules" added by microsoft over the years. You'll need to debug the code and determine WHY it says it cannot connect. It may simply be you are using it with FSX and haven't added FSX as one of the acceptable versions in the header declarations. either way, you will find the debugger in your VS very useful. Just step through the code, see where it determines the error. Sorry, don't know what "PDBs" are. Regards Pete

Ah, sorry -- I was thinking of the PMDG 737NGX, not the 747. I don't know how you'd do it on the 747. Have you asked in the PMDG support forum? Regards Pete

I'm still not sure why you'd want to. The SDK seems to list controls for everything in the CDU. Pete

I use VS too. Have you compiled anything else with it before? The source of everything provided for UIPCHello.c is provided in the SDK. I expect if you are using the compiled LIB file it isn't compatible with your version of VS. Just take the source of the LIB instead and either make a new lib with your VS or simply build the source into the program. Your choice. Regards Pete

Super! Thanks for working it out!! Pete

I have three monitors on one of my systems with a humber nVidia 7600GS driving through a Matrox TripleHead2Go. I think that was one of the first real "surround" video setups. The other two reports of problems with nVidia Surround are at start-up -- FSX never loads. In one case it is sometimes in combination with another DLL (BGLMANX.DLL), but the inconsistent results from trying different things strongly suggests timing issues -- i.e. bugs between SimConnect and the video drivers or the trust verification system. Your report is the only one which suggests problems later on, well past the trust verification -- except maybe that for the PMDG MD-!! components? I noticved there was no sign of the MD-11 having loaded in the FSUIPC log you showed. The last entry appears to be the loading of the standard FSX default. Regards Pete

No, sorry. There's really no indication there that it's specifically fSUIPC. Please see the thread near here about SimConnect and BGLMANX. That remains unresolved too. However, you should try version 4.85, the current release, please. Does everything run okay without this "surround" setup? I've actually never heard of that, by the way. Is it new? Regards Pete

Sorry but, excepting the fact that it is also related to this "nVidia surround" mode*, this is really seriously starting to look like a Wndows problem, probably a corruption in the Cryptographic Services or related functions. Your results don't make any sense at all unless they emanate from something weird going on pretty low down. The fact that the unsigned Loader loaded at all when the signed one didn't is a pretty saure indication of this I think. (* Should I still understand that none of these problems occur without nvidia surround mode?) I'm afraid I can't really advise further. And to cap it all i'm off on holiday later tomorrow for a couple of weeks. [LATER] In another nVidia surround problem report near here, a user has the problem when loading the PMDG MD-11 -- only on one out of two systems though. He is using different nVidia drivers on the two. You once said changing drivers was not a possibility. I took that to mean that only one specific driver version supported the mode you are using. This appears not to be the case, so don't you think it might be a good idea to try different drivers after all? Additionally, this other user's system loads up successfully using a default aircraft. It is only when he tries to load a complex one when problems occu. What aircraft are you loading by default? Can you try changing it? I'm swinging back to thinking it's video driver related again! Regards Pete

Ah, in that case Prepar3D isn't even returning bad information like fSX. i will re-check when version 2 of P3D is available. Regards Pete

Just as an experiemnt, try this UNSIGNED copy of the loader. You'll need to give permission for it to be loaded, at least the first time. Try running FSX more than once. FSUIPC4 loader (unsigned) Pete

So it isn't an initialisation problem? It can occur later, after you are able to use FS? It must be something specific to your system as the PMDG MD11 is used with FSUIPC quite successfully by most folks. there are even macro libraries for it (see the thread PMDG MD11X commands in the User Contributions subforum). What information does Windows give as to why it is an FSUIPC problem? (Check the Windows error log). Pete

The current layer whichever is operating. Global weather only operates at weather stations which don't have their own weather set. And it progresses independently in any case, so effectively there is never any such thing as "global weather", only "default initial weather". FSX is different in that they granted our request for a global weather mode, on the justification that we needed precisely reproducible conditions for training purposes. The global mode is used by Active Sky on FSX for its "direct weather control" mode as this gives it more precise control. BTW I think you are mistaken about FSX. Given the right hardware it is very reliable and very enjoyable, much more so than FS9. The level of detaill and quality at add-on airports is incredible compared to FS9. Regards Pete

The facility relies on a SimConnect function which doesn't work very well, so it is defaulted off. Add (or change) "GetNearestAirports=Yes" to the [General] section of the FSUIPC4.INI file. However, it rarely provides the actual airport you are sitting on, and sometimes not others nearby. It is SmConnect which is buggy in this area. After the facility was implemented I did get some hacked information from Daniel van Os which led me to a table inside FSX which contains the correct information, so I use this for FSX SP2/Acc. But I didn't find this in P3D -- and in fact did not look very hard, because P3D is still being developed and they should make the published facilities work. I don't really want the job of detailed hacking into each update of their code in order to correct their bugs. If you check it after setting that parameter, and it doesn't give reliable information, please do report it to P3D support so that they might one day fix it. For reference the SimConnect facility concerned is: HRESULT SimConnect_RequestFacilitesList( HANDLE hSimConnect, SIMCONNECT_FACILITY_LIST_TYPE type, SIMCONNECT_DATA_REQUEST_ID RequestID ); with type = SIMCONNECT_FACILITY_LIST_TYPE_AIRPORT Currently I can't even test it on P3D as my license has expired again. I'm really waiting for Versio 2 when I might actually buy it if it looks as good as folks are hoping. Regards Pete

I assume you are talking about FSUIPC3, not FSUIPC4 by the way. You don't provide the context, but the visibility control doesn't really allow any effective graduated visibility in FSX. Sorry, there isn't and not really an easy way to change things on-the-fly, the way it is working. Additionally, the code in that area in now at least 8 years old, and quite complex. I'm not really willing to risk messing about with it at this stage. Generally, apart from Lua plug-in provisions, development of FSUIPC3 is frozen. Regards Pete

I've changed the loader slightly, to delay 5 seconds before it activates FSUIPC4 itself. Because it doesn't sound like the loader is even being entered I don't think it will help with your case, but do try it. You never know -- SimConnect may just about to log the "load" message at the time of the crash. If so, this may help. Worth a try anyway. Download FSUIPC4_Loader 1.10. I'm releasing full version 4.85 later today. The Installer for that will automatically handle the DLL.XML for Loader or no Loader, depending what it sees in the Modules folder. Regards Pete

The lettered name entries in the [Joynames] section aren't removed by the program, only added. So Q was either added automatically or manually at one time even though it is no longer used. The missing A and B GUIDs looks like a bug in FSUIPC. I'm fixing it now. Meanwhile please put them back in yourself -- copy the appropriate 3.GUID and 3.GUID lines to A.GUID or B.GUID, in whichever order is correct. Version 4.85 will be released later today. Regards Pete

Ah, is it one of those implementations which used the values in certain offsets which were actually faulty, and instead of reporting the fault to me so I could fix it long ago, adapted to the incorrect values? If so, then because i corrected those values a while back it may be one which needs the "AxesWrongrange=Yes" parameter to make those offsets revert to their previous wrong values. The reference is here (quoted from the Advanced User's manual):: If so then it might exaplain why such a very specific series of settings appeared to be needed to work around this without the parameter set specifically for the aircraft. Regards Pete

Ah, not "fs339.exe" as you said earlier? Okay, but neither in the FS folder, surely. The operative CFGs are those in the <username\AppData\roaming\microsoft\FS9 folder. Why not simply rename the original "FS9orig.exe" so you don't lose it, and call your patched version "FS9.exe". You seem to be making it very complicated for yourself. Anyway, it is the CFG file actually being used by FS which you need to edit to add the [FSUIPC] section. And the name you provide in there can be any name you choose. If you want to name your INI "fscloud9.ini" then just add [FSUIPC] ControlName=fscloud9 This will make FSUIPC create or read "fscloud9.INI", but you will need also to copy the KEY file to "fscloud9.key" otherwsie it will be unregistered, as you found. Also the Log will be called "fscloud9.log". Regards Pete

Who's Steve? Why? do you want a renamed CFG file for FS9? I don't understand why you'd do this. And the name "FS9cloud" was only an EXAMPLE! And it only applies if you want different CFG files for FS! Your FS9.CFG is in your <Username>\AppData folder! In your case, because you named your FS "F339.exe" it wil be "F339.CFG". It is in THAT file you add the [FSUIPC] section. THEN in that section you set "ControlName" to any name you wish -- e.g "Fabio". Not "Fabio.ini". If for some strange reason you want to call it "FS9cloud" then do so. BUT the section you add MUST be in the FS CFG file actually being used by FS, not in some arbitrary CFG file placed in the wrong folder!!! Such a CFG will never be seen by FS or FSUIPC! I am starting to think it is too difficult for you. Or maybe it is English which is the problem, but i am sorry, I cannot think of any other way of explaining it. I cannot imagine how you come to all these entirely wrong ways of doing things! :-( Pete

Ouch! I don't know how you work that out! FS9.exe /CFG:fscloud9.CFG is an example of a command line you'd use to load FS9 with a CFG file called FScloud9.CFG. The ControlName is whatever name you want to give to your FSUIPC.INI file instead of FSUIPC! As I told you, YOU choose!! Please try re-reading it more slowly! ;-) Pete