Pete Dowson

Well, it doesn't! That's for certain. To start with, a really wrong Key would be rejected in the first place -- you wouldn't have been able to enter it! It would fail the basic checks. Since version 3.53 of FSUIPC, the only type of key which can cause things to go wrong later are those which have been made by one of the Pirate Key generators around. These look like valid keys to the entry-checker's processing, but are wrong enough to corrupt the decoding of the interface data. The fix is simple: just delete the FSUIPC.KEY file and re-register, entering only legitimate, non-pirated, keys. There is no re-installation of anything at all ever needed, as no permanent changes are made. The only result of the bad key is bad data supplied to FSUIPC client applications. Regards Pete

Your FSX and FS9 installations are separate. You manually install FSUIPC3 into FS9, without touching FSX. The FSUIPC4 installer for FSX knows nothing about FS9, and installs only into FSX. So the two are completely separate. In short, you can do what you want. Regards Pete

:roll: !!!? If you would please consider using separate paragraphs so it is readable, and make separate points, explained separately, it might help understand what you are complaining about. You certainly seem to be mixing up lots of things -- my PFC support doesn't include the USB-connected yoke, for instance. PFC.DLL only deals with PFC devices with the digital control electronics, so probably your Throttle Quadrant is via PFC.DLL, but certainly not your PFC yoke if it is connected directly to USB. That is more like a normal joystick and is dealt with via Game Controllers and FS assignments. It seems like most of your problems are down to not having calibrated the yoke in the correct place? If there's no yoke nor rudder plugged into the PFC throttle quadrant, do NOT enable the flight controls in PFC.DLL. I've no idea what rudder you are using though, except that, as you say, you have two assigned at the same time -- a sure recipe for trouble unless one of them is kept totally silent (jitter free). On the other point which I can vaguely make out from what you say, if you don't understand FSUIPC, then why did you try using it in the first place? It isn't the place to start getting your kit to work! Please consider setting up your normal joysticks and yoke using Windows Game Controllers, and Flight Simulator itself. After all, Windows and FS between them are actually supposed to support these things directly. FSUIPC is not a necessity, far from it. FSUIPC won't fix things which are wrong in the first place. Please get your kit working using the standard methods, following their documentation, then, possibly, consider using FSUIPC to refine the settings and making more flexible use of them. Never start the other way around -- if things plain don't work in the first place, FSUIPC cannot fix them. Regards Pete

Excellent detective work! Thank you! I think I have fixed it in version 1.24: http://fsuipc.simflight.com/beta/GFdisplay124.zip Please let me know before I release it generally. Thanks! Pete

Please look at the FSUIPC.LOG file, in the FS Modules folder. Does it show any errors? Run FS again, close it down, show me the Log, all of it. Regards Pete

Hi James, Phew, you are stretching my memory nowthat stuff is many years old! ;-) FSUIPC3 still includes code for reading buttons direct from the EPIC.VXD I wrote in the FS95 days. Unless you are still using WinMe or earlier then that's not active. Oddly FSUIPC4 still has that code in... even though FSX only runs in WinXP SP2 or later, which cannot support EPIC.VXD! Thanks for reminding me... that's one chunk of code that can come out! ;-) WideClient has the same code, still relevant for FSX because folks can be using old Win98 PCs as clients. ButEPICINFO? It doesn't actually contain any button reading code of its own now -- hasn't for a long time. It is dependent upon FSUIPC, calling a routine there to get button states (and they don't have to be from EPIC). Long, long ago, when EPICINFO was independent of FSUIPC it used to read them from the VXD. Of course, as far as AXES are concerned, EPICINFO provides the option to read stuff via the VXD or R&R driver (EPICIO.DLL), or only through Windows (HID), or even both. This part of the doc is relevant: Does this help? Regards Pete

Well, they aren't updated by FS as fast as they could be, and the DME values are actually provided in FSUIPC as strings, rather than as floating point values, so the change I made may not actually have any affect -- though it depends on which offsets you are using. Can you show me the INI file, maybe that may give me a clue? Perhaps you can, as a test, try the same values we were dealing with earlier -- i.e. the heading (gyro or whiskey compass, it doesn't matter which). The main puzzling thing in your report is that the LEDs don't work, which is in such a separate part of the code (compared to the little bit I've been changing) that it isn't really making sense to me at present. Sorting out whether the difference is the UNIT (166 vs 46) or value type (floating point like the headings vs. other types) would be a help to start with. Thanks, Pete

No, sorry. I've not made any changes other than the ones discussed above, and the different GF units are not treated any differently from each other. Certainly nothing that has been changed goes anywhere near LED indicators in any case. I'm afraid I have no way to debug these things as I don't have any GF displays. If there's nothing you needed out of the newer version, I'd stick to your earlier one if I were you. Sorry. Regards Pete

Thanks for the log. This shows that both "FS Earth" and "Recorder" are initialising all their data requests (and for the Recorder that is a huge number) right at the start, whilst other programs are being loaded and well before FSX is actually in any fit state to supply that data. This is very dangerous. Even if it did not crash FSX when some security or other check on loading arose, it has been known to have later odd effects in FSX, possibly resulting from corruption at this early stage. They are both doing all this at the same time as FSUIPC4 is being loaded, so I am pretty sure it is one of them causing the crash. I hope this is something which is, indeed, sorted out in the upcoming SP1 update from Microsoft, as they have known about it for some time, but I also think you should point out to the authors of these two programs the possible problems they could be causing their users. The fix is relatively easy and painless. They should only ask SimConnect for a "Sim Start" event first, and issue all their other data requests after receiving one of those. By all means copy my comments and send them the SimConnect log, in case they do not fully understand this need. AutoThumbnail does ask for the SimStart event, but oddly also asks for the only data it is interested in (the aircraft title) before it receives the event. Not being a big data requester, it may or may not be a problem. I can't tell from the log -- it did this well after FSUIPC4 was fully loaded in any case. FSForce is, however, very well behaved, like FSUIPC4, and waits till receiving a "SimStart" notification before initialising any of its data requests. For your current dilemma, I recommend you temporarily stop FS_Earth\fs_earth.dll L:\FS X Downloaded Files\FS X Recorder\RecorderFSX.dll from loading (just rename them for now), get FSUIPC 4.088 installed (and Peter L Dowson trusted), then re-enable those afterwards. Regards Pete

Okay. It looks like you have several other add-ons which are being loaded when FSX loads. One of more of those is attempting to initialise its data requests from SimConnect before FSX has really started properly. There are two different ways of finding out which one or more. First is to get a SimConnect log -- instructions for doing that are found in my FSX Help announcement at the top of the forum. Just enable the logging, start FSX in your normal way (but with FSUIPC4.081 of course), and when FSX is ready to fly, close it. ZIP the simconnect log and send it to me at petedowson@btconnect.com. The other way is a process of elimination, stopping each of your add-ons from loading, in turn, until you can run with a new 4.088 without a crash. For this, save your 4.081 and copy the 4.088 DLL back into the FSX Modules folder. Then, looking at this list of add-on mdules FS_Earth\fs_earth.dll (presumably this is in the FSX folder) L:\FS X Downloaded Files\FS X Recorder\RecorderFSX.dll L:\FS X Downloaded Files\FSForce\FSForce.dll L:\FS X Downloaded Files\FSForce\FSForce.exe L:\FS X Downloaded Files\AutoThumbnail\Autothumbnail.exe L:\FS X Downloaded Files\WheelCam\Wheelcam.exe temporarily rename or, easier maybe, move, each of those in turn, so they don't load, checking FSX loading (with 4.088 installed) each time until you get the prompt correctly and no crash. Once that is okay, make a note of the last one disabled, then look for the drop down which allows you to say you trust Peter L Dowson. That will at least stop this happening, with my new versions, in future. Please let me know which module it was (or all of them, possibly ...?). Do you rember which of the above were installed BEFORE you installed FSUIPC 4.081 originally? Which one of those above did you install last of all? Probably, for me, the best information would be the SimConnect log. For you the process of elimination will solve your problem, for now. Regards Pete

Ah. There's a little drop down menu you can access from that prompt which allows you to say that you actually trust software signed by Peter L. Dowson. If you do that it will never prompt you again for any legitimately signed programs from me. This will be before FSUIPC4 is even entered -- if you get that prompt it is crashing in FSX before loading FSUIPC4. There's really nothing I can change in FSUIPC4 which would make any such difference, simply because it isn't running yet! The only thing I know which has happened which is anywhere similar to that is actually caused by a bug in FSX which can crash it exactly where you say, if (and only if) something was trying to initialise SimConnect at exactly (and I mean exactly) the same time as that security prompt appeared. When it was happening before it was when FSUIPC4 was loaded okay but some other (unsigned) program was loading and causing the prompt. I got around that by making FSUIPC4 wait and not try to initialise SimConnect until much later -- generally 10-20 seconds into the loading sequence, when SimConnect has signalled a "Sim Start" event. That's simply because the prompt is suppressed, not by you having said you trusted my programs, but because when you answered "Yes" before, FSX entered details of that version of FSUIPC4 into your FSX.CFG file. It will keep adding stuff there each time you say 'yes'. If that's all you installed between installing 4.081 (and getting the prompt) and installing 4.088, then it must be one of those. Do any of them start automatically with FSX, do you know? I may be able to help identify the culprit (it needs tackling if possible) if you could find these two files: EXE.XML DLL.XML which, if they exist (DLL.XML certainly will), will both be in the folder where your FSX.CFG is kept. i.e. Documents and Settings\\Application Data\Microsoft\FSX They are text files, so just paste them into your reply and I'll see what can be done, at least until Microsoft fix the bug (hopefully in the SP1 update). It sounds like, to use any new version at all, you'll need, temporarily at least, to stop one of your other installed programs from loading. That's what I'm trying to help identify. Regards Pete

Of course, because 4.088 is a later version!! If you want to go backwards (and have no support after it is released as 4.09 later this week), then you will need to delete it first. FSUIPC's installer does not let you overwrite a later version -- that was a big problem with too many automatic third party installers in the past! BTW what was your "previous version"? There is a problem, long ago avoided, as we thought, by FSUIPC4 and FSUIPC4 installer changes, with SimConnect and the Security checking for other (unsigned) programs loading at the same time as FSUIPC4's initialising. This problem is known to Microsoft and hopefully is fixed in the upcoming SP1 update. However, it only occurs when you have more than one SimConnect client loading initially (presumably via DLL.XML or EXE.XML additions), and one of them forces the Security warning confirmation dialogue. Is that your case? What other SimConnect clients have you got installed? Regards Pete

Er .. have you never simply told Windows that you accept software signed by me? Then you will never ever get that so-called "usual" popup again from any of my updates! Sounds like you have a corrupted copy, it works fine on all the test sites and has been fully tested. Regards Pete

Great! I'll release it generally now, then. Thanks, Pete

Okay. When you can, please download GFdisplay 1.23 here: http://fsuipc.simflight.com/beta/GFdisplay123.zip and let me know if this fixes the problem. Thanks & Regards Pete

I've done that, I guess I don't know what you need for feed back.When I used D30, there was no change unless I had a turn rate equal to 15º bank. D31, less bank required about 8º D32, Even less bank required, about 3º. D33, Even less if any. Okay, that's exactly what I needed to know. I know where to look in my code now. It proves that it is an original bug in GFdisplay. ;-) Regards Pete

Well, the latter must be a function of FS, reducing vibrations to near zero. But unfortunately this is not really a comparison with your previous results, so it isn't useful. Please do the same tests each time, one with D30, one with D31 then D32 then D33. If it's a bug in GFdisplay, due to something about the way it is checking the changes, this should give progressively better results -- i.e. less heading change needed for each increment in display sensitivity. Okay, so FS simulates smaller and smaller vibration effects. Nice. It sounds like an original bug in GFdisplay. Just confirm, please, with your original banking tests then I'll start dry-running the relevant bits of code. It'll be tomorrow now -- it's 01:15 am here. Not sure what to make of your subsequent three short messages, sorry. I can't get them to jibe with anything else. I just need reports of results on your bank testing with the four different precisions. I am expecting you to tell me each one is progressively "better" (i.e. less change needed to register). I'll assume that if I don't hear from you. Regards Pete

Well, the latter must be a function of FS, reducing vibrations to near zero. But unfortunately this is not really a comparison with your previous results, so it isn't useful. Please do the same tests each time, one with D30, one with D31 then D32 then D33. If it's a bug in GFdisplay, due to something about the way it is checking the changes, this should give progressively better results -- i.e. less heading change needed for each increment in display sensitivity. Okay, so FS simulates smaller and smaller vibration effects. Nice. It sounds like an original bug in GFdisplay. Just confirm, please, with your original banking tests then I'll start dry-running the relevant bits of code. It'll be tomorrow now -- it's 01:15 am here. Regards Pete

I did, that's what this is... Ah, so that proves it isn't the variable but either a GFdisplay bug or GFDev.DLL. The other tests should show which ... The latest, but they've screwed up other stuff, so I'll look for an older one. There's an older one in the "Other downloads" announcement above. Regards Pete

Previous version of... GFDisplay I assume since FSUIPC wouldn't be looking at x2B00? Of course. FSUIPC is certainly okay. The variable at 2B00 is changing continuously when I turn, in FS2004. I've checked this using both the FSUIPC monitor (Logging page, right-hand side -- select "Advdisplay" option for real-time on screen updates) and using FSInterrogate. So it has to either be GFdisplay, or possibly the GFdev.dll. I wouldn't know if the problem lies with the bank angle (why would it) or the rate of turn, or even the rate of bank, but... Please, can you check it with the whiskey compass? I am going through a process of elimination. For all the values it's just a simple comparison of previous displayed value to the current value, to the number of fractional places you specify, and a half (i.e. greater than 0.5 difference for zero fractional places). By all means, try increasing the number of fractional places -- if displaying it as D33 "fixes" it, try D32 and D31, see if each needs a faster and faster rate of change. If so it points to something wrong in the way I'm storing the "previously displayed value". Okay. Good. I've not messed anything up in GFdisplay, then. If it doesn't update with 'slow' changes here, maybe it doesn't with any displays of anything? Maybe it's a 5 year old bug and no one has ever noticed? It needs testing with other variables, like the whiskey compass and so on. Please. Also, maybe its a problem with GFDEV. Try different versions of that (are you using the latest or an older one?). Regards Pete

Seems that GFdisplay isn't working properly at all then? I may have to withdraw it if so, as there's no way I can debug it here with no displays. Could it be I messed it up with my alignment changes? Can you test with the previous version? Can you also test with the Whiskey compass instead, just to make sure it isn't something strange with the FS value rather than GFdisplay? (Though if it was I don't see that re-writing the INI would magically "fix" it). Pete

Hmmm. That's strange. It shouldn't have a problem keeping up then. I'm afraid I'm at a bit of a loss on that. Did you get the same thing happening when you tried using the whiskey compass? Pete

No, sorry. The 2B00 offset is updating normally,, at the same rate as most of the other fast-update stuff in FSUIPC, and it certainly says it's the gyro compass value. If the FS panel gyro compass display isn't suffering then the problem must be that GFDisplay is not getting the processing time. A dual core CPU should fix that. Not sure how you'd do it in your PC. Regards Pete

I've just checked, and it looks pretty easy to add it to FSUIPC3 (for FS2002 and FS2004 only, not FS2000 or CFS), so I'll do that in the next increment (3.732) which I'll post in the "Other Downloads" announcement above, probably later today ... Regards Pete

It's a one-off purchase fee, per version. There are two separate versions - 3 for FS2004 and before, 4 for FSX. Please check http://www.schiratti.com/dowson where you can download the version you are interested in, and browse the User Guide which explains all. On that website there are also links to the place where you can purchase them. Prices and offsers are shown there. Regards Pete