Pete Dowson

No need for an "advanced" copy now -- get WideClient 6.771 from either of the download announcements above. I've included a User Guide with an updated ButtonScreen section. Regards Pete

Thanks for the Log file data. Sorry, i seem to have made a mess of the thread and actually lost your reply -- but i did study it first. The log seems to indicate that FSUIPC is sending the brakes control, but it evidently doesn't arrive. I'll take a look here with the latest interim version I was about to put up today. ... Ah. The log from this one is different. It looks okay. Please try this: http://fsuipc.simflight.com/beta/FSUIPC4327.zip Let me know, please. I'm getting ready to put this version into the FSX Downloads announcement above. Actually, I think I will anyway;-) By the way, didn't you confirm that you got the same problem with the assignment in FSX instead of in FSUIPC? Not sure how FSUIPC would get involved then, unless you had it calibrating the brake axes too -- then I think it has to deal with the BRAKES LEFT and RIGHT controls as well as the AXIS controls. Regards Pete

Oh, right. Even if you press them again, you mean? We're not talking about holding them down? They only work once per FSX session? Or once per aircraft load? What makes them work once again, only reloading FSX? And this is the same if you assign the same buttons to the same functions in FSX instead of FSUIPC? Right. So this seems to eliminate a problem with the buttons themselves, presumably? Otherwise I was going to suggest some simple checks: 1. With the brakes assigned in FSUIPC, go to FSUIPC's Logging tab and enable both Button and Event logging. Then operate the brakes until they appear to stop working. Check the FSUIPC4.LOG file (in the modules folder). Show it here if you don't understand it. 2. Use the attached joystick display program, "DIVIEW", without FSX running, to see if all the parts of your joystick are working okay. I can't think what it could be. But first, let's clarify what, exactly, brings the brake operation back -- only reloading FSX, or loading an aircraft or a flight, or what? Might you have some other add-on which is specifically inhibiting the brakes, maybe because of pneumatic pressure being low, pumps not on, that sort of thing? Some of the more sophisticated add-on aircraft will do such things. The brakes when first applied use up what pressure remains in the cylinders, and then you cannot brake again until building up more pressure via electric or engine pumps. Such an add-on may not check against the simple "brakes" control because that isn't a real aircraft facility unlike the separate toe brakes. Regards Pete DIView.zip

It looks like the reason for the lowest increment being less than the others was to get the rest spotted more centrally in their "zones", matching FS's values more consistently. It seems, however, that this 'correction' is lowering the top value enough to defeat PMDG's code. Please try http://fsuipc.simflight.com/beta/FSUIPC4327.zip and let me know. I've adjusted only the top-end, so if it is the top value i use 16383 instead of whatever the relevant number of increments provide. Regards Pete

I suspect that's because PMDG is doing its own thing here, and"Flaps1" has no trailing edge flaps I think, just leading edge slats which are simulated in its code not in FS. It also must be intercepting the 16254 I'm sending for full flaps and deciding that isn't enough. Their code evidently hasn't much idea of a "range" of possible values for flap notches. I can only suggest that I investigate why my increments are not as even as I would have thought, and try to fix that for you to re-test. I'll let you know. No, no need. In any case you should always ZIP things. For pure text, which is what logs are, you can paste the relevant extracts into your message in any case. If the only logging you enabled was the monitoring I asked, and you only operated the flaps once, it should be very short in any case. Regards Pete

I've a new interim version of WideClient nearly ready (just some documentation to do, for the new facilities) which, i think meets all your needs: Instead of this fixed method I've allowed user defined buttons for "Previous", "Next" and "GoTo". They can be where you like on the page. The "GoTo" doesn't refer to a page number (because if you change the configuration the buttons will change pages) but to a paramter numer in the INI file. i.e. a button definition. The current default Prev and Next buttons only appear if no user-defined Prev, Next or GoTo appears anywhere on a page. I've allowed 8 background colours to be defined -- the 4 already used and 4 new ones. I think that should be enough. If the background is dark it automatically changes the text to white. Let me know if you would like an advanced copy to test. Regards Pete

That's totally weird. Monitor 0BDC as U16 for the flaps control, 0BE0 and 0BE4 for left and right flaps indicators, also U16. If you set this to display in the FS window and in the Normal log you can see them in real time and also the Log will contain the SimConnect reads and writes. 0BDC goes to 16384 here when FSUIPC sends its top value. I've not idea why that doesn't work for PMDG. Maybe I need to stretch the values over a bit more. The fact that my first increment is less than the computed value disturbs me a bit. I wonder if that's a new thing. I'll trace it here, see why. Regards Pete

Now I am getting confused. Are you saying these red brake buttons you are using are actually analogue axes, not buttons? You use the calibration page to calibrate axes, whether you assign them in FS itself or in FSUIPC. It isn't mandatory unless you are assigning axes "directly to FSUIPC calibration" in FSUIPC's axis assignments. But what has this to do with your brakes buttons, or are they axes? Reinstalling FSUIPC changes the FSUIPC DLL for an identical FSUIPC DLL. Not sure what else you possibly accomplish. It has no other dependencies. If you simply want to remove all of your settings so everything reverts to defaults, just delete the FSUIPC INI file before loading FS. It wwill make a default new one. I didn't understand that from the original post. But it sounds like you deleted all your settings for FSUIPC and now you don't understand how to set them again. And I cannot help you whilst there's this confusion over whether you are talking about buttons or axes. That is totally symptomatic of a button being pressed once and not set to repeat. Like pressing the F11 or F12 key on the keyboard momentarily. Regards Pete

And what are they? Are you calibrating the detentes in FSUIPC, or just letting the positions take care of themselves? 6 increments at 5460 gives a range of 32760, which is so near the maximum of 32767 that I can't see how it could fail to reach. I can try it here on the FSX default 747. [LATER] Okay. it works okay here with the default 747. The 7 values I get are -16383, -11052, -5592, -132, 5328, 10788 and 16254. Not sure why the first increment is 5331, but the rest are 5460 (well the last is 5466, but close enough). But nevertheless, they all work. Regards Pete

In either case you'd need to enable "repeat", because the action of a button going from not-pressed tyo pressed is what instigates the brake control, and not the fact that it is held down. Key presses would be the same it it weren't for the automatic repeat you get on keyboards. Buttons aren't "calibrated" in any case. Only joystick axes are "calibrated". Calibration means setting minimum and maximum values and centres to suit the particular lever. You mean ASSIGNMENT. Just don't assign the same axes or buttons in both FS and FSUIPC at the same time, unless you really want two things to happen, possibly conflicting. I didn't see you say you had it working until some change other that you did mention "I've just reinstalled", but you didn't say what you reinstalled. What exactly was the change? Did you delete your FSUIPC INI file by mistake and thereby lose all your settings? As I keep repeating, have you checked the repeat option? You don't seem to be reading my suggestions. :-( Pete

As Jeff says, the FS brakes controls are only operated when pressed. With the keyboard holding the key down causes the automatic keyboard repeat action to occur, and this gives you continuous braking. If you assign a button to do the job instead, it has to be explicitly set to repeat whilst held, as many uses of buttons do not want repeating to occur. If you are assigning the buttons in you will see the repeat whilst pressed option on the same tab as you used to make the assignment. Also make sure you don't have any buttons assigned both in FSUIPC and in FS, as they will both be doing whatever they are assigned to do. You may actually want that, but that's rather unlikely. Regards Pete

DON'T! Use the FSUIPC options dialogue for assigning buttons, as intended and documented! I just gave you exact steps! Pete

Unfortunately Microsoft's installers do NOT reinstall SimConnect if remnants are still there. It is a bad failing of the Windows "side-by-side" library system, a result of their over-protection against possibly corruption making it difficult to remove corruption. Please see the "FSX Help" Announcement above which tells you how to reinstall the base version of SimConnect from the DVD -- it is this version which is corrupted! If you are using Vista you might find it more difficult. You would need elevated administrator proivileges at least. Folks have re-installed Windows for less! Regards Pete

You can only do that reliably by using the Offset controls to write directly to FSUIPC offsets. For information on offset values you need a document found in the FSUIPC SDK, available from the Schiratti website. Here's the entry in the "FSUIPC for Programmers" document for the Sim Rate value (I simply searched on the word "rate" till I found it): 0C1A 2 Simulation rate *256 (i.e. 256=1x) So, for your needs, the FSUIPC control to be assigned would be: Offset Word Set (Word because the offset is 2 bytes. 1 byte = Byte, 2 bytes = Word, 4 Bytes = Dword) with the offset field then set to "x0C1A" (the x tells FSUIPC it is in heXadecimal -- all offsets are known by hexadecimal numbers), and the parameter field set to: 2048 for 8x (this being 256 x 8 ) 256 for 1x Okay? Pete

Yeah, it should show GLOB. It does in FSX. Some sort of timing change in FSUIPC3 I think. I'm not messing with it now unless it turns out to be a problem, as it seems to have been like that for a good couple of years. If it allows you to set weather, it's on "GLOB" and if not it's only weather at aircraft. Oh, right. Yes, sorry, I forgot that the final 3.81x interim was released as 3.82 and everything was changed except I forgot to update the dialogue. Apologies. It was fixed in an interim update to 3.821 immediately after. Incidentally, you can also see the correct version number at the top of the Log file. Please use 3.845 then I won't be confused! ;-) Regards Pete

Well, not dread, but i must admit I cannot fathom what it is you are trying to prove. All of what you appear to be investigating is old hat. FS2004 weather and all of its ins and outs was sorted years ago. There's going to be no changes to any of the interfaces. They work quite well, better than FS's own facilities, and there's no more that can be done with the FS9 weather engine. For that matter, there's going to be nothing further done for FSX either, but for different reasons. It needs to be sorted in SimConnect. I'm not about to go through the same hacking hell as I endured for FS9. The next change would be for ESP2 or FSXI, whichever is first. You say that, but absolutely nothing in what then follows points to anything in the NWI wrong at all, only in the FS dialogues. You even reproduced a log extract showing the weather logged in other ways. All this is data extracted from FS. You didn't even bother to check which was correct, either, did you? If you'd bothered to slew up to 25000 feet and use Shift+Z to see the weather actually at that altitude you would have found WeatherSet2 and the logging to be accurate (when you do this, bear in mind WeatherSet uses TRUE whilst the Shift+Z display is MAG). All you are doing is proving, as others have before you, that FS's weather setting dialogues are pretty useless for setting weather very precisely. They are, in a word, buggy. If you want to set weather reliably why not use WeatherSet2 for this as well? To do your experiment: First slew up to 25000 feet and do Shift+Z twice to show the wind there. If you slew up after setting the wind it may well have changed by the time you get there owing to FS's dynamics. Load WeatherSet2. Clear all weather (Clear menu, "clear All"). Place cursor on the "0" under "Station" and Press Enter. Type GLOB for the station name (or your airport if directly over one) and press Enter. Place the cursor on the "1" under "Winds". Press Insert. Enter the wind data -- 25000 feet, 50 knots, 358 True, or whatever. Press Enter Check the readback in WeatherSet2 (degrees True) and that on the FS screen (degrees Mag). What more do you want? WeatherSet2 is 100% NWI. No other tricks. Everything it does you can do through that interface. It is supported and it works. No, they are not totally different. Most of the old bugs are there, and they added some more -- more complex ones. Also, because FSUIPC no longer hacks into FS code to control or read the weather, but relies on the promised facilities in SimConnect, it cannot set or read so much. Cloud types and thicknesses, for instance, are not directly controllable, and thicknesses impossible to read. The visibility is only indirectly manageable. The winds have a habit of multiplying spuriously in numbers of layers, and still exhibit near 180 degree shifts in direction. FSUIPC tries to overcome some of this, but doesn't entirely succeed -- which is why most of the weather filtering facilities in FSUIPC4 are defaulted off, and only provided as options with health warnings attached. ASX also does its best with FSX, and, because it is a weather setting program, unlike FSUIPC (which tries to be a weather assisting program), ASX is rather more successful in achieving its aims. But it has been a great deal of trouble to do for its author, and it still isn't 100% satisfactory, only the best likely to be achieved at present. BTW if you want support here to continue will you kindly update your FSUIPC. Versions 3.81X have not been supported since 3.82 came out in July, and the latest interim update to that is 3.845. So, 3.820 is the earliest you can be using for any form of support. Please do read the relevant Announcements above which tell you these things. Regards Pete

Yes, and in the process the COM port number may have changed. I don't know of any problem with Vista privilege levels as far as any modules internal to FSX are concerned. The PFC driver is acting simply as an extension to FSUIPC. In fact all of its operations with SimConnect are conducted via FSUIPC4. I suppose there is a remote possibility that your COM port driver won't work in Administrator modes, but that seems so unlikely. Or possibly the COMMs operations run in normal mode in any case and suffer from the inability to share memory with an Administator privileged level. If this is the cae you have no solution but to run FSX normally. Come to think of it, as a test, why not simply try running FSX, without SB4, in normal user mode? If that works then you know you have to get the SB4 folks to sort their problems with Vista out, pronto. they should be, in any case. Either that, or maybe you'd need to re-install FSX someplace else than that dreadfully long-winded and now over-protected Program Files place! That's a problem using beta software -- you act as one of the guinea pigs. If I were you I'd certainly be making sure SB4 folks know that it isn't a good idea to force FSX users into Administrator mode. It should never be needed except possibly for installation (where it is usually automatic in any case). It will certainly clobber all other local FSUIPC clients unless you also run those in that mode too, as it blocks off the memory sharing needed. Regards Pete

GPSout functions are built into FSUIPC4 for FSX. It is no longer a separate DLL. You need to purchase an FSUIPC4 registration key. Regards Pete

Ugh! That is really bad. Is this, perhaps, because you let FSX install into its horrible default place? Under Vista all of the Program Files folders are protected against writing even by the programs which read from them. The FSUIPC4 installer overcomes this by changing the access permissions on the FSX Modules folder. Maybe SB4 (still in Beta I believe?) should be doing something similar? You should write to the authors. Are you sure the COM port is the correct one? Just because it can open the port you've given it doesn't mean it is the one to which the device is connected. Yes, but port numbers won't necessarily be the same with a new operating system. In fact I've found that Vista often renumbers USB COM ports at the drop of a hat -- usually when something else is changed. I had that recently when I simply removed a sound card, which has no ports at all. That's the most likely problem. You could tell the PFC driver to abort the checks and carry on in any case, and then go to its Flight Controls and Test tabs to see if anything gives any response at all. If not it has to be either wrong COM port or driver (USB/Serial driver, perhaps, not Vista compatible?), or hardware. There is nothing Vista / XP dependent in either FSUIPC or PFCFSX. Regards Pete

Yes, certainly. Oh, I see now. ;-) The graphics in the VC are operating correctly, but you expected to see them reversed as you have set your pedals! Incidentally, the facility to reverse an axis is present in the FS axis assignments dialogue as well. It isn't just the preserve of FSUIPC. It is normally of main use for things like spoilers/speed brakes, and flaps, where the lever is pulled towards you for the higher/active values rather than away, as for throttles, propeller pitch and mixture. Regards Pete

Well, that's plain wrong. Why would you want the rudder reversed compared to the way it is in a real aircraft? Sorry, I've no idea. I've never used a VC. You need to ask an aircraft designer. Regards Pete

But did uninstalling remove all the PMDG modules from the Modules folder? In my experience, it doesn't. Otherwise there must be some other rogue DLL or program interfering. regards Pete

And have you set the port and speed correctly in the INI file? Have you set the Garmin GPS to receive NMEA positional data from its COM port? I wouldn't know how to do that. I have three Garmin GPS units and none of them will go into such a mode. The PC will not recognise anything on the COM port. It does not read the port. All it does is through data out. It is up to the GPS to read it. Sorry I don't know the unit at all. Did you search on this forum? I'm sure someone has mentioned that GPS before. You have two COM ports on the GPS? How do you know it is using the right one? Are they set to the same speed you've told GPSout? The "manual" is the text file with GPSout which lists the NMEA sentences and other data modes you can select from, and tells you to set the port and speed to suit your device. There's nothing else to add. You need a manual for your GPS. Are you setting the right more, the right speed, the right port, and the right selection of NMEA sentences or other data (maybe "AV400" for "aviation" mode?)? There's nothing else. Regards Pete

All the choices are in the manual, but they are yours to make. There are several ways of assigning and calibrating joystick axes: 1. The default method in FS is for them to be assigned in FS and only pre-calibrated in the Windows "Game Controllers" applet (part of the Windows Control Panel). In fact no matter what else you do, you should always first check and calibrate axes via the applet there, as the data seen by all other software routes through the Wndows joysticks driver. Some joystick devices come with more complex or more flexible drivers which enhance the default methods in Windows, but it still remains the first "port of call" for any device you add. 2. With FSUIPC, once the axes are working reasonably well in FS using the normal default methods, you can calibrate for greater precision or more flexibility -- like having a reverse zone added to the throttle lever(s), or applying a response curve to vary the sensitivity for greater precision near the normal central control zones. And so on. This is the long-standing facility for Calibration in FSUIPC, the facility which has existed in the program for about ten years. It does not involve nor require any change of actual assignment -- you do not need to use the Axis assignment facilities in FSUIPC at all (all those are relatively recent). 3. More with FSUIPC can be done using the axis assignment. These facilities were added mainly for the benefit of cockpit builders or those with several alternative forms of aircraft control. They offer greater flexibility than the default FS assignment methods, and in particular allow the assignments to change automatically with different aircraft as they are loaded. For example you might have a set of helicopter controls assigned for helicopter flying, a joystick set for military jets and Airbus's, and a standard Yoke for Boeing and MD airliners. FSUIPC axis assignment can handle different assignments for these. Assigning in FSUIPC does not (cannot) override assignments in FS -- if the same axis (or button) is assigned in both, then both assignments operate simultaneously, probably resulting in some surprises. In general it is easier (but not essential) to either do all axis assignments in FS, with buttons programmed wherever you like, or disable the joysticks entirely in FS and do everything in FSUIPC. When assigning in FSUIPC there are two sub-options which you'd see on the assignments dialogue: 3(a). Assigning to the normal FS controls. This routes the results of the assignment back to FS where they act just like they would if assigned in FS. They may then be used directly, or still optionally calibrated in FSUIPC as you wish. 3(b). Assigned to operate directly to the FSUIPC calibration. This is more efficient, bypassing FS altogether until AFTER FSUIPC calibration. On FSX, in most recent versions of FSUIPC, this method also bypasses SimConnect for even more efficiency. Because the routing is via FSUIPC calibration, such axes MUST be calibrated in FSUIPC or they won't work. There is one potential disadvantage with this last method (otherwise it would probably always be the most appropriate for ambitious users). That is, because it bypasses FS and doesn't route the FS Axis controls in the normal way, it can defeat the way some add-on aircraft work -- probably in particular those with Fly-by-wire. However, there do not appear to be many so adversely affected. ------------------------ Anyway, in conclusion, as you see, FSUIPC is like the Swiss Army Knife. It provides a wealth of tools for you to use as you wish. It does not impose anything, so there are no rules. But like any such tool, you can cut yourself if you aren't careful. If you ever get in a mess with it, just reset it to default where is again becomes innocuous and dormant -- you can do this easily by simply deleting the INI file (its configuration settings) from the FS Modules folder. Regards Pete

That should therefore have been one of its temporary weather stations. Not sure why it didn't 2take" if so. I'm afraid that's a subject I know little about. In FS9 it was actually possible, with some exceptions, to control the weather more precisely, because (and only because) I spent many hundreds of hours hacking into the FS code to work out how to do that. There were no Microsoft-supported ways for external control of FS weather before FSX. I did not do the same for FSX because it was all supposed to be supplied, officially, by SimConnect. We knew, when FSX was released, that it wasn't all there, but at that time MS had good intentions of providing ongoing regular SimConnect updates to complete the facilities as originally intended, much like FSUIPC3 had to be slowly completed as more was done and learned. Unfortunately, that ongoing development wasn't to be, and what we currently have in FSX is less control over the weather than we've had in any previous version. Given the problems SimConnect weather control presents I find it quite impressive that ASX manages to achieve what it does. I'm afraid that most of the real answers will not be forthcoming until FSXI, or whatever it will be called. At least I certainly hope they will have fixed the weather engine and the facilities offered to control it by then. Regards Pete