Pete Dowson

The SimConnect log shows the explanation for the FSUIPC4 log entries. FSUIPC4 times out arrival of User Aircraft and General data, but it doesn't worry about AI/MP traffic data. t seems that user aircraft data was arriving to FSUIPC4 (client 63) okay till the last such data at 70.81075 (70+ seconds) which is possibly where you engaged MP mode? Following that the ONLY "ObjectData" return to client 63 was for AI/MP aircraft. Then, at 83.61249 I reconnect and re-initialise everything, to no avail ... I look forward to seeing results without TrackIR. Regards Pete

Okay, thanks. I'll take a good look. I'm out tonight so it may be tomorrow before I get through it. Meanwhile, could you do a test with that timeout changed as I mentioned. Also, I see you have TrackIR installed too. Does that continue working okay throughout the MP session? Could you try a test without it running, just to see if it is related to their being two very intense Simconnect clients? Thanks, Pete

There was a problem in FSX as originally released where SimConnect became disconnected altogether when a Multiplayer session was started. That was what first prompted me to add in the extra code to detect a lack of data arriving from SimConnect, and execute a re-connection. This problem was said to be fixed in SP1. However, from this it looks like the fix isn't working correctly -- in fact it is worse, as the reconnection before worked and was only needed just the once. This part is a bit worrying: 216312 Failed on SimConnect_CallDispatch for Message, return = 0xC0000120 I'll need to find out what that error number means. I will report this to Microsoft and see what they say. I know there have been Beta testers successfully using FSUIPC with Multiplayer and Beta versions of SP1, so it may be system-specific -- so can you also report it with as much information as you can about your system. Send stuff to tell_fs@microsoft.com. A Simconnect log may be useful (see the FSX Help announcement). Then you might like to try changing the timeout and let me know: SimConnectStallTime=n This is actually the timeout between items of data arriving, defaulting to 1 second. Since data should arrive on every frame, this is actually a very generous allowance. The range is 1 - 9. You could try something silly like 9, and if that appears to "fix" it, gradually reduce it. Currently the 5 second retry interval isn't adjustable, but bearing in mind nothing of FSUIPC is working in the intervening seconds, there's not much point in making it bigger or smaller. There's only such an interval in the first place to stop it taking over the system. I'll check into that Error number, in the mean time. [LATER] I need to see what is happening from SimConnect's point of view, so could you please do that second test again for me, but first set up to get a SimConnect log -- the instructions in the FSX Help will tell you how. It will be quite large, so don't let it go on too long, then ZIP the logs (SimConnect and FSUIPC4) and send to petedowson@btconnect.com. Thanks! Regards Pete

Just to verify that my diagnosis is correct (before rushing to try fixing it), could you please download the 4.101 version of the Installer package I've now uploaded (see the FSX downloads Announcement). If the 60905 build isn't available this will say so, with an error. The install log will list those builds of SimConnect it does recognise, but it won't install unless the needed base version is correctly installed. Let me know please. If this doesn't show me what I expect it to show, we need to look elsewhere. Regards Pete

There wouldn't be if FSUIPC4 wasn't even loaded. The only dependencies are the original release version of SimConnect (60905) and the same C run-time library which FSX itself needs in any case. So it sounds like the new SP1 version of SimConnect installed okay, but when you re-installed FSX the original SimConnect wasn't installed correctly -- one of the usual problems several have had in the past. Please see the FSX Help announcement, above. Try re-installing the original SimConnect by deleting the relevant folder (the 60905 one, not the new 61242 one for SP1) and either repairing from the FSX DVD1 or finding the original SimConnect.msi from the DVD's SDK folder and running that. I'm afraid there's no way around this. If I build FSUIPC to only load with the SP1 SimConnect it won't load on non-updated versions. FSX is supposed to support ALL versions of SimConnect, but the only one guaranteed to be supported on any particular system is the original, the 60905 build. So FSUIPC4 expects to be loaded by that. When it is actually loaded and running it finds the latest one it can deal with and links to it. This is the way the Windows side-by-side installation system is supposed to be used. [LATER] I'm thinking that possibly I can check for this problem in the Installer. It wouldn't solve the problem, but it would stop FSUIPC4 installing into a system where it wouldn't get loaded anyway, and give a proper error message. Regards Pete

Was there no FSUIPC4.LOG produced? Hmmm. Strange. I'm not sure what Error -3 is. I'll have to ask Microsoft. I'm doing so right now ... Pete

The only 5 second timer in FSUIPC4 is a timeout for the connection to SimConnect. A stutter would most certainly be caused if it was getting no information and was doing a complete re-initialisation each time, as that involves thousands of little messages to SimConnect. Please look at the FSUIPC4.LOG file. That is what it is for, to show things going wrong, if and when they do. Regards Pete

You can have more than one WideClient receiving the GPS data, on separate PCs but only one output from each is available. I don't know if there are any utilities to divert one serial port stream into more than one connections. One thought. By using the "ClassInstance" parameter in WideClient.INI (please check the documentation), you may be able to run more than one copy of WideClient in a sinlge PC, and have each receive GPS data and send it to different ports. Pete

No. It now links dynamically. It has an overt manifest matching 60905, to guarantee that it gets loaded, but then it uses sets of probe manifests to determine the latest SimConnect version it can work with --including SP1 Beta3, SP1 Beta4 and SP1 release. Before SP1 Beta3 there was no difference which mattered to it. As new SimConnect facilities are added and FSUIPC is extended to use them, it will maintain compatibility with older versions but simply won't support the newer facilities then. There are entries in the Log file which tell you which one it is working with ("SP1 May07" for example). Regards Pete

You don't need to uninstall anything related to FSUIPC. You should install version 4.10, but it doesn't matter if you do this before installing SP1 or after. FSUIPC will not crash FSX SP1 nor will any of its needed files get destroyed by installing SP1. The DLLs which are certainly not compatible are those related to the SDK. f you installed the SDK with its modules such as the Traffic Explorer, then you should install SP1, then install the SDK SP1A update before running FSX again. I understand there are some other third party DLLs which might cause problems unless updated -- FSCopilot, possibly, for example, but I'm not sure of the details. Anything only using FSUIPC will be okay. Oh, I don't think you need worry about 3rd party aircraft either. Regards Pete

What post? Didn't you read the Announcements above? It is available here for hours, in the FSX downloads, and, just recently, on the Schiratti page too. in other words in the usual places. Please DO read Announcements first. It will save you time, effort and frustration! Pete

The only component of WideFS which might change at all for different flight simulators is WideServer, and this has been built into the FSUIPC4 code since its conception. Apart from the documentation, the only part of the downloadable WideFS package you use for an FSX installation is WideClient, which is common to FS98, FS2000, FS2002, CFS1, CFS2, FS2004 and FSX (and, for that matter any future version). So, no, there's currently no new version of WideClient expected or needed. Regards Pete

The PFC driver links PFC hardware to either FS directly, or to pmSystems facilities. In this case neither of those are supported by FS, but by pmSystems. FSUIPC's job is primarily to interface to FS for all FS-supported functions. The assorted PM modules and programs communicate to FS and between each other via FSUIPC offsets allocated to PM for this purpose. FSUIPC really has nothing to do with it at all except as a post box. 3BD0 and 3BCC are PFC-assigned locations for an interface PFC themselves once used to their own Flight Instructor module. I think they now use the PM Instructor. All the bits in those words are doing is allowing a third party program to see when a PFC button or switch is operated, and to set or clear indicators on the PFC panels. They are not useful at all without the specific hardware which PFC.DLL drives. Offset 556D is one of a range of offsets assigned to PM and interrogated by PFC.DLL so that PM can operate the stick shaker. Again it is related specifically to PM hardware. Whether PM software operates that location without the PFC driver being installed I'm afraid I don't know. If you are implementing a full cockpit with subsystems and facilities not supported by FS itself you need something like pmSystems to make it all happen. PM systems can be driven by programming your switches to operate via pmSystems offsets, an, in fact, pmSystems does support some hardware interfaces directly. Currently pmSystems is far more advanced in its 737NG implementation than it is in most other aircraft types. For more information on all this you'd best go to the PM site and investigate pmSystems there. Regards Pete

Of course not. FSUIPC 4.0 won't work on a new version of FSX. You need 4.1. You can NEVER expect old versions of FSUIPC to work on versions of FSX it has never seen. It is impossible to program in advance of knowing what to program! I had FSUIPC 4.10 ready to release yesterday, but I needed the final SP1 release to verify before uploading. Yesterday MS were predicting later today for public availability of SP1, but they evidently released it whilst everyone in Europe was asleep! :-( I will download it now and check it out, then FSUIPC 4.1 will be available in the FSX downloads above, and later on the Schiratti page. Regards Pete

Sounds like RC can't talk to FSUIPC. What version of FSUIPC are you using? The only other report I've heard of like that was on a Vista installation, where the user had installed FS2004 using its default location, in "Program Files". Apparently Vista protects folders in Program Files, and allows pre-Vista program compatibility by a sort of aliassing system for the folders. Why this should mess up RC specifically I've no idea, but evidently something about how RC works gets thwarted. In the case I know of, the user only resolved it by uninstalling FS2004 and installing it somewhere else, like C:\FS2004. As far as I know this most certainly should not be necessary, but I suggest you go to Radar Contact support to see what the correct solution should be. Regards Pete

Well, there's not a lot of point for FSUIPC, because I've no way of finding the same information in memory at run time. FSUIPC does nopt scan all BGLs -- it doesn't scan any at all. It would be far too inefficient and certainly the wrong place to do it. What you need is a database, generated by pre-scanning all BGLs, much as used by many other programs. If the value is really there I could even add it to the database generated by my MakeRunways program (aimed at Radar Conract) -- but only for ILS's because non-approach VORs aren't included in my scanning unless they are part of the airport record. Regards Pete

I've searched through all the stuff I can get at, and this doesn't appear in any of it. Sorry. Are you sure the facility in AFCAD actually does something? Looking at the format of the ILS/VOR records in the BGLs there doesn't sem to be any field for such information. Mind you, the documentation I've got has some fields marked "unknown" -- one two byte field for the Glideslope, and one for the LOC. However, they are both in the same relative position for both, suggesting that they both would contain the same type of data. Wouldn't there be a beam width for the glideslope as well -- even though AFCAD doesn't appear to have a setting for it. Regards Pete

Hmm. New one on me. ;-) Not at present. I'd have to check whether anything is supplied to gauges and so on. If so then I should be able to get it. If it is only used internally to compute signals, then there's not much chance I'm afraid. Yes. I think there's a search process which isn't particularly high priority, and possibly simulates real equipment behavious? I suppose it depends on what you are tuning, but VOR's for instance have a delay as they do their 360 degree sweep, don't they? As far as I know that hasn't done anything since FS2000, possibly earlier. It was necessary because the search didn't start till then. I think it was to get around low performance when changing frequencies through to the one you wanted. Pete

Flags or virtual buttons can be operated by axis zones, on the right-hand side of the Axis assignments dialogue. Ahthat's the other way around from what you asked, is it not? You want a conditional facility for axis operation, not a flag generated by an axis zone. That's because only the [buttons] section supports conditionals. However, you can inhibit reversers by setting bits in offset 32F8. Here's the relevant part of the Programmer's Guide (list of offsets) describing the one byte value at 32F8: You can program your button to "Offset Byte Togglebits" 2^4 to 2^7 using mask xF0. You don't even need to edit the INI file for this. Does this help? Regards Pete

Ah, yes. Sorry. I hadn't noticed that. Though, even if that were wrong, your DLL would still be loaded. It would simply have been terminated again quite quickly (i.e. without the init function being called). Since up until FSX I made DLLs work for all versions of FS since FS98, and even including CFS1 and CFS2, I had to set that parameter dynamically, in the DLLmain function, after working out which version of FS had loaded me. Regards Pete

Did you export the ImportTable and Linkage names, as in extern __declspec(dllexport) IMPORTTABLE ImportTable; extern __declspec(dllexport) LINKAGE Linkage; If you don't, FS won't think it's a suitable DLL. Regards Pete

Sounds like either he has tried to register it with bad (pirated) keys -- just delete the FSUIPC.KEY file to fix that. Or possibly it's a signature problem -- all my software is now signed, and if it is corrupted or there's a problem with the signing authority, this will be a symptom. He can right-click on the DLL and check the signature. Most likely he's using winXP before SP2 or any older version of Windows and needs the GlobalSign signature fix applying -- tell him to look at the documentation. In the section on Installation there's a box headed "IMPORTANT: Before updating ...". It tells him about this and what to do. Regards Pete

I don't see why VS2005 isn't usable -- I use it. But sorry, I've no idea about anything to do with C#. Pete

It isn't mandatory, but a good idea if they want better performance, fewer bugs, and any support. No. My game is compatibility. That's what started all this stuff off in the first place. I suppose he's using ages old versions of Project Magenta modules too! :-( Pete

Sorry. Just replace 3.65 with 3.74. I cannot and will not support old versions. Yes, terrible things like bugs being fixed, things working better, support available! ALWAYS use the latest versions! Yes. Tell your user to put his hand in his pocket and pay for an FSUIPC user registration. ;-) Pete