Pete Dowson

Okay, you are welcome. I hope it gets fixed soon! Pete

Okay. I feel a bit daft with something I know nothing about, so i will probably preface it with "it has been reported that ...". ;-) Thanks, Pete

Nothing known to me. FSUIPC and FSNav have nothing to do with each other., and I know lots of folks using both with no problem. What are the details (you can access more, like the Module name and address by asking for them in that Window). Usually such problems are caused by video driver interactions in FS, and they are often very timing sensitive -- the loading of both FSNav and FSUIPC may simply be showing up a problem that is lurking anyway. FS9.0 was very prone to these sorts of problems, but 9.1 did clear most of them. Is there anything about any problems in the FSNav support place? You could try delaying FSUIPC's start-up -- add an InitDelay parameter line to the [General] section in FSUIPC.INI. For instance InitDelay=5000 delays FSUIPC's start-up by 5 seconds after FS loads it. By default there is no delay. The units are milliseconds. Oh, also try the latest interim version of FSUIPC, 3.709, available above, just in case the small differences in it help. Regards Pete

I looked at the EliteFS DLL (which is the only bit relating to FSUIPC), and traced its FSUIPC actions right through. It is not, in any way, a problem related to it and FSUIPC. It gets through all of its FSUIPC checks and sets an internal flag to say it has done so. It must be falling over interfacing to your hardware somehow. Sorry, I cannot do any more. Maybe your USB subsystem is wrong. Are you using WinXP? Are you connecting it through a USB hub or direct to the PC's own USB ports. If not, do that. Also go into the System control panel facility, Device manager, and make sure you have power management switched off for that USB device. Apart from trying things like that, I'm sorry, but it starts to sound like hardware. Regards Pete

Not if you are not using it, no. Cross that possibility out. Try "portmon", http://www.sysinternals.com/Utilities/Portmon.html Regards, Pete

No, sorry. Sounds like COM1 is already used by something else. Do you have GPSout loaded and using that? Check your other programs. Regards Pete

Isn't that realistic? Sorry, I don't know all the technicalities of these things, I only provide what's there. Well, you have the exact Latitude, Longitude and Altitude of both the Glideslope transmitter and the Localiser, and you have the localiser direction and the glideslope angle. All those variables are available. From there it is just a matter of three dimensional trig, isn't it? Regards Pete

It isn't broken, it is working fine! Please try again. No, it's just an interim update. Another formal release, 4.02, will be up on the Schiratti page on the weekend. Regards Pete

There are lots of examples in the documentation. Did you check? How come you've used this stuff with FS9 and now don't understand the same stuff in FSX? Nothing has changed! Anyway, all this below is simply looking at your INI file. You had: [GF166.2] Needs=V16 B E A B=4 ; Radio use D0.1=!C36 C39 X350 R2 ;NAV1 D1.1=!C36 C39 !C43 X311E R2 ;NAV1 sby D1.2=!C36 C39 C43 C44 XC50 U16 *360 /65536 D30 ;NAV1 radial D1.3=!C36 C39 C43 !C44 ="---" D1.4= ="" ; Else right display blanked Of those conditions, C36 is for debug mode -- do you need that? Do you understand it? Let's chuck it! C39 selects NAV1 on the value 3 in offset 66C5 (you can look these up yourself!) C43 is a flag for radial display instead of standby. Do you need that? If so you need the button to change the offset on which it is based. I'll throw it out for now. C44 is just a test for an active NAV1, but since it depends on a radial display (to be replaced by ---) it isn't relevant if we throw the radial display away. Anyway, deleting all that you end up with: [GF166.2] Needs=V16 B E A B=4 ; Radio use D0.1=X350 R2 ;NAV1 D1.1=X311E R2 ;NAV1 sby There. What's so hard about that? Regards Pete

Erbut your INI file contains lots of conditions relating to what is going to be displayed, and those are set by buttons. I'm thinking in particular of the values set in offset 66C0 and 66C5, which define what is to be displayed on a GF45 and GF166 respectively, with COM1 if it is zero (as it will be!). The INI file seems to be very closely based on the one I provided as an example, but whereas my example for the radios was for a single GF166 or GF45 to display any one of the 6 radio settings, according to an FSUIPC offset set by buttons, you have added three or four other GoFlight units, but you are still using the same types of conditions!!! Obviously, if you can display 4 or 5 values at once on different units you don't want each dispaly to be dependent upon some selection button. The only reason you see COM1 and not the others is that is what you get with 66C0 and 66C5 set to zero, which it will be until you change it with the button stuff. Sorry, if I'd known you hadn't programmed the buttons to select the frequencies I wouldn't have asked for the Log, as it does me no good. Really you need to examine your complete GFdisplay.INI and discard EVERYTHING to do with selecting different displays for the same GoFlight unit. You have several Goflight units so you need none of that stuff, nor probably most of the button stuff. To start with, delete conditions 12 to 18 and 37 to 42, and all references to them. I'm sure you could throw most of the rest away too. Regards Pete

Ah, thanks for letting me know! Pete

I'm sorry, I keep archives for a year, but that's about three years ago! Anyway, I can't see how that could make any difference. As the Log shows, it doesn't even try to talk to FSUIPC except for the Open. If it is related to FSUIPC it will be something wrong with its checking of what the open returns. We've already tried changing the FS version number. Maybe it also checks the FSUIPC version number, and doesn't like later versions? The best I could do is to look to see if that is what it does, and try patching it for you. Zip up the DLL and send it be email. Regards Pete

Oh, I am sorry, then. I really don't know what to advise. This company doesn't seem very sympathetic, does it? I suppose it is too late to demand your money back for the hardware? Did you buy it directly or from a dealer? In the UK it is the retailer who is responsible to you for the "fitness for purpose" of the product, but I suppose if you have been using it well for a period and now it doesn't work it comes under chargeable repairs as far as they are concerned. Regards Pete

I would do if I understood that properly. I'm afraid I am not familiar with Gauge programming. Are your words above enough, or would you care to word something for me to insert, please? Do you think there are likely to be many gauges actually using FSUIPC4 when they can get this stuff direct from SimConnect? Regards Pete

I'm afraid I cannot reproduce that here. It seems to work 100%. What happens is that SimConnect sends me the Aircraft Changed notice, with the pathname, before it sends me the Flight Changed notice, also with the pathname -- I think when I get the latter, the flight is then fully loaded. So the value in offset 3C00 should be changing slightly earlier than that in 3F04. If you can get a different result, could you tell me how to make it occur? It would have to be reported to MS for fixing in Simconnect, but we need to tell them how to make it happen. Thanks, Pete

Thanks. Two things only to note from what you sent. Following the link in your first post in this thread, I found one message from someone in Elite, who said What version is your EliteFS.dll? (right click on it and check Properties-Version). The date on it in the listing you sent says "25.09.2006" but I can hardly believe they have updated it so recently. Second, in the FSUIPC Log these are the only parts relevant to the Elite driver: 42531 Client Application: "fs9" (Id=1836) 42531 C:\Programme\Microsoft Games\Flight Simulator 9\fs9.exe 42531 Product="Microsoft Flight Simulator 2004 - A Century of Flight" 42531 Company="Microsoft Corporation" 42531 READ0 [P1836] 3304, 4 bytes: 00 00 00 37 42531 READ0 [P1836] 3308, 4 bytes: 07 00 DE FA 42531 WRITE0 [P1836] (failed, read-only!) 330A, 2 bytes: EC 03 Now the first 4 lines above show that the driver is written using the EXTERNAL application interface to FSUIPC, i.e. as if it is an EXE program. This is pretty bad. The tools for accessing FSUIPC efficiently from a DLL or Gauge have been provided in the FSUIPC SDK now for over six years. It is why FSUIPC identifies the client application as FS9 itself -- that's the EXE in which the DLL is running! The other three lines are standard -- they are part of the FSUIPC_Open and are fine. It shows that the Elite DLL did issue an FSUIPC_Open call. But that's itit NEVER then tries to access FSUIPC at all. The main likely reason for this is that those three lines identify the version of FS as being FS2004. It seems likely to me that the Elite driver you are using actually checks the version of FS it is being used with and doesn't like FS2004. Perhaps it was intended to operate with FS2002 or FS2000 only. There is a "fiddle" available in FSUIPC to tell lies to programs and say that it is FS2002. You can try that, to see if will get any further: MakeItVersionFS2002=Yes This goes into the [General] section of the FSUIPC.INI. Note that is may make other add-ons not work, or at least not work the way they are supposed to on FS2004. Really you ought to report all this to Elite and get it sorted! In a second email you asked about the sequence above occurring twice -- this will simply be a timed retry by the Elite driver I should think. I really cannot do anything more. Even if the fiddle I mention does work, if you ever want to upgrade to FSX you will certainly need to get Elite to sort this problem out -- there's is really no way I can allow FSUIPC4 to lie to its clients about FSX being FS2002. It is simply not on. Let us know how you get on. Regards Pete

Is their driver an external EXE program you execute manually, or a DLL inserted into the Modules folder? I have no idea what they are doing, but if you want me to look at it from the FSUIPC side please do this: 1. Make sure nothing else is using FSUIPC -- i.e. no other external programs, no add-in DLLs other than FSUIPC, and only default aircraft. If you don't do this the information I need to look at gets completely muddied. 2. Edit the FSUIPC.INI file and add two lines to the [General] section: "LogReads=Yes" and "LogWrites=Yes". 3. Run Fs till you know the Elite driver has failed, noting down what you are doing step by step. 4. Close FS, find and Zip up the FSUIPC.LOG file and send it to me with your description of what you did and what happened. Send to petedowson@btconnect.com. I don't guarantee to be able to help, especially if it turns out to be something entirely unrelated to its dealings with FSUIPC. Regards, Pete

Okay, so it has loaded FSUIPC4 (that's where is sees the export it mentions), but it hasn't called it at all yetFSUIPC4 isn't actually running. Turning them off doesn't remove their hooks unfortuanately. I suspect the only sure test would be to uninstall them. Please first though do review the other reports here -- I think AVAST is being used by one person without a problem, and I think there might be other settings in Zonealarm that may need changing. Privacy, or making FSX trusted or something, I think. Buy all means, whatever you find, resolved or not, please be sure to write to tell_fs@microsoft.com to make sure they consider all the angles on this. I have been feeding all this data to them as I get it, and I hope they will get back to me with some clear advice or statement soon, but pressure and iformation through the proper routes from the users who are suffering cannot be a bad thing. Regards, Pete

Seems they have a bug then? Unless you are trying to use it without paying for and registering FSUIPC? I think that is needed. Elite have never contacted me, never asked to use my program nor requested any support. I'm afraid they need to sort their own problems out. Regards Pete

Are you programming buttons in FSUIPC4 too? If not how are you controlling what is displayed. Would you like to explain more? There's no change to GFdisplay, nor GFDev.dll. I cannot easily test your INI here as I don't have GoFlight equipment any more. If it worked before, with FSUIPC3, it should be okay. The NAV, Transponder and COM radio offsets are working fine in FSUIPC4, so I really cannot say what is wrong. If you want me to look, I can check FSUIPC Log files -- you'd need to enable IPC Read and Write logging in FSUIPC. Please make sure nothing else is using FSUIPC at the same time otherwise it will be too confused. Do things methodically and write down exactly the sequence you used so I can piece that together with the Log to see where it is going wrong. Pete

Insolence? Do you actually know what it means, as it cannot possibly apply here? Please read it again. I merely asked the obvious question as to how effectively the same post appeared twice, together (which you have answered well), and I pointed out I'd answered in the other one as it was the first I'd seen! You surely didn't want me to cut and paste the reply here too? What's the matter with you? Your response to my civility is most certainly completely unnecessary and not wanted, thank you very much. I'd rather you not come here again with that sort of attitude. Pete

Why post effectively the same question twice at the same time? I've answered as best I can in the first of the two I saw. Pete

In FS2004 and before the only way Multiplayer (as opposed to AI) traffic showed in FSUIPC's TCAS tables was by something like AIBridge, or, I think, the later versions of Ivap and Squawkbox, injecting the data into those tables as well as injecting the multiplayer aircraft details themselves into FS via the published MP interface. Without something actually providing the data on the MP aircraft, FSUIPC doesn't know about them. Its tables are populated by facilities in FS (and FSX in this case) to read details about AI aircraft. As far as I'm aware, there is not yet an SDK for FSX multiplayer, which is certainly different to previous versions, so I don't know how it is possible that you are currently using add-on preograms which generate MP aircraft. However, if they can do it then they can certainly inject the details into FSUIPC4, because that interface I present has not changed. I'm not sure what you mean by "but nothing seems to work in Multiplayer. WideFS shows as connected" -- WideFS really has absolutely nothing whatsoever to do with multiplayer. In fact I've never done any programming for multiplayer at all. I know nothing about it. Are you actually trying to use the FS2004 version of AIBridge? I wouldn't have thought that would work -- doesn't it depend upon the MP interface to FS? That is entirely different in FSX I think. I have seen some statements that say that Microsoft will not be opening up Multiplayer for use in the way it has been used in the past. Aren't the Squawkbox and Ivap and FSInn writers having to program the aircraft injection for FSX via Simconnect, creating them effectively as AI aircraft? Take a look at the various websites and check the news. I've only looked at the FScopilot/FSinn site, and that seems to confirm this. If that is true then all those "ex-MP" aircraft will show up through FSUIPC because they will look like AI aircraft. In fact they will mix with AI aircraft unless you turn the traffic right down on the sliders. Let me know what you find out please. It isn't an area I can afford to spend much time on at the moment, too much else to do I'm afraid. Thanks. Regards Pete

I think I can explain it ... In some Beta version of FSX the SimVar for the fuel pump switch seemed to work okay for writing as well as reading. So in my tables I marked all of them (the 3104 one for Engine 1 and 3125, 3958, 3A18, 3AD8, 3B98) as 'OK' for writing. Then I found that writing wasn't working (in a later Beta of FSX I think), and unmarked this -- on all of those offsets, excepting 3104 which I missed! Duh! What happens is that, on a write to a SimVar which doesn't support writes an exception is generated by SimConnect, which eventually gets back to me (all these things are aynchronous). When I see the exception on this write, I add another flag "Write Error" which makes future attempts bypass the SimVar writing section and operate using events (controls) instead. I think this explains all your results -- the business of many settings before FS is full ready is probably explained by the delay in SimConnect getting the row of Exceptions back to me. It is easily fixed and will be so in the next update, this weekend. If you cannot wait I can send you an interim version, but I'd rather not if you don't need it. Thanks! Pete

Okay. I'll email you something this afternoon. Pete