Pete Dowson

Sorry, what is the question you are asking me? I'm not clear what you mean by "would I have stumbled over something here?" so I have no idea how to answer this, the only question I see. If it is just that you are confused over version numbers, all version 3.xx FSUIPC's are for FS9 and before. For FSX you must install FSUIPC4. I have no idea what that "FSFlyingSchool" folder is for, but if it talks about or includes FSUIPC version 3.70 it is pretty old -- 3.70 was released in July 2006 and was superseded by 3.71 in November 2006. All products which include a copy of FSUIPC are supposed to either provide the full package, including documentation, or at minimum a reference to where to get updates and the full package including documentation -- i.e. to http://www.schiratti.com/dowson Regards Pete

Why do you want to "open" anything? Don't! Refer to the FSX Help announcement, above. Follow the instructions provided there for repairing SimConnect. Pete

Erhow on Earth are you checking them before the PFC driver is running? The PFC menu appears when the PFC driver is loaded by FSUIPC4, and it has read the INI and initialised itself. None of that happens till a while after FSX is "ready to fly" as FSUIPC4 doesn't get sufficient data from Simconnect until then! FSUIPC4 is loaded by SimConnect when FSX is loading, but it has to wait until everything is ready before loading any other ancillary drivers. The same applies to WideFS initialisation, and subsidiary activities such as GPSout and AutoSave. This is simply because all of them are dependent upon the FSUIPC interface to SimConnect and that isn't fully viable until FSX is fully initialised and running with regular data exchanges. There's no difference in PFCFSX.DLL to the original PFC.DLL as far as INI settings and their operation are concerned. Only the interface to FS was changed, and rather than have multiple clients to SimConnect (very inefficient when they are all using the same data), PFCFSX is a wholly-owned FSUIPC client application, just as many external programs are. It is more efficient that it would be as an external program as it can access FSUIPC directly, but it still cannot do this until it is loaded and FSUIPC will not load things prematurely. I think you should re-enable the PFC connection checks, via the main PFC options screen. Leave them enabled so you can see when the PFC driver is loaded -- when that finishes its checks (or you force it to continue into FS via the button), it is all established. Having already waited 3 minutes for FSX to load, another few seconds should seem like no time at all! ;-) Regards Pete

"[Axes.Boeing]" is fine as long as all the aircraft titles have "Boeing" in them, and you have changed the "ShortAircraftNameOK" parameter from "No" to "Substring", as clearly documented. If all of the titles start with "Boeing" then you can have "ShortAircraftNameOK=Yes" instead -- but then it won't find it if the word Boeing is not at the start. Please do refer to the User Guide, and the new Appendix included in the latest releases. Regards Pete

I'll look at the multiple INI thing for FSUIPC4 next week. Certainly, if it isn't too complex I'll add it fairly quickly. Regards Pete

Yes. SimMarket will sort it out for you if you raise a problem ticket, or alternatively you can send both sets of details to me (full sets please) and say which one you would like changed. Send to petedowson@btconnect.com. Regards Pete

No, sorry. That is a bit odd. Obviously the PFC driver is feeding FS with the correct controls, else they wouldn't work for the other aircraft. The DC-3 must have something odd about it. It's getting a bit late here and my PFC-enabled system isn't on at present, so I'll make a note to look at it tomorrow. It won't be first thing, so I might not get back to you till the evening. Meanwhile, you could try axis Event logging in FSUIPC4 (Logging page, one of the radio buttons on the left). Just to assure ourselves that the right things are being sent. Looking at the PFCFSX code, the throttle operation uses the same system as the aileron, elevator and rudder, whilst the mixture, prop and brakes use FSUIPC offsets -- so that deepens the mystery, because your split isn't by method but bysource? That suggests one other experiment. Suppose you go into one of the other user settings for the quadrant (U2?) and, as an experiment, assign the aileron, elevator and rudder there (temporarily disabling the main ones of course, via their checkboxes). If they work we know for sure it's nothing to do with PFCFSX or the hardware, but something to do with the specific axes and their treatment in the DC3. [LATER] I'm a bit puzzled by the PFCFSX.INI file you provided. Although it says you are using quadrant "U1" there don't appear to be any assignments or calibrations set for it. At least none saved in this INI file. Are you using one of the standard quadrants from PFC? Does it's normal settings page work for the DC3? Or could you choose one of the ready-made ones which suits the DC-3 and try that? From this: [AircraftQuadrants] Curtiss_C-46A=U1 ALPHA_Hudson_0=U1 Douglas_DC-3=U1 it seems that you have two other aircraft set to use U1. Do they suffer in the same way? So far it is looking like there's no settings for U1 in the INI , so it is never actually doing anything. None of the levers are being assigned! The quadrant will work in the Baron and Goose because they presumably aren't using U1. Regards Pete

Really? How strange. Any partial log file to show? Try removing your FSUIPC4.INI file, in case it is some joystick setting or assignment, or a button or something. Let me know -- if it seems to be an INI setting then (a) let me see the file, and (b) enable logging for the relevant areas -- i.e. buttons and axis events. You can do that by adding LogAxes=Yes LogEvents=Yes LogButtonsKeys=Yes to the [General] section of the INI file. That'll make sure we get information from the start. Actually, another thought. If you run FSX in Windowed mode 9just for these tests), adding the line: Console=Yes as well will provide a log in real time in a console window, on screen, so you can see what is happening 'live'. This might help in case the Log file is lost or incomplete when you have to terminate FSX. Just in case, select and copy the text from that window (I think it's a right-click on the title bar option to copy), so you can paste it into a message or text file for me. Oh, one warning -- don't attempt to close the console window itself as that will certainly close FSX too. I don't know why, and I can't find any way to remove the close (X) icon top right. © then it will be a matter or eliminating things one by one. I'll need to know what other add-ins you have running too, just in case of adverse interaction somewhere. No, none. Regards Pete

Okay. So, nothing installed in FS9, it just all works with no add-ons? In that case you must be correct, weather being set through the MP interface. I should have investigated that! Never mind, too late now! ;-) Sorry, I don't know exactly how that would work (though I suppose I could test that using WeatherSet2). But FS does graduate temperature changes between layer levels, so I would certainly assume so. Regards Pete

Sorry, I don't recall the old one? Have you ENABLED the relevant quadrant in the PFC options? Sounds rather as if your quadrant is not enabled. Which quadrant is it, and is it actually being selected? SimConnect and WinSxS are both totally irrelevant. If SimConnect problems were occurring you'd have trouble on everything, not just one part of your PFC system. The PFCFSX log shows some odd logging. What logging options have you enabled? Please don't turn anything on unless asked. The FSUIPC log shows something odd (though nothing whatsoever to do with anything you are reporting). See this: It appears to be taking over 179 seconds (i.e. 3 minutes!!!) to get to the point where FSX is actually almost ready! During some or a lot of that time SimConnect is totally disconnecting (i.e. not supplying any data to FSUIPC) Why is this? What is your FSX doing for 3 minutes? Anyway, the only file which might possibly show why your quadrant isn't operating is missing -- the PFCFSX.INI file which has your settings in it. Regards Pete

"Did it" you mean -- I've changed it to make your program report the altitude correctly now. As I said some time back, if I supply a GeoId correction value of 0 then you report the correct altitude. If I simply omit it, as is allowed according to the NMEA standard, then you are applying your own. Hence you are treating "omission" as "incorrect". I'm not sure whether that's right or wrong, but yours is the only program we've come across in the 10 years or so of GPSout which does such a thing. I don't think there's much point in pursuing this discussion -- I've updated my program so yours reports altitude correctly, and this does not muck up anything else, so it's all okay. Regards Pete

Not sure about "translation" there -- I think FS9 converts all input weather to localised weather in any case (there's no "global" mode), and the temperature gradients will be applied to altitudes not provided with a specific layer value. I don't know the MP interface but I didn't realise there was any provision for weather settings in it! That might have saved me a lot of work in past versions, where I had to hack severely into the WEATHER.DLL. Are you sure about this?. Yes, this is a new facility which Microsoft added at our request (mainly Damian of ActiveSky fame and myself insisting on it). The reason for it is to provide properly controllable and reproducible weather for use in flight instruction. FS9 doesn't really allow detailed control for anything but short periods because it uses whatever is input merely to populate local weather stations which then are subject to individual development, forever after unchangeable (except by station-specific setting), unless you clear them and start over. Yes, I understood all that from your first posting. I use all of the SimConnect facilities in FSUIPC4 and they are all accessible through the NWI. Yes, because the Global setting is intended to allow specific control at the aircraft, which it does well. You can make it set a gradient by setting multiple layers, by which you can actually control the gradient itself of course. To do the same rather fuzzier system applied in FS9 you'd not use "global mode", but instead do exactly as you did in FS9 -- Clear all the weather (which can be done through SimConnect by setting the clear weather 'Theme'), then set Custom weather mode (same as "user-defined" in the UI) and then write the "GLOB" METAR. The cleared weather stations would be populated by that, but develop as you'd expect real weather to develop, including temperature gradients and so on. You still effectively lose control from then on, but from your first post it sounds as if FSHost doesn't care about that as it doesn't give you local weather as you are flying in any case. LOL! There's only ever been one pressure setting in FS in any case -- the QNH or sea level pressure. Obviously pressure has to decrease with altitude else you destroy a lot of what flying is about and none of the altimeters would work! In FS2002 and before only temperature, winds and clouds had layers. In FS2004 they also added layer facilities for visibility but they didn't work. They don't work properly in FSX either. Pressure never had layers and of course never needed to -- maybe weather on Jupiter has variable pressure gradients, and perhaps there is some minor variations in our atmosphere, but evidently nothing serious at normal flying altitudes. Yes. Pretty much the same as on FS9, then, except better than FSHost because of your different weather. You'd set "custom" mode (though i think that may happen in any case as soon as you write a WX station METAR). Note that your destination weather (and your en route weather) may change substantially whilst you fly, depending on the user's dynamics slider. There is a SimConnect (and FSUIPC) facility for setting that to "0" which is not really zero, but ssslllooowww enough mostly. Regards Pete

It should either be setting a series of temperature layers (perfectly possible in the extended METAR format supported by SimConnect, or, possibly easy, send a fresh Global setting as the aircraft climbs or descends. Same goes for winds of course. Surely as you fly to different weather areas it obtains and supplies a fresh METAR? Yes, as you would surely see if you used ActiveSky 6.5 which uses FSUIPC's "NWI" system to set localised weather and which works well with both Sims. In ASX they changed to using SimConnect directly, but 6.5 still worked pretty well. I wouldn't go for global weather, though. Although FSX sports a "Global Weather" mode which overcomes the problems, FS9 in particular was almost impossible to control weather-wise globally. Once the global weather became localised you couldn't change it again without clearing all the weather and propagating fresh global settings. You can imagine how horrible that looks! Regards Pete

It may have arisen from assigning axes, then unplugging that controller from one USB port and plugging it into another and re-assigning -- Windows would see it as a new controller and assign a different number to it. Actually the only "update" in this for some time is the addition of the Appendix to the User Guide -- it's derived from a posting here in the Forum. The "ShortAircraftNameOK" option has been in since, let me see (consults History document)3.70 (July 2006) for the "Substring" option, but 3.21 (April 2004) for the original "Yes" option. Glad you are all sorted. I was relieved to see it had a rational explanation. Regards Pete

You don't need to convert it, it is already in a usable form -- pounds of fuel, as documented. Here's part of a Log where I Monitored both 090C and 0910 as FLT32's (FSUIPC's Logging tab, right-hand side): 617859 SimRead: 090C="GENERAL ENG FUEL USED SINCE START:1" FLT64: 1.57705454783 617859 SimRead: 0910="GENERAL ENG ELAPSED TIME:1" FLT64: 51.0742018745 617859 Monitor IPC:090C (FLT32) = 1.57705450 617859 Monitor IPC:0910 (FLT32) = 51.07420349 .... (later) 672125 SimRead: 090C="GENERAL ENG FUEL USED SINCE START:1" FLT64: 70.8945062595 672125 SimRead: 0910="GENERAL ENG ELAPSED TIME:1" FLT64: 51.0842001718 672125 Monitor IPC:090C (FLT32) = 70.89450836 672125 Monitor IPC:0910 (FLT32) = 51.08420181 Seems fine to me -- note that FSUIPC is converting the value into Float 32 format for you. A small loss of precision doing that, but certainly nothing significant. Maybe you are reading it as an integer or a double (Float 64)? Try using the correct form. Regards Pete

It shouldn't need any "configuring". What on Earth were you doing for a week? There is no relationship between SimConnect and WideFS, excepting that they both use TCP/IP and FSUIPC4 uses SimConnect and that has to be working for WideFS to work. I've never had to tell a router to open specific ports. Does that mean all the others are closed? Possibly you've told SimConnect to use the ports needed by WideFS? That would most certainly clobber WideFS as SimConnect will grab them for exclusive use first. Pete

Wouldn't reference to the documentation I supply help you here? The Advanced User's guide explains all this in the section entitled "Format of button definitions", thus: This is why I provide documentation, especially for the Buttons parameters where a lot more programming capabilities are provided for INI file editors. You must have assigned them at some time, presumably when your Joystick 0 was connected as Joystick 1 (unfortunately if you unplug and replug in controllers Windows can reassign the numbers). If they "reappeared" when you deleted them you presumably must have done this whilst FS was still running? If you do that you must tell FSUIPC to reload them (reload all buttons button on the Buttons tab). Otherwise only make changes when FS isn't running. There's no way FSUIPC will ever "invent" these parameters for you. You don't really need to know as this section isn't really suitable for manual editing, but just for info "F" means you assigned an FS control, "D" means you assigned it to go direct to FSUIPC calibration. You'll see the word "Direct" in the calibration section for those. As described above and in the documentation. Because, I assume, the parameter with that control restores the previous view, rather than sets a straight-ahead view. I can't think of any other way to say it. Isn't it clear enough? Do you need a translation into your native language? Regards Pete

Default aircraft too? You seem to have quite a strange collection of Axis assignments via FSUIPC -- have you disabled axes via FS itself? If not then I assume you are using a mixture, because the Default Axis assignments you have in the INI are: i.e. Aileron, elevator, generic Throttle (NOT "Throttle 1") and Throttle 2weird, eh? This is the assignment section: which has two sets of assignments for 22 (spoilers), and 9 and 10 (Throttles 1 and 2). So, I think that's where the difference lies. Between FSUIPC 3.81 and 3.82 I added the multiple joystick arbitration facility -- so that you could do what you've done, assign multiple controls to the axes (for two pilots) and have FSUIPC use the one with the largest deflection. Your Throttle 2 problem is no doubt due to the fact that your second set of throttles is set with a more extreme position than the one you are trying to use. Your Air Canada NC one is the same: which also raises the question: why do you want aircraft-specific axis assignments? Do you really assign your axes differently according to the specific aircraft? And why separate sections for each paint job? You know you can simplify all this, don't you? There's a new section in the FSUIPC User Guide which might help -- contributed by a User. Check the Appendices. Regards Pete

Yes, that is strange. I'd still like to see the relevant INI file sections to see if I can figure it out. No need to apologise. It is a puzzle. Regards Pete

No, that's exactly what I have. Pete

Those sound like default readings for a disconnected joystick. You should make sure you don't have Windows doing "power management" on your USB ports -- it enabled it tends to turn the power off USB devices until they need it (i.e. until you "waggle" the axes. There's no such thing as a "full toe brake" axis, only separate left and right axes. You press both together for full normal straight-line braking. If you want the (unrealistic) equivalent of the "." key for braking, assign a button to the brakes control, not an axis. Of course you can, in FSUIPC assignments, assign both left and right brakes to both left and right axis controls, but I really think you are losing aircraft steering capabilities if you do that. Why do you think a null zone will help anything? Regards Pete

Very unlikely as this is an excellent candidate for an add-on program, especially one which could be run on a separate PC via WideFS, as then different sounds can be routed to different parts of the cockpit (different speakers). In fact there is already at least one program doing such things -- pmSounds from Project Magenta. I use that on two PCs at present. Regards Pete

More information is needed I'm afraid. There's been no change in any of this, at leatt not intentionally, but I need to know simple things like how you are assigning the axes, to exactly which controls, and so on. "Setting the axis to be calibrated by FSUIPC" can be done in any of three ways, for instance -- via FS assignment, via FSUIPC assignment to FS control, or by direct assignment to FSUIPC calibration. All can route through calibration! Maybe the relevant section from the INI file would be the clearest way of showing me? Also, sorry, but "version from April 2008" doesn't tell me much. Could you actually look at the version number please? You can get it by right-clicking on the DLL itself and going to Properties-Version. [LATER] I've just fired up FS2004 and tried assigning Throttle 1 and Throttle 2 axes all three different ways (FS, FSUIPC via FS, FSUIPC direct), and all three work fine. There really isn't any distinction in FSUIPC between any of the axes -- so one can't suddenly get lost without the others -- UNLESS, of course, you are Mapping from one to another. Obviously if you map one Throttle to the others, the others won't be seen independently. However, none of that has changed in a long while. Are you sure you aren't getting mixed up with some aircraft-specific settings? Maybe you should show me the whole of your Joystick and Axis sections of the INI file? Pete

You "click on FSUIPC"? Are you sure that's not "Install FSUIPC4"? FSUIPC itself is a DLL, not an executable. I don't know "flying School" but if they have atheir own installer you may need to check with their support. The current supported version of FSUIPC is 4.30 which you can get from http://www.schiratti.com/dowson Ah, that will be from the FSUIPC4 Installer. If you look more closely (everything is actually in English) you will see that the "front" window is an error message box, and the "rear" one is a progress Log file. You can view the complete Log file in the FSX Modules folder. It is called "FSUIPC4 Install.Log". Don't FSFlying School provide the FSUIPC4 User Guide in their package? It will be found in the FSX Modules folder, but they most certainly should be giving you clearer instructions than those you appear to have received! :-( Aren't we all? :-( I "retired" a few years ago, and I'm "officially" a pensioner from my 65th birthday next month. I don't really think age is relevant to this, though! Unfortunately you seem to have somehow got the installation of FSX screwed up. I don't know how it happens but it certainly seems to occur to a minority of users -- about 2 a week reporting here. Lots of complaints about this have been made to Microsoft, and indeed you may need their assistance to resolve it, especially if you have the misfortune to be using Vista rather than Windows XP. Anyway, all I can do here is repeat my explanation from another thread here, posted yesterday: The error you have is that the version of SimConnect which is needed to load FSUIPC4 (and most, though not all, other SimConnect applications) is either not installed or is corrupted, as Windows fails to match it to the Installer's checking. It uses a set of "manifests" -- data declaring versions -- to determine what "side-by-side" versions of SimConnect are installed and working. It does this so that it can configure FSUIPC4's run-time capabilities -- more can be done with SP2/Acceleration, less with SP1, and less still with only the original base version. However, the last is always needed and expected, as it is responsible for loading the DLL in order for it to run. You haven't shown me the Install Log, so I cannot tell if you've tried installing FSX SP1 or Acceleration or SP2, but even if you have I'm afraid that its version of SimConnect, even if working, is insufficient. You must always have the full SimConnect version which was installed when you installed FSX from the DVD. So, you have a corrupted installation of FSX. You have already tried uninstalling FSX itself and re-installing it. This didn't work (as apparently it may not do -- if the Installer thinks SimConnect is already installed it fails to uninstall it or reinstall it, so it never gets sorted). So, the only other recourse I'm aware of is rather more complex, and is detailed in the "FSX Help" Announcement above --- the part which tells you how to repair just the SimConnect installation. However, this is apparently not so easy on Vista (if you are running XP it should be easy enough). You may also first wish to visit Microsoft's own support website and read the FAQs they provide. Regards Pete

The error is only the line I've shown in Red, not the others. Your message title is wrong, there is nothing wrong with the FSX.EXE version, as it clearly says! (61355 is greater than 60905, so it is okay -- it does say "Need at least", and you do have more!) The error you have (which would also have been shown clearly in an Error Message box, something you missed somehow?) means exactly what it says: the version of SimConnect which is needed to load FSUIPC4 (and most, though not all, other SimConnect applications) is either not installed or is corrupted, as Windows fails to match it to the Installer's checking. It uses a set of "manifests" -- data declaring versions -- to determine what "side-by-side" versions of SimConnect are installed and working. It does this so that it can configure FSUIPC4's run-time capabilities -- more can be done with SP2/Acceleration, less with SP1, and less still with only the original base version. However, the last is always needed and expected, as it is responsible for loading the DLL in order for it to run. You have SP1 installed and its version of SimConnect is okay, but that is insufficient. You must always have the full SimConnect version which was installed when you installed FSX from the DVD. So, you have a corrupted installation of FSX. You can either try uninstalling SP1 then FSX itself and re-installing them, or read the "FSX Help" Announcement above which tells you how to repair just the SimConnect installation. However, this is apparently not so easy on Vista (if you are running XP it should be easy enough). You may also first wish to visit Microsoft's own support website and read the FAQs they provide. It is still there, at the top of the Forum, clearly entitled "FSX HELP: Logging or Re-installing SimConnect" Regards Pete