Pete Dowson

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

Wherever you like. Give yourself more movement on the forward thrust side -- you don't need anywhere near as much movement for reverse provided it is at least consistent. Many airliners only use two reverse settings in any case. For instance, on the 737 there are three notches. The first "arms" the reverse mechanically, but leaves the thrust at idle, so you don't need that. The third is normal reverse thrust, and the second is used on the way back, when cancelling reverse, to allow the engine to re-stabilise at a low setting before mechanically closing the reverser. They don't really seem to use variable amounts of reverse -- you either need it or you don't. It's only used for a short time in any case of course. The idle zone needs to be large enough to always reliably find it -- if there is much jitter or variation in the readouts your lever gives then it will need to be wider. Things like humidity and temperature variations can affect the values being provided. You must always be able to set idle, else you will certainly have problems. Just experiment till you can get it working well in all circumstances. That's the problem with doing it with one smooth lever slot. I'd recommend making some sort of notch -- a piece of rubber or a sponge gate perhaps, glued to one or both sides of the slot, for instance. A little piece of rounded corner from a soft rubber pencil eraser might do. Oh, hi! Friend of friend! :D I imagine that the discussion was something on the above lines. The other method I had considered for one of my throttle quadrants (an old FlightLink one) was to fit a hinged metal gate across the slot, only moving it out of the way when I needed reverse. This is rather more ambitious though and permanently disfigures your controls. Regards, Pete

It's more likely to do with video drivers or some such than WideFs, which has not substantially changed for a long time. If by "lately" you mean it was okay once, you really need to track back and work out what you changed. The bad data size error is an error from a client program. But one such error will not produce stutters, it is merely a symptom of something wrong in that program. Maybe that is related to your stutters, I cannot tell. You need to ask whoever it is supports the program in question. The ReadLocal lines don't make sense -- looks like things have shifted so the offset has become the size and vice versa. Weird. But if there are commands being sent with 'bad data', then maybe this can happen, so it may all be part of the same symptom. BTW the "ReadLocal" lines should NOT actually be in the log if you are using the standard default settings! If you have changed the Logging to include such data the log file will get huge and certainly not help performance! Set the Log line to "Errors+". Regards, Pete