Pete Dowson

Strange, that's the exact reverse of the experiences of MELKOR in the other main active thread. with his tests it is always smoothing on descent but he gets the wild fluctuations on ascent. Unfortunately MELKOR has no logs for me yet. But I see you had my full logging enabled. Can you ZIP up the FLT files and the Log and tell be roughly what FS time it was then the shifts occurred, please? Send to petedowson@btconnect.com. Only the files. We'll keep the discussion here. I'm uploading 4.238 later today, with some code tidied up and made more protective, though I don't think there's likely to be much different in how it smooths. I can't see any answers yet. It is annoying not being able to reproduce the problems here. Regards Pete

No, I've almost reached the give-up-and-do-something-useful point. Unfortunately you have none of my smoothing logging on, using the INI settings listed in the FSX Downloads announcement, so although you can clearly reproduce the problem (which I've not managed to yet), I still have no information telling me why my code is doing wrong which is allowing it. Do you think you can repro the problem with the logging enabled as requested? Best now wait for 4.238 which I shall have ready later today. I'm doing some tidying up, nothing radical, but I'm also attempting to make the code more protective, to stop the crashes one tester is experiencing. Regards Pete

Seems that all this effort has been a waste of time so far then -- those events are exactly what I set out to conquer, and we are still getting them. And I don't understand why. I cannot repro them at all. :-( This is such bad news after things were looking so good. I could cry! :cry: :cry: :cry: Pete

Great, but what's a 100 ft of wind? ;-) Pete

Hmm. That is worrying. It is indicating a possible problem in my code. I will go through it with a toothcomb, checking where there might be a loose reference to an internal FSX variable which may have moved. The problem is that if I add too many checks it affects performance. I tend to look for workable compromises. But I can't allow crashes! I don't really think ASX can directly cause the crashes, though I suppose it could indicate a bug in FSX's weather processing. However, I'd expect it to be more widescprad and especially not suddenly start occurring when I add complex code! Okay. Thanks. Best try such a different route with it on again too. Best Regards Pete

I've flown from the FLT files you sent, with no crash. I note from this Log and the previous one you sent that the crash both times happened more or less in the exact same Geographical spot, somewhere North West of Boise, Idahoperhaps 30 nm away, maybe more? Something close to N44 40 12, W117 25 48. Are all your tests which crashed following the same route? Could the crash be down to something in the scenery or terrain or textures/Landclass in that area? I'm not getting crash reports from others with these last two FSUIPC releases (so far, at least), so I'm looking for plausible alternative explanations at present. NOTE: I just noticed that one of my latest modifications, the addition of the wind smoothing thread, isn't disabled when you switch wind smoothing off. This might detract from the value of smoothing-off tests to see if FSUIPC is causing your crashes, though I hope not. After all it was crashing before I added that new bit. Anyway, I'll fix that ready for tomorrow's inevitable update! ;-) Regards Pete

A program to read both axes and make some sense of them as one axis, with the result being fed either directly into FS or via FSUIPC. I just had one other idea which may work. You could assign one pedal as the rudder axis in FS, but reverse it there. This is one of the facilities in FS, I think. You can calibrate it in FSUIPC as the rudder. And assign the other pedal to another FS axis, one you don't need for anything else at all. Find out the control number for it (there's a list of FS control numbers installed in your FSX Modules folder). In the FSUIPC4 INI file add this line to the relevant [JoystickCalibration] section(s): RudderB= where you give the control number of the control you assigned. (This is part of the "multiple joysticks" facility described in the back of the Advanced User's guide). Now both rudder axes are assigned to the rudder but one of them is being reversed in FS before FSUIPC sees it. Best to make sure both are well calibrated in Windows before doing this, and both have null dead zone and max sensitivity settings in FS. Then also calibrate both in FSUIPC -- one to give max deflection one way and the other to do so the other way. Best to give them a decent centre zone. And choose a slope to give you best control, to taste. Regards Pete

But the "fix" is just the Installer providing the Registration dialogue, or an option to re-register if you already have a correctly generated KEY file in the Options folder. The Installer automatically has "elevated administrator" status by virtue of having a name including "Install". I think names including "Setup" get the same privilege. A bit simple-minded really when you think about it -- all that claptrap stopping you doing things only to have easy names to get passed it all. So, I'm rather worried there's more going on with your system than meets they eye. Perhaps you should show me the FSUIPC4 Log file and the Install Log, both from the FSX Modules folder? You can paste hem here. I'd like to check them just in case there's something else I can spot. It might also be of interest to see if renaming FSX.EXE temporarily as Install FSX.exe and running that not "as administrator" gives it the needed privilege. Maybe Vista also checks the internal (resource-based) name too, though, to stop such simple tricks. Regards Pete

Yes, all smoothing. Pete

Er, the GF ATC Module? OhI don't recall supporting this ATC module in FSUIPC. I've certainly no idea what it does. Let me check my code: ... ah yes. It is mentioned! Wow! It gets a normal dial value, like the rotaries on a GF46 or RP48. That should give you up to 4 button numbers, fast counter-clockwise, slow counter-clockwise, slow clockwise and fast clockwise. Also up to 4 buttons or switches? Is that right? I've never actually seen one. So, how are you wanting to use it in FSUIPC? Obviously GF's own driver simply sends the keypresses. But for FSUIPC you don't have ten buttons 0-9, what you have is 4 buttons telling it what the rotary is doing, then some additional buttons. I must admit I'm confused. If you want to use it for its original purpose why aren't you using the GF facilities? If you want to use FSUIPC then I assume you just want the rotary as a rotary and the buttons as buttons. How does that relate to ATC? Regards Pete

Well, yes, I did have such layers, though often they changed before I got there. I finally realised I had the Options setting for weather changes one notch off the "no changes" mark. Even so it was uncanny how most of the winds "sorted" themselves into more reasonable setting before I got there. Maybe it is related to where in the workld I am. I'm inclined to put the aircraft mid-Ocean and create weather using the user-defined global facilities. However, I did actually managed to slew up and down fast enough through some very large changes in wind direction, and the smoothing still worked, so I'm puzzled. Evidently not so bad where I am. Can you give me an airport ICAO ID for such reliable misfortune, please? ;-) The first report (see the other recent threads) on 4.237 seems to say that these shifts may be fixed, but I'm not holding my breath. Thanks for your help! Regards Pete

Please describe exactly what you are doing. So far 100% of all cases of this problem have been because folks are NOT using the right-click "run as" administrator option. Maybe you are trying to do this on the shortcut, not on the program itself? I have heard of some cases where the shortcut produced does not correctly obey the "run as" command. In case this is the problem, use Explorer and find FSX.EXE in the FSX folder, and use the right-click method on that. It is because of these really annoying aspects of Vista that I am revising the Installer to try and get such matters dealt with there. But that won't be for at least another week. Sorry. Regards Pete

Are you using FSX + SP2/Acceleration? What FSUIPC Wind options are you setting? How does a "speed tape" measure "400 feet"? Do you mean the altitude tape? If you are using FSX without SP2 or Acceleration then the main result of any of the smoothing options is "jumping" of the values at regular intervals -- the intervals are probably dependent upon the smoothing values, but most usually, for the ASI / Wind speed, they would be every second. Sorry, but there really is no way what FSUIPC is doing can cause the PMDG that much confusion, not unless it really has some serious bugs. To start with its ND's wind vector is derived from exactly the same values which would be displayed when you press Shift+Z. No wind vector means no wind. Did you check? Thanks for the offer, but without more information I wouldn't know what to look for. If you are not using SP2 / Acceleration, as it sounds from your report, then I suggest that you disable all the smoothing options. If you are using SP2 / Acceleration then perhaps I need to investigate the "400 foot jumping on the speed tape" (), but maybe we should clarify that first, please? Thanks, Pete

Well, there's nothing wrong with the SimConnect installation. You could show me the DLL.XML file, from this folder: C:\Documents and Settings\Dave\Application Data\Microsoft\FSX\ The only reason to look at that is to see if there are any other DLLs being loaded which could be responsible. One other question. Are you using FSX RTM, SP1 or SP2/Acceleration? If you've installed SP2 or Acceleration you are aware, I hope, that this renders a lot of FS9 aircraft incompatible? I seem to recall from somewhere else that one of the symptoms is disappearing gauges or holes where they used to be. I really can't understand, however, how any of that relates to whether FSUIPC is installed or not. Regards Pete

That's good, thank you. Very encouraging! That is a big worry for meyes, please send the files. Please include the PMDG files as I mentioned too. Well, maybe, but the coincidence of it happening whilst doing these tests does not sit well with me. Perhaps, if it looks like we've conquered the main smoothing problems (I'm still waiting for reports back from PMDG as to what might be the problem with the heading drift in turbulence), you should return to having wind smoothing disabled for a while. If you get no FSX crashes on several successive flights then I think you might agree it must be something to do with the smoothing? Let me know, please. Best Regards Pete

Are you using Vista? Did you read the Installation section of the User Guide? Perhaps you missed the important point emboldened and in red in the section entitled "Next … running FSX. But read this first"? You need to take specific action when registering with Vista. In the next update of the Installer (before the end of this month, for sure) I am adding registration facilities to the Installer, so this will be taken care of better. As it is at present, however, Vista's over-protective nature really means lots of complications which weren't there before. Regards Pete

Hmm. For one add-on to mess another up is quite unusual. It does seem as if the IFly installation does alter something more fundamental in the FSX installation than its own gauges and textures. For the presence of FSUIPC4 to be making any difference when you are not flying the IFly I think there must either be something messed up with SimConnect (the interface used by FSUIPC4 and other FSX-specific add-ons), or there's some other gauge which is common between the IFly and your other add-on aircraft. and that is where the problem still lies. Since the IFly aircraft is a port over from FS9 I don't think there will be any other DLL it is using and loaded via DLL.XML, though that still might be worth looking at. If you like, just to be sure there's nothing wrong with the SimConnect side of things, I will examine your FSUIPC4 Install log, and the latest FSUIPC4 log file -- you'll find both in the FSX Modules folder. Best to re-run the FSUIPC4 installer first, please, and then load FSX and close it after seeing your problem. You can paste both files into a reply here. Regards Pete

I've been trying to make things go wrong doing this, but I can't seem to get the same results as you. Tell me, what is your weather source when you do this? Are you manually setting up some nasty shifting layers? After thinking about that for a while, I've made two further changes to try to nail this: 1. I've resurrected my "wind smoothing thread", which I didn't think would be needed now that I am hooking into what I thought was the right place in WEATHER.DLL. This thread attempts to re-write the desired winds up to 200 times per second. I want to see if this stops these directional swings. 2. I am now automatically doubling the WX station METAR reads and corrective writes during times when the number of temperature or wind layers at the aircraft exceeds 15. I am hoping this will avoid a build up of such layers, many of which are spurious and unwanted. The problem with both of these changes is that they may impact performance, and I really can't have that happen, at least not noticeably. The thread one may even be a little dangerous, although again I've taken steps to prevent it accessing stuff when it shouldn't. I can't make it crash at all here. I am testing FSUIPC 4.237 right now and will upload it soon. Thanks Pete

OkayI see it in the Log, but I cannot reproduce it. I can only think it is related not to static weather setups in saved WX files, but dynamic weather -- were you getting weather from ASX or FSX downloads? Anyway, I've found I need more files in any case for the saved FLT + WX + FSSave files, when you fly PMDG. There are other saved files in the PMDG\747400\PanelState folder. They'll have the same name (eg "AutoSave ...") but types .flt.sav, .flt.0.rte, .flt.1.rte (etc). So that I can fly exactly as you did, could you include those too next time, please? Nothing helpful regarding any sort of crash. This is a bit worrying. I know you think it may not be FSUIPC, but I'm definitely a bit worried that I've not got enough checks in place to make sure the weather variables I'm writing are always there. I've examined it very carefully and can't see where an error could now occur, but it is still worrying. From your email: I suspect that all that is happening is that with a locked frame rate the weather routines are given more time to screw things up! I am testing FSUIPC 4.237 right now and will upload it soon. I've made two further changes to try to nail this: 1. I've resurrected my "wind smoothing thread", which I didn't think would be needed now that I am hooking into what I thought was the right place in WEATHER.DLL. This thread attempts to re-write the desired winds up to 200 times per second. I want to see if this stops your 39000' swings. 2. I am now automatically doubling the WX station METAR reads and corrective writes during times when the number of temperature or wind layers at the aircraft exceeds 15. I am hoping this will avoid a build up of such layers, many of which are spurious and unwanted. THe problem with both of these changes is that they may impact performance, and I really can't have that happen, at least not noticeably. The thread one may even be a little dangerous, although again I've taken steps to prevent it accessing stuff when it shouldn't. I can't make it crash at all here. So, please, if you have time and patience still, try that 39000' test again with 4.237. Thanks! Pete

I think there have been previous reports of problems with FSX's Scandinavian METARs -- a temperature of +65C was reported I seem to recall. Bad data no doubt. No, not required, thanks. I know FSX generates lots of spurious layers. This is the cause of all the problems we've been battling. It was actually pretty similar in FS9, but I had a lot more control there as I managed to suss it out (but it cost me many thousands of hours and I won't do it again). Thanks! Regards Pete

Yes. FSX generates far too many "spurious" wind layers when it is updating the matrix of WX stations around the aircraft (part of the weather dynamics). These in turn make a mess of the interpolation it performs to derive the weather at the aircraft location. As it performs these dynamic changes, the number of wind (and temperature) layers increases. In fact it can get so bad that the METAR strings it generates in its SimConnect reports can exceed the defined Maximum METAR string length (of 2048 bytes I think -- it's defined in the SimConnect header). For some time now FSUIPC4 has tried to fight this by reading the surrounding WX station METARs, removing thin or duplicated wind and Temperature layers, and writing them back. But to avoid a noticeable performance it doesn't do this very often. It cycles through the 9 closest stations (in a 3 x 3 matrix) at the maximum rate of 1 per second (when the value bottom left on the Winds tab is set to 2 -- it would be 1 every 1/2 second if that was reduced to 1). This keeps the number of layers in check, but doesn't prevent all those silly changes. Possibly it makes them a little worse, but I don't think so. That is mighty strange. FSUIPC4 doesn't check or care whether you are ascending or descending. I'll have to do similar tests myself -- I haven't tried doing anything directly like that as I thought the problems were related purely to changes being made from external sources, like ASX. Unfortunately it isn't that simple. The overrides are made in two places in FSX's processing. One is when the Weather DLL is called by SIM1.DLL to provide the local weather. That's a straight-forward hook. That is when I learn the "target" value of the smoothing -- i.e. the value which I need to graduate towards. The same applies to the temperature and pressure (both ambient and sea level). This part I do in FSX RTM, SP1 and SP2. The other is dirtier. I actually have to patch the WEATHER.DLL to perform what's known as a "blister" out to a little bit of my code which overwrites values just before it is about to use them. I only managed to find this in SP2's Weather DLL. The previous version is vastly different. Without this patch the smoothing, when operating to do its job, causes the ASI to "ratchet" (jump up and down) at a regular interval, about 1 sec normally. I suspect the same would happen to the QNH/Ambient pressure (causing the altimeter to "ratchet", and the temperature (causing blips in the engines), but I've not re-checked SP1 since adding those smoothing actions. I have tried having a thread running overwriting these values every n mSecs (n various: tried 1, 5, 10, 20), not caring where in FSX's operations they were. That really didn't seem to help, and it gets very complicated trying to avoid crashes or corrupting other data. It is also then more complicated trying to discern the correct target values to be used. You see, these values do not kindly sit in one place. They are in dynamically allocated structures belonging to a C++ class. They move about! Regards Pete

Sounds like that IFly aircraft messed something up. Have you checked their support? Is this IFly 747 designed or adapted for FSX? If not installing it may have messed something vital up in FSX. Not sure why it is "obvious" that your gauges are dependent upon FSUIPC4. Is this something you just happen to know? I don't. I'm not aware of any FSX-specific products with gauges dependent upon FSUIPC4. And FSUIPC4 itself cannot change the way gauges appear or make them disappear. If it comes and goes with FSUIPC4 it is because something is doing it which is (coincidentally) dependent upon FSUIPC4 and is therefore not running (or at least not doing as much) if it is not installed. No, FSUIPC4 cannot possibly affect such things. What "other" add-on aircraft? FSX ones? If they are all transfers from FS9 then maybe something they are dependent upon has been screwed up someplace. What sounds more likely is that the IFly installation has left some change it made installed even though you think you've "ditched" it. In case it's another DLL check the DLL.XML file (in the same folder as your FSX.CFG file). It could also of course be something to do with textures, though why having FSUIPC running or not should then make a difference I don't understand. That would be one to report to Microsoft. In the end you may find it quicker to do a complete uninstall and re-install of FSX, on the assumption that something has been corrupted by the IFly 747 installation. Regards Pete

This is an activation key for what, exactly? You need to be rather more specific. Are you talking about FSUIPC3, FSUIPC4, WideFS6 or WideFS7? Those are the only programs which I produce which need any Keys at all. What is the actual symptom of it "not working". And did you make really sure you were entering all three parts (name, email AND Key) exactly right? I always recommend cut-and-paste to be sure. You'd be amazed at how many folks don't spell their own names the same twice running! ;-) Don't post any private details here, especially not your Key. Provide some more information, which you surely must realise s needed, and we'll go from there. Pete

WeatherSet2 in its default setting (with no ICAO code shown in the top right section) shows what FSX reports as the weather AT the aircraft. When you are in an location with close WX stations around and about, you will often see clouds, even all around you, but FSX's interpolation doesn't always show them at your actual position. I know , it is extremely confusing (and annoying). As far as I recall, cloud reports in a METAR refer to clouds in view within a 5 mile radius. Or is it more? I am not sure FSX obeys the rule, whatever it is, properly, though it is very difficult to judge how far away the ones you can see are. The only time you can be SURE you have clouds at your exact location is when you can't see anything because of them. Actually, even then, they may just be very thick and prett close. I suppose a top down or straight down view would tell you. Not sure. You can ask WeatherSet2 to display the weather for any WX station -- just put the cursor on the left-most field in the top-right section and press Enter. You can provide an ICAO ID of an WX station (not an airport which isn't also a WX station), or a Lat/Lon for interpolated weather anywhere. To go back to the aircraft location, just do the same but enter nothing. For "GLOBal" weather (the setting that would be used to populate WX stations with no METAR received), use the fictitious ICAO "GLOB". Regards Pete

Hmm. Difficult one. You can certainly use FSUIPC to assign more than one axis to the same control, but the calibration (including the facility to reverse the axis) would be common to both, so you couldn't get one going the other way. So at present I don't see how it is possible without some programming, or some hardware changes (like reversing the pot in one of the pedals, or at least the connections to it). Regards Pete