Pete Dowson

Either delete the F16.GAU from that panel, or register it using the Freeware key found in the Freeware keys list above. Pete

"Joystick chatter"? What is that, exactly? I've not heard that term. D you mean "jitter"? In that case it sounds like turbulence, nothing to do with the joystick at all. There is no way the weather data and the joystick inputs are related. No. FS's own weather downloads are nothing whatsoever to do with FSUIPC. You surely don't think Microsoft would add facilities to their programs which only work if you add third party programs like FSUIPC? Your downloaded weather would be the same whether FSUIPC were installed or not -- except there are some filter facilities you could try if you liked. Take a look in the FSUIPC user documentation. I'm afraid I cannot remember what worked and what did not with FS2002 weather, that was all done five years ago! If you are getting too much turbulence, I think you can tell FS to not include it in the downloaded weather. Mind you, I'm not sure about that for FS2002. You could also try the turbulence suppression in FSUIPC, but I think you'll need to check the documentation to see if that applies to FS2002 downloaded weather -- many of the filter facilities only ever applied to weather from external programs, like FSMeteo or ActiveSky. You can also turn dow the realism options in FS's Aircraft menu. If you have those turned up too high the effects are grossly exagerrated. They should be mostly near centre. Regards Pete

Yep! I think the term "weird" applies there :wink: Clever, but weird too! :) Thanks for the explanation! Pete

Have you noticed any of the announcements above? Please peruse them. Even the titles may suggest the answer. If you registered in 2006 then version 3.47 won't work -- and in fact the notification you got from SimMarket would have told you that, quite clearly. The current version is 3.70. I cannot support anything before that. Regards, Pete

In that case it would be nice if you could explain this in more detail, don't you think? ErI'm not understanding that AT ALL! You are trying to orient the heading of the aircraft, andit does what? If you only read the Mag Var AFTER it has been moved how on Earth can you correct a Magnetic heading to a True heading to set the desired heading correctly? Tell me what you want to do, what you write and what you expect. Have you considered using FSInterrogate to experiment with all this before embarking upon something you don't fully understand? I'm sure it would help! Is that meant as sarcasm? If so, please explain yourself. I have tried very hard to explain something which should be obvious. If you are hiding half of the information (like the fact you just stated, that don't even bother to read the Mag Var till too late), you can hardly expect me to provide the answers you desire, now, can you? Pete

Yes, of course. They are both numbers in hexadecimal. Decimal numbers don't contain digits like 'A'. All FSUIPC offsets are known by their hexadecimal value. No, x07 means bits 0, 1 and 2. It is a number. Usefully, 7 in hexadecimal happens to be the same as 7 in decimal, but expressed in binary as an 8-bit byte it is 0 0 0 0 0 1 1 1 Bits are numbered from the right-most (the least significant) 0 up to 7 for the top bit. Thus your bit 7, in binary, looks like this: 1 0 0 0 0 0 0 0 In terms of decimal, bit 0 is worth 2^0 = 1, bit 1 is worth 2^1 = 2, bit 2 is worth 2^2 = 4, and so on, up to bit 7 which is 2^7 = 128. See? The value multiplies by 2 for each higher bit. This is called BINARY. In decimal, each higher digit is worth TEN times the previous one. This is how 0 0 0 0 0 1 1 1 gets to be worth 1 + 2 + 4 = 7. So, the parameter you want has to be 128 (for just bit 7). This will look like x80 in hexadecimal. In Hex, bits are in groups of 4 (because 2^4 = 16): 1000 0000 The left "nybble" (as it is often called -- "byte" --> "nybble", see?) is 8 in decimal, the right is 0 in decimal, hence x80. Really this sort of documentation should appear in the Project Magenta documentation website. Have you looked? If not, maybe filing a suggestion with their support might help others. Regards Pete

Yes, as I said. Yes, I understand that as well. they do the normal game device USB versions to sell as separate units to folks who don't need or don't want one of the units with the digital controllers (it is their digital controllers which my PFC.DLL interfaces to across a serial connection). That I cannot answer as I've never had them connected any other way. I prefer it all to be controlled from one place. I have no idea what their Windows joystick driver for those is like, nor whether it supports all of the switches on the yoke. Sorry. I would have thought that the only possible advantage of having them as separate devices is that you can sell them separately if you like, rather than have to dispose of them as a complete set, should you ever want to sell them in the first place. I cannot judge any possible disadvanges because I don't have such devices to try. As far as the facilities in my driver are concerned why not just download it and read the user documentation? There you aregreat minds;-) Pete

Not heard of "perfect flight cirrus". Are they the PFC devices marketed under someone else's brand? The PFC.DLL I provide is for all PFC devices using the digital controllers, connected to the PC either via a serial port link, or possibly a USB one using a serial port adapter or driver. Sorry, I've really no idea as I've never had PFC devices connected directly. I think you'd need them re-wired in any case to route them via the digital controller. However, these are most certainly questions you should direct to PFC if they are, indeed, the makers of your devices. Oh, you've not even got them yet? Where does this "Perfect Flight" name come into it? I'm a bit confused now. "PFC" is "Precision Flight Controls". I don't see why connecting them as game devices direct to the PC and having standard Windows drivers handle them makes them any better than what I can do with them via PFC.DLL. I would have thought having an integrated system would be more an advantage. The only advantage i can thing of having them as separate standard-type deives is that you could seel them separately. If they only work with a controller you'd have to sell them as a complete system. More realistic than what? I wrote FSUIPC.DLL and PFC.DLL. Why should I deliberately make one worse or better than the other? Regards Pete

What's the difference between reading and writing. Can't you simply reverse the computation? MagVar of +20, not -20 I assume you mean? There's 40 degrees difference! Why bother with a programming language to show simple arithmetic? True heading is 100 + 20 = 120 (if you meand -20 Mag Var, then it would be 100 - 20 = 80). Then just do the conversion to FS units: 120 x 65536 x 65536 / 360 = 1431655765 Write 1431655765 to offset 0580. That's it. A doddle, eh? ;-) Why don't you play with FSInterrogate a bit, get the feel of all this. It strikes me that you haven't got the hang of it at all at present and you are making very heavy weather of something as simple as A B C. Regards, Pete

Well, only the VOR2 has changed, and then only its location. Seems like PMDG have some weird programming if they let a wrong position on one affect the other. Pete

Did you read my last message yet? Anyway, please try 3.708. This only fixes the VOR2 position problem -- I cannot fix VOR1 because all of the values I am supplying are fine. I have double-checked this. Regards Pete

When you re-arm the A/T do you also then re-enable the appropriate thrust control mode in the A/P (IAS/Mach Speed for instance)? If you disconnect the autothrottle the speed modes turn off too. Always test default aircraft first. I couldn't possibly hazard any guess as to how add-on aircraft behave. You'd need to check with their documentation. Pete

I checked all of the values FSUIPC provides for both NAV1 and NAV2. They are all okay for NAV1 (VOR1) -- nothing wrong at all. For NAV2 (only) I have an error in the table for FS2004. The Latitude/Longitude/Altitude values and the localiser/glideslope angles aren't being filled in for the NAV2 positions. The DME distances, speeds and bearings, plus the flags, and signal strength needle values are all fine. Only the poisitions and orientations aren't being given, and that's for NAV2 only. I'll fix that in version 3.708, probably by Monday. Please re-check what you are seeing more thoroughly, as I am sure all of the VOR1 data is perfectly correct. It still surprises me that PMDG gets these via FSUIPC. Regards Pete

I wouldn't have thought this could be anything to do with FSUIPC -- surely PMDG panels get their radio data direct from FS? I would be uttelry amazed if they are using FSUIPC for this when the standard Gauges interface to FS supplies all that in the ideal form for their needs. Can you check with PMDG please? Also try without FSINN. Why are you reverting all the way back to 3.53 anyway? That's no help. Doesn't 3.70 itself work in this respect? Pete

FSUIPC only lists these because they are the A/T controls offered by FS. FS doesn't provide an "Autothrottle disconnect" as such -- the "Arm" control toggles. You could just as easily assign these in FS's own assignments. Well, you can do that via the axis assignment because you can program it to send controls at certain values as well as operate an axis, but I fail to understand why you think this is "perfect" -- mostly you would want the A/T still engaged during descent even though you would have certainly pulled the throttle back to idle. Where is this "hint"? I don't remember ever writing anything for A/T disconnect. FS has never provided a control to do this specifically -- only the ARM which is a toggle (i.e. it turns it on if off, off if on). Prject Magenta and my PFC driver both support AT on/off switching -- they do this by writing a 0 or 1 to the A/T Arm offset in FSUIPC. You can actually program Offset operations in FSUIPC's Button Assignments, but you really need the FSUIPC Programmers' Guide out of the SDK for a list of offsets and their functions. The offset of AT Arm is 0810 (hex) and 1 switches it on, 0 switches it off. Regards Pete

The main one, the one I use, is Project Magenta. But it isn't cheap. It boasts the most complete set for airliners, and there is also a set for GA aircraft. See http://www.projectmagenta.com. There used to be a freeware set called FeeFDS, but I've not seen that available for a while. Don't know why. There's a freeware reduced function FMC+ND called "vasFMC" by Alexander Wemmer, which is quite handy -- http://vas-project.org. You could try checking through the partial list of FSUIPC-compatible programs on the http://www.schiratti.com/dowson page. Other that that, I suppose browsing the Forums or Googling might uncover something. Regards, Pete

What programs are you using for these gauges and controls? If they are all FSUIPC-interfacing programs all yuo should need to do is to run them on the client when Wideclient is running. In fact you can get WideClient to load them for you using the "Run" or, better, "RunIf" parameters in its INI. If you are referring to FS's own panel gauges then these are part of FS. They are not FSUIPC programs and cannot be run outside of FS. They aren't even separate programs, "GAU" files are not a lot more than sets of instructions for driving FS graphics. I'm not sure where this "fs commander" comes into the equation. Regards, Pete

You sent two nearly identical versions of this. I've deleted the earlier one. I don't understand what you are trying to do the "360-magv" in each case? All you should really do, in all cases, is "normalise" the results you get: Headings have a range of 0-359, MagVars a range of -180 to +179. So you just need to add or subtract 360 untl they are in the correrct range. In fact, unless you need the separate values, you don't need to do it separately at all. It all simplifies out quite well. Just add the two (when converting MAG to TRUE) or subtract MagVar from Heading (TRUE to MAG) no matter whether either are currently in the correct range, THEN normalise the result by adding or subtracting 360 till in range. I'm afraid that you are making too much heavy work of something pretty simple. But I cannot show you correct VB code (or whatever it is your are using, which is not C). Regards Pete

Er"managed to get" it installed and working? You make it sound like a difficult job? All you needed to do was copy the FSUIPC.DLL into the FS Modules folder! Was that arduous? :-( Anyway, as far as I know Richard's code includes the proper access key and that will work fine with any version of FSUIPC. I should automatically register, you need no separate key. No, please do not. Take a look at the FSUIPC Log instead (in the FS Modules folder). Show it to me if you don't understand it. Make sure you close FS first please. Regards Pete

Okay, I looked at your thread in the other forum. I see you are using the latest WideFS and that somehow WideClient is actually getting tied up in such a way that you have to kill it with the Task manager. I'm not sure how that can happen, so it is worrying. The Network part of the program is in a different thread to the main one which interfaces to the application programs -- if some Network call made by WideClient simply never returned from Winsock I'd still expect the main part of the program to be responsive. The only times when the main part appears unresponsive is when an application program is calling it so frequently that it never gets a chance to do anything else. So, this suggests one or two avenues for investigation: 1. Try no applications, just Wideclient running, then start your FSXpand partresults? 2. If Wideclient didn't lock up in (1), try a simple WideFS application, like WeatherSet or TrafficLookbut just one at a timeresults? 3. Take the very simplest example which locks up and run it with full Debug logging in Wideclient. To enable this, edit the WideClient.INI file with "Log=Debugall" in the [user] section. This will produce a huge log so don't run it too long -- only till you get to the "frozen" situation. ZIP the log and send it to me at petedowson@btconnect.com and I'll see if I can make any sense of it. Regards, Pete

What is that? Sorry, without having any idea whatsoever what the other software is or what it is doing I really have no way of suggesting anything. If there are no errors listed in the Log then I can only assume that something in the other software is somehow causing things to lock up in Winsock (the Windows network software). I really no nothing more about Networks than what Microsoft publish in their APIs, and the Network code in WideFS is lifted straight out of Microsoft examples. Regards Pete

Oh, strange ... Pretty standard format. Should be no problem. Same there. It's a little worrying. Please let me know if it happens again. I would need to get to the bottom of it. Thanks, Pete

Yes -- that's the problem. The "graphics speciality" I meant was specifically FS graphics modules, someone who, burrowing into FS code, would be able to actually recognise what he saw. You need to be able to get the correct procedures called to activate the changed files. Yes, exactly, although I think even then you might be over-simplifying matters. I went through all this with weather, and in the end had to give up. The data imported to set the weather is processed through so many levels and in so many forms that it really was never a simple "overwrite this with that" business. Yes, that's a start, and then there's the need to call a whole succession of routines which actually bring those changes to fruition. I managed it for global weather, but had to give up on the local weather stuff. Regards Pete

Eris this specific to 3.707? The only change was to the Joystick Calibrations. Are you saying that NONE of your button settings are saved? At present I'm not seeing the significance of all the details you are providing for this particular assignment. Is there only a problem with that, and nothing else? I mean, if you assign it to something simpler or different, is it saved, possibly indicating some formatting problem with this specific arrangment? I'd like to seea before and after INI file section for this please, and some clarifications as above if possible. Thanks, Pete

Someone has already pointed that out. I've informed SimMarket, who deal with the commercial and legal stuff. Thanks! Pete