Pete Dowson

There's a good discount on SimMarket fpr those who purchased in the last six months. Pete

I been messing about here trying to make FSX behave differently when the ATC window is showing, and I cannot. The view options programmed on my twin rockers are for VIEW_FORWARD_LEFT VIEW_FORWARD_RIGHT VIEW_LEFT VIEW_RIGHT in that arrangement, with VIEW_RESET sent on release of each. This is the same as the default programming of the Shift+NUM keys on the keyboard. In 2D cockpit mode they do exactly what I want -- an instantaneous view to the direction specified. In VC mode they pan instead, which I don't like -- but then I don't use VC. In the PFC driver I provide two different default settings for those rockers. If you go to PFC options, Yoke Buttons page, you'll see 2predefined sets" 1 and 2 selectable. Set 1 uses panning and is better for VC use, set 2 is the set I use which operates as I describe above. This is pretty much the same as in FSX as it was in my FS2004 PFC.DLL. Either way, I can get no difference in behaviour just because the ATC window is showing -- logically it wouldn't make any sense for the presence of that window to change the effect of controls, and, indeed, it doesn't do so as far as I have tested (on two separate PCs now). Regards, Pete

ErYou must enter the email address too! Pete

Note: I deleted the duplicated thread to avoid confusion. I 've never seen a Cirrus II with a hat switch -- my Cirrus is the same as the Jetliner, with two separate rocker switches which I do use for snap views (i.e direct views forward left, forward right, left, right, and all returning to front on release). Can you tell me what FS controls are programmed on your hat? You can do this easily by enabling Event logging in FSUIPC4's logging options, then using the hat and checking the FSUIPC4.Log file. You could also see if you get the same effect when using the keyboard. I think the Shift+Arrow keys should give the same results. I am pretty sure the view controls operate differently in 2D panel mode compared to VC mode -- that was also true in FS9 -- unless you set "pan_in_cockpit_mode=1" in the [Controls] section of the main FS CFG file. Maybe there's a bug in FSX which is changing the way the controls operate when the ATC window is present? Seems a bit odd. Certainly there's no way either PFCFSX or FSUIPC4 knows that the ATC window is open and they therefore won't be actually changing the way your buttons operate. If you can confirm now you've programmed this hat (if it isn't the same as my rockers) I'll look here to see if there's any workaround, or whether it needs reporting to MS as a bug. Regards, Pete

I understand that, but until Microsoft can come up with a fix for Simconnect that gets around all these problems, assuming they case, it looks like the only way is to uninstall then install one which is reported to work. certainly, for a firewall, the default WinXP one works. For Antivirus I know norton works (I use it myself), but there appear to some freeware ones which work too -- AVAST and AVG are two mentioned in the threads, though i think you have to do something with the privacy settings in AVAST. No. It seems that in many case the way the hooks are implanted in the system does the damage. Maybe there are settings in the individual products that would alleviate or even cure the problem, but it's all a bit hit and miss till we get some guidance about what is going on from Microsoft. Although the workaround for the joystick delays in FSUIPC4 may suit you at present, there will be more and more products using Simconnect and some of these are going to suffer with similar problems too. In a sense you are lucky only having the slow joystick symptom, there are those where Simconnect simply blocks (doesn't work at all) and even the one that crashes to the Blue Screen Of Death as soon as you start FSX. Regards Pete

Must be some sort of clash on startup. Regards Pete

You can do that anyway, in either of two ways: 1. Undock the FS window, and drag it to wherever. The font colour and size can't be changed this way though. 2. Run the free utility "Showtext" which you will already have, as it was part of the Advdisplay ZIP. That does allow many more options. Actually, that reminds meI need to make ShowTest available for FSX users in the downloads above. Thanks, Pete

There's no fix at present as it either needs something doing in FSX's simconnect to get around the assorted vagaries of third part security software, or for everyone to uninstall their security software and use only proven working products (working with simconnect, that is!) What anti-virus, firewall and privacy software are you using, and have you tried changing its settings or even uninstalling it? Temporarily I made a work-around in FSUIPC4, which unfortunately also stops you using it for joystick calibration, and that change will be included in the next official version, 4.02, this weekend. I'm busy putting it together now. Please check the Schiratti "Dowson" page later tomorrow, or maybe Sunday, latest. Then, edit the FSUIPC4.INI file. Add the line: NoAxisIntercepts=Yes anywhere in the [General] section Regards Pete

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