Pete Dowson

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

Sorry, I don't really understand what you are saying. If the throttle is not assigned in FS, it won't be seen in FSUIPC. FSUIPC is not a joystick driver, it is not processing joystick inputs, it is processing FS controls. You need to get the throttle working reasonably well in FS first, using standard methods. Regards, Pete

Only delete those which you are definitely re-programming in FSUIPC. Yes, they will both be trying to react otherwise. Pete

No, I don't think it was actually ever offered for download there. There may have been a link to it. In fact (I've just checked) -- there still is. It's the last link in the list of FSUIPC users at the right-hand side of the page. Anyway, glad you found it. I think the FS2004 version is payware -- the FS2002 version was free. Regards, Pete

You can make any button toggle between two actions by using a flag as a condition. It does mean editing the FSUIPC.INI file, and all the details you need are in the Advanced User's document. You need to strudy the "compound button conditions". I will go through how to do this here (I notice it isn't one of the examples in the document, so I may add it): Suppose your button is Joy 110, button 3, and a spare flag (a button on joysticks 0-15 not otherwise used) is 15, 2. Program your button with three lines in FSUIPC (the numbers on the left need to be sequential with whatever's there already, but I'll assume you have no others so will start with 1): 1=P110,3,C1005,3842 ---this says execute Control 1005 whenever your button is pressed. Control 1005 is "Button Flag Toggle". The parameter '3842' identifies the Flag -- 256 x joystick 15 + button 2. So, this flag will now alternate between being set and clear each time you press the button. 2=CP(F+15,2), ... This tells FSUIPC what to do if the button is pressed AND the flag is set. Replace thepart by the Control number and paramter for one of the actions you need. (All the PM controls are listed in the document). 3=CP(F-15,2), ... Similarly, this tells FSUIPC what to do when the button is pressed and the flag is not set. I hope this is clear enough. Regards, Pete

Sorry, you didn't say you wanted PANning actions, not directly selected views. The Pan controls are different. These are: PAN_DOWN PAN_LEFT PAN_LEFT_DOWN PAN_LEFT_UP PAN_RESET PAN_RIGHT PAN_RIGHT_DOWN PAN_RIGHT_UP PAN_TILT_LEFT PAN_TILT_RIGHT PAN_UP PAN_VIEW Of those you probably only want pan up/down and left/right, so you could save one other of the 8 directions for the 'reset' to get you looking straight again. If you keep swapping between 2D and VC cockpits (why?), and you want one mode in one and the other mode in the other then you are really better off using the FS built-in hat programming, which allows for this. Either that or investigate FSUIPC's conditional programming facilities using flags, with a spare button or keypress to swap between the two modes -- that stuff is covered in the FSUIPC Advanced User's documentation and involves editing the INI file yourself. You can't do that sort of thing via the options dialogues. Regards, Pete

Why skittish? If you make a mess or don't like the results, simply delete the Joystick calibration sections in the FSUIPC.INI before you load FS next time. Or reset all of FSUIPC's options to default by deleting the FSUIPC.INI file altogether and making it restore the defaults. What part of the documentation isn't clear, please? I spent a lot of time (and I do mean a lot) on the documentation -- much more than I am likely to spend here, so it is difficult to know how to explain things any better than I have already. I shouldn't need to do this, but here is a copy of the relevant paragraph: Isn't that clear enough? What is it there you don't understand, please? If it is merely how to calibrate the throttle, please simply follow the step-by-step calibration instructions earlier in that same section of the documentation! Regards, Pete

What do you mean by "WideV"? I've never made anything called WideV. The only two products I know with names starting with "Wide" are my own WideFS, which you will certainly see listed in the current versions announcements above, and "WidevieW" which is a program by Luciano Napolitano. The latter is certainly available now for FS2004 -- check his website (http://www.wideview.it). Regards, Pete

Great! Thank you! Pete

That should actually be okay. You certainly wouldn't want it the other way about as that gives straight line cut-off edges to many clouds. Odd, I've made no changes at all to the way the visibility limits are applied, and in an unregistered version there will be nothing done by FSUIPC in any case, except upon external program request. Well, that's something of a minor miracle then, with no changes in any of that area of code. Truly astounding! Well, that's the main thing. It most certainly does. Maybe you have changed from Win98 to WinXP since you last tried the feature, and haven't checked the documentation? WinXP defaults to showing the windows when dragged, and that FSUIPC feature has never been able to work, on Win98 or WinXP, if that is enabled. It is nothing to do with whether it is FS2002 or FS2004. Please do check the documentation when you have an issue like that, in case it is actually mentioned. Regards, Pete

Sorry, there is no way FSUIPC, registered or unregistered, is going to do anything with graphics. I wouldn't know where to begin. You have something else going on there. [FSUIPC always gets the blame for everything, no matter how improbable :cry: ]. I've actually never heard of dark bordered clouds at all before -- the shading of the 3D clouds (at least) is excellent in FS2004. The 2D clouds should be shot though -- check your Options-Settings-Hardware-Weather options and make sure clouds are 100% 3D. Regards, Pete

Yes, of course. And much more. Get the FSUIPC SDK from and check the Programmers Guide document.Regards, Pete

It would help enormously if you could be more precise. I can't understand what changes could have caused this on your system. The only change in the programming of the RIC dials in the last months has been to take notice of the "fast" mode they supply to add/subtract 10 times the minimum increment, so in fact the reaction is faster for the faster turning rate. But that change made it faster, and was a long time ago! With FSUIPC 3.30 and PFC 1.90? There is no way programming the Heading dial to adjuust the heading through standard FS increment and decrement controls will ever be better than the direct control exercised by the default way the PFC driver handles it. For all such numerical adjustments (Heading, Course, Altitude, V/S, Speed, Mach) the PFC programming bypasses all the inefficiencies of using FS controls and actually works on the values insude FS. I spent a lot of time making that the most effective it could be. Please delete the FSUIPC programming for the knobs and retry it with PFC as it is. But please use FSUIPC 3.30. A lot has changed since FSUIPC 3.22 and I want to be sure we are talking about the same thing before I start investigating something which may not need investigating. At present, due to my eyes, I am severely limited in terms of PC work at present, so I can't afford to waste time. Sorry. If it used to work fine, and then, after a change in the software, stopped working fine, why are you now so skeptical that another change won't put it right again? That isn't logical. Regards, Pete