Pete Dowson

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

Ah. sorry. No I don't know how to get that -- wish I could. Pete

No, I cannot intercept the conversation between ATC and AI aircraft. However, yes, of course you can get the current state of AI traffic through the TCAS tables facilities in FSUIPC, at least since FS2004 (not before). Try running my own TrafficLook demo program supplied with FSUIPC -- it shows that state. Documentation for the FSUIPC programmable facilities is found in the FSUIPC SDK. Regards, Pete

Not really. The graphics parts of FS are those which I've never learned anything about nor delved into. That sounds to me like a job for an application, not FSUIPC which is intended as a mere portal. I expect that's because it is treated like the scenery, for which you also need to shut down FS and reload to change. I'm not sure why you think it is actually possible, but even to find out one weay or the other it is going to take some expert in FS graphics (and that's not me) many hours of hacking to get into the appropriate FS modules. If you do this and work out a way to do it, let me know and I'll try to make an interface for it in FSUIPC -- but I think you should be looking forward to FSX now, not backwards to a three year old product. Regards, Pete

Not at present. I am open to suggestions. For instance, if it cannot find FSX (because it is not installed correctly and therefore the Registry is wrong) it would ask the user to locate "FSX.EXE". If it cannot find or create the Modules folder or write the modules there, possibly because something is write protected, it would say so and request the user to rectify matters. The same goes for the DLL.XML file which needs to go into the same folder as the FSX.CFG file -- if it cannot edit or create that the user would need to do it, so there's a reference to documentation on how to do that. Finally, if all goes well, it confirms that FSUIPC version X has been installed and asks the user to check the Read Me file. Confirming the actual version installed may be important as other dependent programs may need that information. Normally, all being well, only the last part is seen. I can suppress any or all of these and instead resturn some sort of error (via what, a little result file?), but you'd need to be able to deal with these things yourself. If it is only success or otherwise you need to know and I suppress the last message, then maybe it would be okay for the others still to be handled by my part? You tell me. I don't know wat you need to do. Note that I cannot rely on other folks' installers doing any of this correctly. They don't even do the simplest things most of the time -- I have always asked for installers to NEVER overwrite a later version, but most inevitably do, and it has created a lot more support work for me over the years. :-( Pete

Please don't get upset. I wouldn't have been particularly upset even if you had been referring to FSUIPC in any case. Folks are entitled to their point of view. In any case, a lot of the adverse initial reaction when I "went payware" was based on a complete misunderstanding. As far as the interfafe to FS was concerned it was and still is free for Freeware, and negotiated for Payware -- just as Adam Szofran's original FS6IPC module was, in fact. The only thing I've been charging for, so that I could afford to carry on developing (and it IS a full time job) are the additional user facilities which user registration provides. Despite this being explained very carefully right at the start, many folks did decide to keep their blinkers on and only see that money was involved, now, whereas, as they thought, it wasn't before. Regards, Pete

You are most certainly getting one of the three parts of the entry wrong. I am constantly surprised at how many ways folks have of mis-spelling their own names, even! ;-) The name, email address (or whatever you used there), and Key must ALL be exactly as notified to you originally when you first got the registration details. If you backed-up your FSUIPC.KEY file, as advised in the documentation, then you could read the details from there to save you having to remember them. The KEY file is a simple text file which you can view with notepad, for instance. Pete

Okay, I didn't need your INI file after all. It was actually a trivial problem, coding-wise, fixed easily (I hope! :-) ). I broke the saving when mending the loading. Sorry. Please download 3.707 now available above. Regards, Pete

Validate the area to be painted. i.e. something like RECT rcl; ... GetClientRect(hwnd, &rcl); ValidateRect(hwnd, &rcl); Pete