Pete Dowson

Whilst I cannot agree that it makes ActiveSky impossible to fly with (it still improves on the default weather), this is a known bug in FSX which I reasonably expect to be fully addressed in the forthcoming SP1 update. FSUIPC4 is dependent upon facilities being fixed and added in FSX. I have full intentions to deal with all the weather issues as I can, but the state of the weather control system in FSX's initial release precluded anything further being done at that stage. I don't know, yet, how much more I can do with the SP1 updated version, but I will do what I can and continue to press MS for further changes where needed. Regards Pete

Yes, there is a general consensus that it was released far too early. Hence MS's unusual step of actually promising and working on a bug and performance fix update so soon. Oh, I don't think that is right. It is under continuous development simply becasue (a) it sells well, despite all the problems, and (b) there is always something better which can be done as hardware performance and capabilities improve. You only have to view the different versions over the last 20+ years to see that. I really don't think this will specifically be FSX. The calibration and axis system used in FS hasn't changed since FS2000 days, when they switched to direct input. If the "dead zone" is not truly dead (and you can surely check that in Windows Game Controllers) -- in other words it is actually giving changing values -- then FS (including FSX) will respond to those changing values provided the dead zone setting in FS is set minimum and the sensitivity is set maximum. There is a tendency for FS (FS9 and FSX, and probably earlier too) for the sensitivity to be set far too low and the dead zone possibly too high in FS's settings. Always check those. If you are assigning axes in FSUIPC (as opposed to only calibrating FS's assigned controls), then, yes unless you want the axis to do two things -- whatever FS is told to do and whatever you tell FSUIPC to do. The same applied to joystick buttons. FSUIPC cannot stop FS reading the joysticks itself. Only you can do that by de-assigning axes and buttons or disabling the joystick altogether. I can't really say. Yes, you could do it all via FSUIPC and disable joysticks in FS. That does actuially save having to worry about FS suddenly auto-reassigning axes just because it thinks they are new. The joystick enable/disable doesn't get changed automatically. However, you'd really need to have sufficient reasons for wanting to do it all via FSUIPC in the first place. Different real axes for different aircraft is the main application, the only real thing that can be done with FSUIPC which cannot with FS directly (except possibly in FSX, where you can save and reload different configurations -- but I've not checked if those change joystick assignments too. Might be worth a look?). The axis assignments facilities in FSUIPC are a very recent thing. For its first 6 years the Joystick Calibration facilities were well used, and no one really missed being able to actually assign them in FSUIPC. It was really explicitly for the business of supporting, say, a helicopter control set and a prop/jet control set on the same PC, automatically switching according to the loaded aircraft, which was the spur to the facilities being added. In that case I would extend "fatally" to include a hardware input which is either constantly jittery or which has inconsistent areas in its range of movement -- either due to faults (e.g. dirt in the pot or dry joints.bad wiring) or interference. Additionally, as far as all my testing and understanding of FS's axis treatment is concerned, I believe that, if the axis values are genuinely changing, and the Windows calibration is good, and the dead zone and sensitivity parameters are set correctly in FS, that the resulting internal control values for the assigned axes must also be changing. Possibly, but it would be far better to fix the reason for the noise -- switch cleaner or something, maybe? FS's sensitivity of course isn't related to noise, the latter will be dirt or interference or faults. FSUIPC's filtering is very simple and not extensive. There are some really good filtering algoirithms I could apply, but these depend on building a history of inputs and using this to spot inconsistencies and nullify them. The end result, when done linearly, as necessitated in such a program, is less responsiveness in the controls. The better/stronger the filter, the worse the responsiveness. Believe me, I experimented a lot before including the facility as it is, and you wouldn't like the really smooth results at all. I really don't think that there any such decision made. The calibration of axes is done in Windows before FS ever sees the values. The calibration in Windows is designed to assure a specific range. This is then simply mapped onto the range accepted in FS for the specific control type, typically -16k to +16k for a centering control and 0 to +16k for things like the throttle, spoilers, brakes and so on. The modification to the accepted range which you might observe is caused by applying a dead zone and a sensitivity, both adjustable with sliders in FS. For full range you always need the sensitivity sliders set to max (full right) and the dead zone set to zero (full left). I'm actually quite surprised how good the FSX 737-800 is, considering the 737's in all previous versions of FS were pretty dire. However, its overhead functions are very poor and unrealistic, its engine start-up and shut-down procedures are woefully wrong, and, possibly, yes, its response to controls is still not as good as it should be. In FS2004 I don't think you could beat the PMDG 737s, and I have actually installed the PMDG models and CFG files into fSX --- I don't use any FS panels in any case, being a 100% Project Magenta user. Regards Pete

In FS2002 and FS2004 offset 0D0C is actually mapped through to the real lights flags in FS's own data. FSUIPC doesn't interfere with them, but it does read them to populate the old FS98-compatible offsets at 0280, 0281 and 028C. In FSX, FSUIPC4 assembles the light states from a series of 10 separate BOOLEAN on/off indications from SimConnect. Those indications only arrive, individually, as they change. Either way they should always correctly reflect the state of the actual switch in FS -- although this may not be the same as the state of the lights themselves, depending on how sophisticated the aircraft modelling is with regards to electrical subsystems, generators, fuses, battery switches, etc. They can use the "Monitor" facility, monitoring 0D0C as a U16 in hex, to AdvDisplay for real time viewing on screen, and, at the same time to the normal log so you can see it too. Get them to do simple tests, a known sequence of switching so that you can check it. If you log IPC Reads too, you can relate what you read to the states Monitored. No, not at all. But when you do have some information I will be glad to help analyse it. Regards Pete

Great! Thanks for letting me know. Odd about the modem, though. Regards Pete

Okay, thanks. I'll release it now. Pete

Then either (1) there are two controls for the elevator, conflicting with each other (for instance, make sure there's only one assigned in FS, and also make sure that the flight controls are disabled (not checked) in the Flight Controls tab of PFC.DLL, or (2) there is a fault with the elevator axis on the yoke, in which case it needs repairing. Does it flutter in the Game Controllers test or calibrations screens? If not, then something is interfering with it. Minor jitters can sometimes be eliminated by FSUIPC's filter facilities, but not a real flutter, and certainly not if the cause is actually down to two separate inputs competing to control the elevator. No amount of calibration cures flutter -- it's going to be a hardware problem or conflicting inputs. Try you other joystick as elevator, disconnecting the problem one. If that gives no flutter, connect the original one but deassign it. Does the other give fltter now? Then re-enable the one you normally use and disable the otherand so on. By a process of elimination you should be able to determine whether it is faulty hardware or conflicting inputs. Also be aware that not all USB ports are the same. First of all the ones on the PC are in pairs. Check whether the other of the same pair is connected to something which might interfere. Try swapping that out to another USB port. Second, if you are using a USB extension cable, maybe the voltage drop over it is too much for the device. Try a shorter one or a better quality one. If you are using a hub, make sure it is a powered hub. Regards Pete

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