Pete Dowson

I must admit I am completely confused by all this. Doesn't GoFlight supply any software to drive FS with the TQ6? FSUIPC was never meant to be a joystick driver, and isn't now. All its joystick section does is intercept the FS controls. FS still need to recognise the device and scan it for the axes to work. FSUIPC does have button scanning incorporated, so it can program buttons, but no axis stuff at all. Can you explain why you found it necessary to do all those things with the TQ6 and not use GoFlight software, please? I've got a little bit of GoFlight gear I purchased a while ago, which is how I test the button re-programming. But I've not yet got a TQ6 -- maybe there are problems with the GoFlight TQ6 software? I'm sure GoFLight would be interested in this feedback, if so. Regards, Pete

Was the first assignment done in FS, not FSUIPC? FSUIPC cannot override FS button assignments, only keyboard assignments (as it can intercept the messages for those). If they were both done in FSUIPC, then something is wrong. When you program a button to be "aircraft specific" then the general programming for that button should be overridden -- it can stand as the "default" action for that button on aircraft which you'vve not specifically programmed. It works like that here. Please let me know if it doesn't there (with FSUIPC 3.30), and provide some details so I can investigate. Regards, Pete

With WideFS you can run FS on one PC, other programs on the other. With WidevieW you can run FS on both PCs. There's no way you can run one copy of FS split over two PCs, if that's what you are thinking. If you want to move instrumentation off the FS PC onto the other, then you can -- external instrument programs such as Project Magenta and FreeFD allow this, via WideFS. Regards, Pete

Why do you want to use FSUIPC for the GoFlight TQ6? I don't see the connection. Go Flight themselves provide drivers. FSUIPC is only of any use in programming some GoFlight buttons in some ways that GoFlight may not be able to. COM ports? I really think you have got something extremely mixed up and wrong here. First, the GoFlight equipment (which is really nothing to do with me) is USB connected and driven by GoFlight's own USB drivers. Second, no COM ports at all are supported by FSUIPC. It is not a device driver, it has no provision whatsoever for connecting anything at all, whether COM port or USB. I have no idea where on Earth you are seeing that it supports "only" ports COM1 and COM2 when it supports none whatsoever! FSUIPC does not support levers at all. It is not intended to and never was. If you have problems getting GoFlight euqipment to work with their drivers, you need to ask GoFlight support. I cannot help you. I am not inmvolved with GoFlight and they are no my products. You need to read documentation that comes with your TQ6, not FSUIPC. Regards, Pete

That sounds like other processes in your PC. The most usual stutter with a few-second cycle is the one where Windows seeks IP addresses. You can stop that one by making sure all PCs on your netwrok have fixed allocated IP addresses. But there are plenty of other causes -- active virus checkers, Windows XP file indexing service, and so on. You need to disable altogether as many of the extraneous processes going on in your system as possible. FSUIPC isn't a single separate thread. Most of it runs in the main FS thread. Separate threads of higher priority are used for special timing and scanning purposes, but you can't change any of them. I would think the whole process would be smoother if it were -- I don't know how you differentiate between the 50 fps you want to achieve and 25 fps though. They would look the same to me. It's changes in frame rate which you want to eliminate. If you are getting regular jerking at several-second intervals it is almost certainly due to outside influences, nothing internal in FS or FSUIPC is likely to do that. Regards, Pete

Not FSUIPC. You simply need to change you FS9.CFG file -- look at the FS2004 FAQ on http://www.simflight.com/news5/modules.php?name=FAQ&myfaq=yes&id_cat=5&categories=MS+Flight+Simulator+2004 Yes. See the programmers guide. You can write all 6 values -- latitude, longitude, altitude, pitch, bank and heading. Regards, Pete

I don't think it can be done with TeamSpeak -- Roger Wilco and AVC, no problem, but there doesn't seem to be a way to get correct control into TeamSpeak. Regards, Pete

You may need to program conditionals into FSUIPC.INI to do that. UK, yes, but Stoke-on-Trent, not London. Regards, Pete

Glad you sussed it all out okay! Good flying, Pete

Well, the access registration details for programs are in a document within the SDK. Contact me if you need to, when you are ready. Regards, Pete

It can do, though most (all so far, I think) developers do actaully purchase FSUIPC, as it helps justify the free SDK and all the support I try to give to programmers. Also, even with a freeware key, depending on what language you intend to program in, this may not cover your debugging versions, which can make life more tedious for you. VB for instance doesn't look right to FSUIPC when debugging, so needs a user registered FSUIPC. If you really wish to persist in asking for a free key and feel you don't really need much support so it's money down the drain, then do send the details to me: petedowson@btconnect.com. Regards, Pete

As it says, 08c* is a scaling value. Multiple the two values and divide by 65536 (i.e. shift down 16 bits). Isn't that clear? It says it right there in the document. The engine values in the low ranges are all FS98 compatible, and have been maintained specifically by FSUIPC for compatibility. The others (2000=) were discovered and verified later, some for FS2000, some FS2002 and so on. It should do -- it is probably derived from the latter by FSUIPC in FS2004, maybe FS2002 also, I don't remember. Try it and see. Sorry, all I know is what is written in the document -- and a lot of that has been supplied by others. I am not aircraft expert I'm afraid. You can easily watch these values live using FSUIPC's Monitor facilities. Regards, Pete

For spoilers just assign them in FS -- Options-Controls-Assignments. Look for "Spoiler Axis". You can calibrate them in FSUIPC as well if you like, but you need no special assignment fiddles as it is part of the standard FS provisions. Regards, Pete

You can only assign buttons for specific aircraft via FSUIPC. FS doesn't provide such a facility. I've not yet got around to dealing with axis assignments in FSUIPC. Sorry. You could assign both at the same time, via the multiple controls facilities in FSUIPC. This is described in the Advanced Users guide. Provided when not in use the controls are not interfering, this will work. Just ensure they are calibrated so that they are stable at "zero" when left "parked". The multiple control facilities already there (which have been there for some time now) are in use by many users successfully. They were really originally intended for pilot/co-pilot pairs, using identical controls. With different types you will need to calibrate them well in Windows to give similar results, as in FSUIPC there will still only be the one airleron, one elevator, one rudder calibration, no matter how many different inputs. But it is do-able. Developing an axis handling facility which is as flexible and useful as I would want is not a trivial task and may in fact warrant a separate program. I have had designs for this on my desk for a year or two, but there's always too much to do to allow me to embark upon such a project. One day, perhaps. Meanwhile I'm sure you can solve it with what is already available. Others have. Regrds, Pete

In FS2000 the axis flags merely defined which axes were present. One bit for each, so "31" means axes 0 through 4 are present. I don't know if these are still used. Things changed a lot in FS2002 when they changed it all to DirectInput. The examples in the FSUIPC User Guide are from FS2000, when I last understood it. Anyway, you won't need to edit that parameter, it is either there or it isn't. I have heard of cases where there are no entries at all. I think FS2002 and FS2004 may be using the defaults in the "DEVICES.CFG" file when there's been no changes made, and only enter the details in the FS CFG file when you have made changes. So now what what? What is it you want to do? Regards, Pete

I just noticed that the bad data read here is actually part of the control area of the READ command (in the FSUIPC request protocol) corrupted by ASCII characters: Offset=786C6564 is 64 65 6C 78 which is "delx" and Size=5C70 is 70 5C which is "p". It looks very much like something involving the name of the path of something on your FS PC (the Server) is getting written into the data area which should be reserved for the FSUIPC interface operation. Your server is named "delxp" and a path to something on it would be \\delxp\ ... This is something of a clue, but not enough to positively identify the module in error. Maybe one of them is reading a path FROM FSUIPC and is not allowing enough memory. Or else one of them is not using the library code I provide and doesn't check the memory allocation so thoroughly. We may be able to identify the errant program by increasing the logging in WideClient, though even then I'm not sure it keeps track of who's who when obeying requests. Try "Log=DebugAll" -- but, beware, the log will be BIG and very difficult to analyse. If you want me to look, ZIP it and send it to petedowson@btconnect.com. Regards, Pete

Oh, terribly sorry -- must've read it too fast. :oops: Actually, it probably isn't FS9. Most of FSUIPC doesn't start until you've started a flight, at least in FS9. This is because there are many SIM1.DLL data sections which are not set up until then and attempting to access them would create an access violation crash. FS2000 and FS2002 aren't quite so drastic -- in FS2000 the SIM1 data areas were mostly in its own data memory (i.e. in predefined areas), so there was no danger of crashing. In FS2002 the areas are created on the heap, but they are all part of one large structure and all created at once. In FS2004 this has all been split into different structures for different subsystems and only a subset of those actually exist depending upon aircraft type, engine type, number of engines, and so on. It is very complicated and, although some stuff may be available earlier, I dare not take the risk, nor wreck performance by making lots of extra pre-checks just in case. The same can apply when you are in other menus or dialogues -- FSUIPC detects this and deliberately stops accessing most of the data -- of course, by then some values will have been set, if they are copied into global or FSUIPC memory (not all are -- if no conversions are needed the mapping works directly to the original data). Before the start none are set either way, hence the zeroes. Regards Pete

FSUIPC and WideFS won't help run FS across two computers. WideFS provides a networked extension of the FSUIPC interface, which is for OTHER programs (not FS) to interface to FS. In other words it'll only help FS performance if you are running FSUIPC client applications as well as FS on the one PC, and these are affecting FS performance because of loads on the processor. There's no way to split bits of FS itself to run on multiple machines. It doesn't even make use of multiple processors in the same PC, yet alone on two! Regards, Pete

The offsets, values and methods are the same for FS2000, FS2002 and FS2004 (probably also CFS2 as well). Please use FSInterrogate to check the values you should be expecting. Please use FSUIPC's IPC read logging to check that you are, in fact, reading the right things. If you don't understand what is going on by all means show me the log extracts, but first, please do use the tools provided. I assume you have registered your copy of FSUIPC? Otherwise your application may not be getting access, and in that case you will get zeroes for most everything. Again, the Log will show you what is going on That is what it is for. You can also verify this by running version 3 of FSUIPC on FS2002 or FS2000 -- I assume you were using version 2 before? Finally, please do not "try several versions of FSUIPC". Only the current one (3.30 at present) is supported. I don't want to see any reports from old versions, please. Regards, Pete

Hmmm. Well it looks like something is conflicting with something else. Unfortunately when there's so many programs competing for WideClient's attention it is difficult ot find out which is actually responsible for those invalid requests. It sounds like it is the GF program you mentioned, but it may be that it induces a confluict somewhere. Why not try programming the RP48 through FSUIPC and remove that application, see if that helps? The currently released WideClient does support GoFlight buttons -- if you've installed the GF drivers on that PC, FSUIPC on the FS PC should recognise all the buttons and dials. Please see the FSUIPC dox. Regards, Pete

Do I? Where? I don't think I do. I thought the problems with the 180 degree sudden wind shifts were mostly with upper winds, and experienced mainly en route, in cruise. Varyinghow fast? The 180 degree wind shifts reported are sudden -- like first one way then the opposite, cause stalls, overspeeds, and jet engine problems -- i.e. extreme windshear. Are you saying you can reproduce those on the ground!? Opposite to what? The ATC and AI system does not cater for wind changes unless and until you restart it, or move far away and move back again. If the wind is changed whilst you are at an airport, neither AI or ATC will change if its operations are already underway. This was the same in FS2002. This won't help with sudden windshear problems (use FSUIPC's wind smoothing for those), but to get AI and ATC attuned to the actual wind, after it has been set differently, you either need to select a far away airport, let that AI/ATC start, then go back, OR you could try programming a Key or Button (in FSUIPC's Keys or Buttons pages) to toggle AI traffic off and back on again. I know this sorts out the AI traffic, but I'm not sure about ATC's own directions to you. Try it. If you are not referring to the upper windshear problem, but simply the lack of ATC/AI responsiveness to weather changes, I don't think this is a bug, it seems to be designed that way. I have no idea when there'll be another FS nor what they'll change if there is one, sorry. Regards, Pete

How odd. What's changed? Now you show a fuller log it is obvious that those lines are shown precisely because they are in error. You have two GF remote packages running. Won't they clash? That's all pretty horrible. The data failures are almost certainly going to be some problem with the applications, somehow. The "missed blocks" at the end may be related to close down actions. Tracking back to see what's changed is needed I fear. Regards, Pete

Please yourself if you don't want to find out what is happening. I just thought you might want to see if it is responsible -- after all you can always put in back afterwards. And there's another thread here, from CaptainKeith, who removed that DLL and got more frames and could still fly the PMDG aircraft okay. Regards, Pete

You changed from using buttons to using a lever? If you assign that joystick axis to Propeller 3 pitch in FS (Options-Control-Assignments), and (before loading FS) set the Flaps control to 66427 in the FSUIPC.INI file, then all you need to do is FSUIPC options is press the "Set" button for the flaps and calibrate it. It will not show changes until you tell it to -- otherwise it could upset a genuine prop 3 input. Regards, Pete

Something is corrupted in FS, or some add-on is overriding the engine selection setting, by the sound of it. The value setting which engines are being controlled is certainly set for all engines by the special control I added for this -- Monitor location 0888 as type U8 (Monitoring is set on the right-hand side of the FSUIPC Logging tab) and see what values are there. If it is 15, that's all 4 engines, 7 three, 3 two, 1 only the first. I can undertstand the E+ keystrokes getting messed up by some of the more sophisticated cockpits, because many of them send many controls to FS and when one gets between the E and the number the subsequent numeric won't do what you thought. Bear in mind that when you install some aircraft, you get more permanent additions too -- PMDG for instance, install a DLL in the modules folder. Maybe that is continuously sending controls even when you are not using the PMDG aircraft? Find it and see if it is okay with it removed. Regards, Pete