Pete Dowson

I have good news and much worse bad news, I'm afraid. After fixing the above and trying a real flight with my wind smoothing doing what I intended, I have come to three conclusions: 1. The severe wind shifts are either a direct result of the appearance in WX station weather settings of large numbers of spurious and untenable wind layers, or they are related to that as a parallel symptom. 2. By having FSUIPC read the nearest weather station METARs, detecting the spurious layers (both wind and temperature ones), removing them and writing the result back, most of the occurrences of severe wind shifts are removed. In one complete flight, albeit only 45 minutes, I had only one such shift. In others, before I had this working, I could be assured of many more than that, especially during climb and descent, which I believe exacerbates the layering problem (as you are travelling through them). I believe the shifts that do slip through are due to the impossibility of detecting and changing them all fast enough without killing performance, and also to the likelihood that the three WX stations actually contributing to the conditions at the aircraft are not always found by the simple 3 x 3 matrix of points I use at present. 3. The act of setting the corrected METAR back to the WX station via SimConnect causes a stutter. When several occur close together, you get a severe stutter. The main period of the stutters exactly coincides with the timing of the smoothing scan -- controlled by the 1-30 value on the Winds tab in FSUIPC4. (For FSX SP2/Accel, value 1 = 500 mSec, Pre-SP2 value 1 = 1 sec). Conclusion ======== I'm afraid (3) above is a killer. I'll provide FSUIPC4 version 4.174 after a final test flight, tomorrow morning perhaps, but it will have the "change FS own weather" option clearly marked as causing stutters. The facility will, at present, merely be a demonstration, not, in my opinion, a usable feature. At least all this work has given me a lot of "ammunition" in discussing the whole mess with Microsoft. I just hope I can make some progress. If I can think of any other way to pursue our goals here, I will undertake them when I can. As a very last resort maybe hacking into the FSX code is going to be necessary, but this is not something I am inclined to do, and it certainly won't be this year. Please lookout for 4.174 if you want to try things out further despite the likely drawbacks. Regards Pete

FSInterogate is an aid, you should certainly not be using that as a reference! Please always refer to the Programmer's document in the FSUIPC SDK. If you'd checked there you would have found this, regarding the PayLoad weights: These loadings can be changed, and this does have some effect, but such changes are not being promulgated to the overall weights (offsets 30C0, 30C8, 3BFC) nor balance (2EF8), and it looks like they have to refreshed, as FS overrides them from time to time. It has also been reported that FS can crash if a lot of changes are made here, so care and full testing is needed. I think this is why they are marked as "read only" in FSI -- it's a safety matter. By all means experiment, but I think the problem is that no one ever found the right way to tell the rest of FS to take proper note of the new payloads, at least not until you enter the Aircraft payload menu and ok out of it. Regards Pete

You might as well hold off for a while longer. I've just done a proper test flight, and it isn't smoothing. I've got something wrong somewhere. It works well on my test system (with the debugging system running), but not in my cockpit. I hate this sort of problem -- you try to find out what is happening, and the very act of looking makes it work okay! Grrr. I'll be in touch again when I have something better. Unfortunately I'm running out of time this week, so it will probably be next week now. [LATER] Okay -- I found out what the problem was. I has a little program called SA_WXR running in my cockpit, which reads out the weather at all sorts of locations all the time FSX is running, so that it can display a weather radar picture. Due to a stupid error on my part, this regular read action caused my normal smoothing actions to be by-passed altogether! Duh! :roll: So, I'll fix that now and test it, and may upload 4.174 tomorrow morning, or even later today, if it is okay. Meanwhile, if you don't get it, you can still test 4.173 provided you have no programs or gauges running which are reading the weather through FSUIPC. Regards Pete

Actually, it was there in the FSX Downloads announcement a few minutes after I sent the message in this thread! ;-) Pete

The FSUIPC4.ZIP file contains a program called "Install FSUIPC4", and even a "User Guide", which strangely enough, tells you to run the Install program! Just look at the section cunningly entitled "Installation" Adding FSUIPC4 to FSX isn't a simple matter, it is done by the Installer! Please do try to help yourself just a little! Although you said "Absolutely. Frequent looks." to my question as to whether you ever looked at the Announcements here, it seems you meant you "looked" but did not actually "read" them! Next time I shall have to re-word such questions so I get a correct meaningful answer! :-( Pete

Make sure you have the currently supported versions of both PFC.DLL and FSUIPC.DLL. Companies like PFC have a habit of supplying out of date versions. Go to http://www.schiratti.com/dowson and download the current ones. The PFC.DLL doesn't need registering, and unless you want to use the additional facilities in FSUIPC, that doesn't either. Check the User Guides, see if you want to first. Follow the links and instructions in the User Guide. It tells you not only where to go and pay, but also how much. ;-) Of course, just follow the instructions in the PFC.DLL user guide. First use the TEST tab to make sure it is seeing your buttons and switches okay. Pete

I think I may have found one possible cause, or maybe another symptom, of the bug in the FSX weather system which is causing the rapid wind reversals. It looks like, with downloaded real weather, at least (and possibly updates thereto, or maybe just the dynamic changes in any case), as the weather is changing at each WX station more and more spurious extra wind (and temperature) layers are added. Most of these are nonsensical, only a metre or so thick. As an experiment I changed FSUIPC4 to detect these spurious layers, and if they occurred, to remove them and re-write the METAR back to the WX station. So far, with that mechanism in place, the wind smoothing appears to be a lot better. I've only been testing for a morning, but so far there've been no severe wind shifts. Consequently, I'm uploading version 4.173 soon, and recommend that you now do some of your own testing with that version. I'm away from Thursday through to Sunday, inclusive, but I'll do some real flight testing tomorrow, and catch up with any results from you next week. Regards Pete

The only time any program touches it is when you run FSX and FSUIPC4 reads it and re-writes it. By all means keep a backup -- and of ytour FSUIPC4.KEY file too! Regards Pete

Yes, but the main use wasn't really intended for that, but for those AI aircraft you meet head-on, or intercepting you, when you are trying to get to or from the runway. That seems to happen to me far more often (especially since, using Radar Contact's ATC, it more often than not manages to prevent aircraft encroaching on the runway when you are on final approach). You can also Zap that aircraft that had the cheek to pinch your favourite gate position! ;-) I did try that, but I found I was Zapping aircraft I couldn't even see (that's when I also added the sound effect). As I put in the notes, I am prepared to make a different set of criteria for an airborne user compared to one on the ground. The bearing should probably be a lot tighter for airborne too. Not sure about the vertical angle -- that 10 degrees was based on how far downwards I could still see an aircraft on the screen, in full-screen mode. It could be more of a problem if you are landing with a panel view and passing over parked or taxiing aircraft. So, maybe: Ground: Range 0.25 nm, Bearing within 15 degrees, vertical within 5 degrees Air: Range 1.5 nm, Bearing within 2.5 degrees (?), vertical also within 5 degrees (average glideslope is 3) Regards Pete

Sorry, I've no knowledge of the CPFlight hardware whatsoever. Since the EFIS functions of the CPFlight hardware will presumably be dealing only with Project Magenta, having no function whatsoever in FSX, I really don't see why you get any difference. But as I don't know CPFlight stuff I cannot really help I'm afraid. Do they have any support? Or does PM software recognise the hardware directly, as I thought it did with their MCP? If so you need PM support. Regards Pete

Good. You know exactly what files and which versions are available, and where, then. Have fun. Pete

Okay. All my files are still all available in the usual place -- http://www.schiratti.com/dowson . Have you actually looked? Have you even looked at any of the Announcements in this Forum, which tell you all about all this stuff? Pete

Yes. That's the whole point of FSUIPC. It's grown from beginnings in FS98 times all the way through. If it wasn't offering compatibility for its client programs there would be little point in continuing it, with SimConnect from Microsoft offering an interface for the future in any case. There are of course many extra bits for FSX, but pretty much all (but not quite all, as yet) of the FS2004 bits are there in the FSX version too. see the FSX Downloads announcement above for some extra SDK bits and pieces covering this subject. Regards Pete

What throttle quadrant? You actually said you were "using a gameport for the Precision Flight Controls yoke". Do PFC make a game port throttle quadrant? If so, the same answer applies. I only provide a driver for the digital control systems, and they connect to a serial or USB port. It sounds as if you need to refer to any documentation which came with your equipment to see what you need to do with them. If you do need to use any of my programs, the versions you need are always the latest ones, as listed in one of the Announcements above -- the "List of Current Supported versions". Pete

Don't go overboard on this at present. I've found another problem -- I'm not actually computing any smoothing increments on the wind speed or direction, because of a timestamping error which indicates no time elapsed! This one is easy enough to fix. However, there seems to be some other problem whereby it fails to scan correctly to update its matrix of 9 weather stations. I'm still puzzled by this. The code is complicated, but it looks okay. When I've found and fixed this error I'll upload another version and let you know. BTW I've done several flights with FSX's own downloaded weather, and whilst, perhaps because of the above, the winds haven't been smoothed, the big changes are always in the wind direction reversing, or nearly so. I've not yet seen any cases of 250-270 knot winds. That really does sound like a result from a corrupted weather download. Many of the cases of wind reversal occur soon after SimConnect reports a METAR which is really very very long and which contains many almost identical Wind Layers, 30-50 of them, some as thin as a few metres. I'm pretty sure this is part of the problem, and that both are symptoms of a serious bug in the FSX weather system. I have seen this in the original Beta last year, and reported it, but no one could ever reproduce it consistently. Regards Pete

When you try to reproduce it, please do remember to switch some appropriate logging on, so that you get relevant information. In fact, wait till I upload version 4.172 (just preparing it now), as I've added some extra logging to give me information on axis masking. Before running FSX add this line to the [General] section of the FSUIPC4.INI file: Debug=Please. The sorts of things which it would be most obvious to log are: 1. Axis values -- the check box on the left-hand side of the Logging tab. 2. The values you are disputing in offsets 332x. Do this by choosing up to 4 offsets and entering them in the table on the right-hand side of the Logging tab. They'll be type S16, not hex. You can monitor them to the screen for your own interest, but check the "normal log" option so we can see them in the log and relate them to the axis values. 3. On the left-hand side you will see an "Extras" edit box, probably with 0 in it. Change that to 64. That enables the new debug logging of the axis masking. After setting all this it would be best to close FSX and restart it, as you have said that on each load of FSX it either works or doesn't. It would therefore be important to see the start of each log. We will need to compare the log of a successful session with that from an unsuccessful one. Try to keep the sessions as short as possible, just long enough to be sure, else there will be a lot of data to plough through. Additionally you should really do this using each of the three different axis assignment routes -- FS assignment, FSUIPC assignment via FS, and FSUIPC assignment direct. Considering there are so many combinations, if you think you can reproduce it by selecting just ONE axis, then please do so. There's no point in ploughing through data for all four of those you are intercepting if this isn't needed. If you send me logs please be sure to Zip them, along with your FSUIPC4.INI file please. If you have something I can use to reproduce the problem, please send that to. All to petedowson@btconnect.com. Regards Pete

Okay. I really don't know of anything else that would do that at present. I will need to be able to reproduce it (which presumably means using your program?), or otherwise at least get some information. Okay, so it suggests SimConnect is not getting kludged. However, the FSUIPC Log is still the very first place to look when you get problems, because if FSUIPC knows about them (and it might), they will be logged. And even if FSUIPC is unaware of any problems, there are plenty of tools provided in FSUIPC, via the Logging page, for you to get enough information to tell both of us what might be happening. Even the values of these "spurious values" may be a vital clue. As it stands, I do not even know how your axis values are arriving in FSUIPC. Are you assigning in FS, calibrating in FSUIPC, or assigning in FSUIPC. If the latter are you assigning direct, or via FS? Have you tried all three possible methods and do the problems occur with all of them or only one? There are lots of things to do to narrow it down. I cannot help at present because I have no information from you and no way of seeing what you are seeing. Thank you. Regards Pete

Ouch. But, yes, actually, others have mentioned how awkward it is to get things put right in Vista once they get screwed up. Scope perhaps for some bright programmer, who knows this stuff about Vista to write a utility to do it all when needed. I'm amazed that the FS uninstall leave stuff all over the place, but when I asked MS about this they said it was MS "policy" for WinSxS libraries to be non-uninstallable (!!) Obviously the powers-that-be somewhere in MS (not the FS team) never expected anything in the WinSxS system to get screwed up! It may be worthwhile sending a full report about this to tell_fs@microsoft.com. Regards Pete

No. The full movement of the joystick itself can be almost anything. Quite a lot of USB gamepads have a range from -7000 odd to +7000 odd, not the max -16383 to +16383. It doesn't matter to FSUIPC because the calibration spreads whatever your range is (shown in the "IN" box) to the range needed by FS (shown in the "OUT" box. If you aren't achieving that spread you are not following the instructions correctly. If you have the axes assigned in FS (rather than in FSUIPC's Axis Assignments) then, before you do any such thing in FSUIPC, you should: 1. Calibrate the axes in Windows, using the normal Game controllers applet in the Control Panel. 2. In FS ensure that the Sensitivity slider is at Max (full right) and the null zone slider is at Min (full left) for every axis. If these are wrong you lose some of the range and definition of your axes. Regards Pete

That's what I thought. Quite often when that is the case the adjustment is local to the gauge and only operable by mouse. I'm actually quite surprised, really, that the control is linked up in the two aircraft in which it is. Yes. This is the reason Luciano Napolitano's "Key2Mouse" program is so popular as it provides a way of driving the mouse from keypresses, which can in turn be programmed to buttons in FSUIPC. If you mean programming your own gauges, you need the official Microsoft Panels SDK. See the FSinsider website. In FSX most gauges are written in XML, but earlier versions used C or C++ as well (or instead). I've not programmed a gauge myself since about FS95, so I cannot really help. There are other forums which might offer help. Regards Pete

I seem to recall this happening if you have something enabled in the PFC driver which isn't supported by the version of the PFC firmware in your unit. See this note in the PFC User Guide page 27): Trim/shaker motors fitted: Only check this to enable the facilities in PFC.DLL which driver the stick shaker motor (on stall or overspeed warnings) and trim motor (to turn the trim wheels), if you have these fitted. Do not enable them otherwise, as there is a possibility that the version of firmware in your console might then cause odd things to happen, most noticeably flashing of the gear indicator LEDs when trim is adjusted. If this isn't it then I'm afraid you'll need to ask PFC themselves. It will certainly be related to an older firmware version and newer protocols. Regards Pete

Yes, I did actually understand the meaning of the name of the control. I just have no idea what it does, if anything, in FS! So you know what it actually does in FS? Maybe it isn't modelled in the Baron for a good reason, or it is a bug? If the latter you should report it to MS via tell_fs@microsoft.com. Regards Pete

No, that was all resolved. Well, it certainly doesn't sound similar to me! There was certainly no element of things "deteriorating" in those earlier problems. It was simply a matter of a routine not being called at all with one of several possible configurations (the direct to FS calibration assignments in fact). That plain didn't work because of the missing routine. Your problem sounds much more like something is clobbering the SimConnect interface. Please check the FSUIPC4.LOG file. In fact, go further than that -- use the Logging to check exactly what is going on. That is what it is for! You can monitor values and log the axes. Do both. If it looks like a SimConnect problem you should get a SimConnect log too -- see the FSX Help announcement for how to do that. If you have other SimConnect client programs running, get rid of those first. Once every few seconds, provided the writes get to FSUIPC within about 10-12 seconds, would be more appropriate. Even on a WideFS networked PC a 5 second refresh should be plenty enough. Please, when any problems are suspected, ALWAYS update to the latest interim version if there is one. There have been about 11 interim update versions since 4.16 was released. I doubt it this aspect is changed at all but I would only want to see current version logs in any case. See the FSX Downloads announcement above. Regards Pete

Sorry, I don't even know what that one does. Are you sure whatever it is is implemented in the Baron? FSUIPC doesn't invent these things (well, except for a few added controls as listed in the Advanced Users guide). They are whatever is tabulated in FS's "Controls DLL". Hmmm .... what control are you using for the starter? If you use the MAGNETO INC (I think it is that one) and set it to repeat, this emulates holding the key to the right against the spring-loading, and on most ordinary prop models seems to need 2-3 seconds. I suspect the time is dependent on the modelling in FS, which will vary. Not in any software currently supported by me -- I did do a module called Esound a long time ago, but it isn't much good these days and not very easy to program in any case. I use the Project Magenta "pmSounds" module for any extra sounds I need. Regards Pete

I don't know anything about "TestconsoleForm" -- all my stuff is in C. What language is that in? In the C versions of all the functions, the return value is a success or failure BOOLEAN only. The actual data being read, which might be a single value or many hundreds of values, or text strings, or anything, is returned into the structure, which could be a single variable or an array or any mixed structure, as you need, and which is pointed to by the parameters provided to the function call. I think you must be misunderstanding something quite fundamental in all this. The data cannot be returned as the result of a function as it can be any data of any type and size! Regards Pete