Pete Dowson

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

You need the FSUIPC SDK, from http://www.schiratti.com/dowson . Regards Pete

It just occurred to me that, since you appear to have the FSX SDK, and if that is the SP1A edition (if not, download and install from FSinsider), then you may be able to effect a repair by simply running the SimConnect.msi file you'll find in the Core Utilities part of the SDK. Regards Pete

Those are FSX build numbers -- you get those in the Version Info of each EXE and DLL component. They are not the same as the internal version numbers. Those are correct for the original version 60905 of SimConnect and the SP1 version (which is 61242 -- it isn't a Beta). Aha! There should be two of the WinSxS folders, one each with a SimConnect.dll in each. Could you read the FOLDER names in the Windows\WinSxS folder please, all those looking like this: C:\WINDOWS\WinSxS\x86_Microsoft.FlightSimulator.SimConnect_67c7c14424d61b5b_10.0.60905.0_x-ww_429211e9 and check in each one of those that there is a correct build of SimConnect.dll inside. The part I've emboldened in the path above is actually the SimConnect version number. You should have two such folders, one as above with 60905 (DLL build 60905 also) and one 61242, which has build number 61355. It sounds like your Registry says there is an SP1 SimConnect installed, and FSUIPC4 is believing this, but you don't actually have the corresponding WinSxS folder with the DLL inside, or you do have the folder, but no DLL. I think you would need to re-install either SP1, or both FSX and SP1, first uninstalling it (e.g. via the Control Panel programs applet). My repair method (given in the FSX help above) could be tried, but I've been told it is none too easy to delete these folders in Vista. Regards Pete

Sorry, I've absolutely no idea whatsoever what the FDS interface is or what it does. I think you will have to refer to their documentation or support on this. Regards Pete

Hmm .. it shouldn't be, because the recent versions of GSUIP4's installer changes it to read/write. It sounds like you installed an old version. Have you tried running the current install -- 4.16 or later? No, you should not need to do that, really. Regards Pete

The same technique is used for Fly-by-Wire. No, that makes it more complicated as you have to stop the other (real) control axes being used. Er, where are you reading this? I think you are looking in the wrong place! Please take note of offset 310A, which will enable you to disconnect the main flight controls. You can then read them in one place (3328 ff) and write them to FS in another (0BB2 elevator, 0BB6 aileron, 0BBA rudder). What you do in-between in up to you. Regards Pete