Pete Dowson

Looks okay then. Of course it isn't! FSX doesn't have any GoFlight drivers built in! I think the only thing it will see is the TQ6 because that's a "normal" joystick-type device. All the others are specific to GoFlight. You either have to use the GoFlight software, or FSUIPC. For FSUIPC you need GoFlight's GFDev.DLL. I thought we'd been through all this? Regards Pete

It certainly is -- and also strange why you see it in lower winds at all. As far as I can recall the problem has always been with upper winds, during cruise. It's almost as if you are seeing some other fault altogether. Sorry, I've no idea about values to try. I don't suffer the problems at all, using ASE in Direct Wind control mode (so, only global weather, no interpolation done in FSX). Even before switching to DWC mode I only very rarely saw it, flying in Europe (I only ever fly in Europe). Regards Pete

That certainly sounds like the interpolation problem, though I've never heard of it happening at such low altitudes. And, further, that is the FS fault which FSUIPC smoothing is designed to handle, within reason. If it is taking 1-2 secs maybe you have the smoothing set incorrectly? The 180 changes without smoothing are instantaneous. If it is taking 1-2 secs it may be doing its best with the settings you've chosen. Where are you flying when this happens? If it is in an area with a large number of nearby weather stations then it could be exacerbated, especially if any one or more of the stations have corrupted weather data downloads. I'm pretty sure they did a lot in ASE to remove bad data so the problems are much less obvious. Sounds like good advice. And have you done so? The "higher value" thery refer to is the time. Not the change allowed. Regards Pete

FSUIPC wind smoothing isn't 100% successful, but generally it works well. It is mainly aimed at preventing the 180 degree sudden wind shifts which FSX (and FS9 actually) is liable to in the upper winds. These are due to an interpolation bug in FS's Weather.DLL which was never fixed. Such wind shifts rarely if ever occur in the surface winds because either they are generally either nowhere near any other wind layers, or, because you are taking off or landing at the time, near enough to a weather station to avoid any interpolation between stations in the first place. Note also that ASE (I don't know about ASX) does have a facility for fixing the weather at the destination once you are within a certain range (up to 50nm I think). I don't really know what you mean by "generally below Fl100 during approach or descent I have heavy circulating wind around the plane", because certainly I've never experienced anything like that with ASE. Maybe it is a bug in ASX now fixed in ASE? Or maybe it is a turbulence or gust effect -- in which case you can probably turn it off. It certainly doesn't sound like anything which FSUIPC would be involved in creating or removing. Have you tried Active Sky support, or considered upgrading to ASE? I don't know "Zinertec Ultimate Weather FX", but have you checked whether that adds other effects apart from "nicer clouds"? Gusts and turbulence are common in and just below thick cloud layers. Regards Pete

That's only because you have made an assignment in that mode. Just uncheck the assignment, select "direct to ..." then select the correct assignment. The direct assignments are to FSUIPC calibration tabs NOT to the FS controls! That's the whole point! ;-) Not sure why changing the route through FSUIPC would change anything external -- why is this? And why are you trying to use an external control manager AND FSUIPC? I would have thought that would cause no end of confusion and maybe added problems. The non-axis controls are old FS98 compatible controls, supported by FSUIPC for compatibility and to allow reverse zones on throttle, prop and mixture (the Axis controls don't have reverse). The Axis ... controls are the ones FS itself uses when you assign in FS --and there are several add-on aircraft which do not work unless those controls are used. There is no way and no reason for them to be "discouraged" and certainly not removed as they are the mainstay of FS surface controls. Just because you have a problem, probably some conflict with CH Control Manager, doesn't mean everything others use must be discarded! Pete

Well a 737NG has 7 intermediate positions as well as full up and full down. A C172 only has 2. Your 5 detentes aren't necessarily going to match any particular aircraft. Regards Pete

Assuming the PC's date is set correctly (check please), it is probably the result of a recent Win7 update which tightens security even further on the Registry. There are two things which may overcome this: 1. Re-run the Installer but by right-clicking on it and selecting "Run as administrator", or 2. Download the latest interim update (currently up to 3.997b) from the Download Links subforum and copy it into the FS Modules folder. If neither action helps, please paste the FSUIPC log file (not the Install log) here, after closing FS down. Regards Pete

Excepting the TQ6 I think all of the GoFlight units need either the GoFlight driver module or, for third party programming, GFDev.DLL which provides a standard interface for them. They can be programmed through the Windows HIP API (as supported in the Lua COM library), but that's a programming job not really a user job. Windows needs no special driver for such devices because they are implemented as HID (Human Interface Devices) following a strict protocol. So the standard HID driver in Windows is enough to support the GoFlight modules, the GFDev.DLLL, and my COM library in Lua. If you wish to check HID devices connected to your PC and how they describe themselves to Windows you can use a little program I made called HidScanner, get it here: HidScanner Are there indents on the TQ6 for flaps? If so, how many? Which aircraft are you proposing to use it for with indents? Different aircraft have different numbers and therefore indents in different places, so they are only really of any use if you plan to use only aircraft types with the correct number. On the other hand an indent-less lever can be positioned anywhere to suit the positions actually available on the current aircraft. If the GoFlight devicer can see it, then so can GFDev.DLL, and therefore so can FSUIPC. As I said, it uses the GoFlight driver. I do have an GF-LGTII here -- I assume that is the one you mean? HidScanner shows it identifying itself correctly, thus: ************************************************************************** Device at "\\?\hid#vid_09f3&pid_0048#8&afbebfb&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}" Vendor=09F3, Product=0048 (Version 1.1) Manufacturer= GoFlight Product= LGTII Serial Number= 00080 7 Usage Page: 2 Input Report Byte Length: 5 Output Report Byte Length: 0 Feature Report Byte Length: 5 Number of Link Collection Nodes: 4 Number of Input Button Caps: 1 Number of InputValue Caps: 1 Number of InputData Indices: 7 Number of Output Button Caps: 0 Number of Output Value Caps: 0 Number of Output Data Indices: 0 Number of Feature Button Caps: 2 Number of Feature Value Caps: 2 Number of Feature Data Indices: 9 Buttons range 1 -> 6 at indices 1 -> 6 Value Dial at index 0, range -128 -> 127, using 8 bits ************************************************************************** If yours doesn't show the same, at least the same VID and HID (i.e. Vendor=09F3, Product=0048) then if I were you I'd check with GoFlight support as it might be faulty. Regards Pete

If you are only requesting data once every 500 mSecs I don't see how there could be a problem. Many programs make requests every 30 or 50 mSecs and don't have problems! Obviously they don't "hang" for more than the one second it takes for those timed-out retries, then they can report the failure. How can those be accumulated to make it appear completely hung? I'm afraid I don't understand. But perhaps you mean you have lots of asynchronous "FSUIPC_Process" calls, each only requesting one or two items of data? If so, that is a very inefficient, way of doing things. You should be accumulating all reads and writes into one regular batch which is sent at regular intervals (and only needing one timer). That's why the "Process" call is separated from the "Read" and "Write" calls. The latter two merely build up a request package. The request package sent by the FSUIPC_Process routine should be regular. Regards Pete

No, not really, unless you want to do specific things for specific aircraft. FSUIPC is a toolkit, to use for what YOU want to do, not to be imposed on everything regardless. And all the GoFlight kit comes with its own software which is fine for most aircraft. It's only when you start getting ambitious with sophisticated add-on aircraft that you might want to do something the regular drivers and FS assignments can't do so well. From GoFlight, yes, I think so. I don't use any such modules myself. Regards Pete

No, not really. For most aircraft Goflight seem to provide quite adequate drivers in any case. And provided you install the GoFlight software (or at least download and install the GFDev.DLL, from GF, or here in the Download Links subforum), FSUIPC can see all the switches and buttons in any case, so you can program the few exceptions in FSUIPC normally -- no programming. Lua only comes into it if you want to display things differently on the GF devices. And FSUIPC assignments only start to get complicated for things like advanced autopilots on some add-on aircraft. I don't think the TQ6 has detentes in any case? But, also, the TQ6 is just another throttle quadrant with so many axes, visible as axes for programming in FS or FSUIPC without any other drivers, and certainly no Lua involvement. Yes, FSUIPC can calibrate detentes if you want to mark them somehow on the lever, but otherwise a flaps axis is just another axis. And having marked or real detentes limits you to aircraft with that number of positions. Regards Pete

No, I don't think FSInn uses FSUIPC at all. Have you tried their support? Regards Pete

Something to do with protection in those Program Files folders. But what, I've no idea, because in all previous cases either the Installer's granted "elevated admin" privileges have allowed the FSUIPC4 Installer adequate access, or certainly right-clicking and running it "as administrator" has worked. I think some recent windows updates from MS may have changed the rules yet again, yet there's no such trouble here with all the latest updates. Mind you, the first thing I do after a windows install is turn that damned UAC off! Regards Pete

Sounds like you aren't handling the error conditions? The SendMessageTimeOut sent to FSUIPC should time out or fail when FS closes. Have you tried using the Delphi debugger to see where it is hanging? I didn't write the Delphi interface program, but as far as I know all the source is there so you should be able to figure it out. Programs like FSInterrogate are written in Delphi, and manage to detect when FS closes and rejoin when it restarts. Regards Pete

I think I'll settle for 4 optional inserts: %A aircraft %D date YYYYMMDD %W day of week (MON, TUE etc) %T time hhmm (no seconds) Pete

Hi, You posted a support question in the FAQ subforum where it was lucky I noticed it. I've moved it here for you. Yes of course. How have you installed FSUIPC? In the ZIP accompanying the Installer there is an Installation and Registration guide. It tells you exactly where all the documentation and extras are -- i.e. in the FSUIPC Documents folder, inside the FS Modules folder. How could you have missed all this? :-( Regards Pete

One thing worries me about this. The "AlsoSave" option is not a file management one. It simply replaces the last one of the same name each time it operates. So at present you don't get an accumulation of files filling the disk directory and slowing each access down bit by bit. Once you start adding data and time, you'll get an accumulation of files. If you have it set for 30 seconds you'll get 120 new files per hour. Now I realise you might set the interval longer to avoid this, but if the main point is simply to choose that latest for this aircraft, then why have the date and time? If you wanted an easy way to archive I suppose Date would be okay, so you get one per aircraft per day. In view of this I'd prefer to add just the two variables: %A for Aircraft, %D for date (YYYYMMDD). I can add %T for time, but I've a feeling this should be rejected unless the interval is set to at least 30 minutes, not seconds, in which can it would probably not be useful. Comments? Pete

You could, of course, have read the documents before spending any money, and so saved yourself all the trouble you seem to think you've met. Or you could possibly look at one of the several French translations, which I am told are quite good. for instance, this one for version 4.60, recently contributed: FSUIPC 4.60 documentation in French FSUIPC460Francais --- Translation kindly donated by Mr. Philippe Hantzberg, 19th March 2011 Regards Pete

Yes, precisely. I don't know. Maybe I'll have a look. However, Prepar3D is a very low-use sim compared with FSX. I'm not currently using it because it seems no faster than FSX (slower with some of my sceneries), and doesn't work with some of my major add-ons --- mainly I think because they don't recognise the name. Maybe the performance wil change as they develop it, but I can't see many of my favourite add-ons getting updated to be compatible. UT2 and ASX work okay, but nowadays I can't live without Ezca! And I think Gary Summons must have taken advantage of some special quirks in FSX for his more recent UK scenery, because it doesn't work properly in P3D either. Regards Pete

I've no idea where it gets that from internally. Obviously it knows where places are as you can see from the Map facility and using ATC or the GPS. If you can find out how to obtain it internally, fine. It's something I would have liked adding in FSUIPC's application interface, and did spend a lot of time trying to make it work with SimConnect's facilities data. In fact the code for a Nearest Airports list is still included and can be enabled by an INI file parameter. But, as I said, it doesn't work properly. The information it provides is full of holes. Regards Pete

If you mean this: Yes, I hadn't seen that before. I'll have a look. Next week. But only aircraft and date/time (FS or Real?). I'm afraid there's no way I know to get the current airport without a database look-up based on the Lat/Lon (There IS a SimConnect facility to get nearest airports etc, but it doesn't work properly. It gets lists of airports with random omissions, quite often including the one you are sitting on!). Regards Pete

I've just checked. FSUIPC can detect when an aircraft or flight is loaded, but there is no way to detect the previous one being unloaded. By the time FSUIPC gets any information it is too late. The only possibility is the closure, and that's only because FSUIPC is being told to close up shop. And that doesn't work much of the time because by the time FSUIPC is told to close, the SimConnect routines it needs to call are often already closed.. Are you actually seeing Previous Flight being regularly saved by FSUIPC? I just had a look at my Flight Simulator X Files folder and the last time it managed to happen here on my test PC was late last year. I think it probably depends on how many SimConnect clients you had running. External ones like ASX are more likely to be keeping SimConnect responsive long enough for FSUIPC to get the job done. On my cockpit PC where I have many SimConnect clients, including at least three external (ASX, UT2, EZCA), the Previous Flight seems to be saved relatively consistently. But, on the other hand, FSX usually hangs on termination (without Windows), in aiPlayer, unless I think to terminate UT2 first, so it has loads of time. (Termination is then a Task Manager process killing job). This problem with not being able to do something on close was one I had on a list lodged with the SimConnect developer in ACES studio, and one promised to be fixed in some never-to-appear SimConnect update. I think it might have been done in ESP, though, as it is working in Prepar3D without any other SimConnect clients. Regards Pete

That's certainly easier, assuming you are just talking about one flight saved when FS is closed, not the timed sequence of flights with automatic cleaning of files in a cycle. But I still really don't see the point -- at the end of a session it is almost just as quick to use FS's facilities, pressing ; and entering a title. No, not any of those except possibly ending a flight (via ESC-End flight), though I'd need to check even that. I've a feeling that, again, I don't see this occur until it is too late to save anything useful. Certainly by the time FSUIPC is informed that you are loading a new flight or changed positions, it's already too late. No, I don't like any of that. Sorry. The timed saving is simply for retrying after a crash (aircraft crash or FS crash), not for archiving autosaves. I honestly don't see the point of that. I can see the application of the end of flight facility, but even then I don't see why trying to make it automatic (when it can't really be, needing FS close or flight exit) saves you much effort over just pressing the ";" key and entering the name of your choice, as I have always done )e.g. "BA 737 at EGCC Gate 42". I have flights saved with my favourite aircraft at my favourite airports. Regards Pete

Er ... hold on, that's an entirely different matter! I've never ever done automatic flight loading, and I really don't like the sound of it. And, don't foget, loading a flight loads the plane it was saved with. But they don't. FSUIPC never loads flights. It sounds like a good job for an external add-on, or maybe a Lua program. But I really don't want to do this in FSUIPC. Sorry. Regards Pete

If the "No Reverse Zone" option is indeed selected, and you then re-calibrated, then FSUIPC never sends and negative throttle values, so reverse can never be engaged. Therefore I suspect you've made some mistake. Perhaps you could paste the relevant Axes and JoystickCalibration sections of the FSUIPC4.INI file here so I can check. Also, check the exact same settings on a default aircraft such as the 737-800. If it operates correctly, with only forward thrust, there, then I suspect Eaglesoft are doing something odd with the throttles. Maybe it needs Axis controls. The change described below was made over a year ago, and it suggests something you might try: Otherwise, if it is a peculiarity only with that aircraft I can only suggest you ask Eaglesoft support. The normal Axis controls only provide forward thrust values, mapping -16k to +16k all to forward thrust with idle at -16k. That's exactly how FSX itself deals with throttle assignments. Regards Pete