Pete Dowson

Well, really that either indicates that the Networking components of Windows were not truly re-installed when you tried that, or, possibly more likely, that some other process had got into your system and was somehow interfering. The only example of such a thing I can remember occurring was a Kensington mouse driver which also affected FS installations. It will probably be another process or service doing it on the other PC. If it mattered to you you could probably find it by a process of elimination, using the "Kill Process" option in the Task Manager. Some processes when killed may affect the system, but it isn't a permanent problem as a re-boot would get them all back. Once the process is identified in this way, it's then a matter of finding why it is loaded and what product it is associated with. Regards, Pete

Maybe something in the [Panels] section -- Image quality, or something? Regards, Pete

That's suspicious, because FSINN isn't an FSUIPC application so it doesn't use WideFS. If SB3 loops tight on Wideclient and allows nothing else to run, you can try slowing it down by setting the ApplicationDelay parameter in WideClient.INI. See the WideFS docs. Try 50 first, then reduce it. It really shouldn't be needed for well-behaved Windows programs which process messages. And it shouldn't be a problem on WinXP which is better at timeslicing. Are you using Win98 or WinMe perhaps? Again, I don't see how FSINN comes into it. If that creates the same problem then it is sounding more like a Network issue. Regards Pete

Log... something or other. It won't be there unless you've enabled it. The Advanced User's document lists all the parameters. Generally it's easier to enable such things in the dialogue. I assume you don't have the culprit aircraft loading as default, so you shouldn't miss anything. Regards, Pete

Seems that whatever they do they have some common code which is used by every gauge. Sorry, I'm out of ideas. If you enable IPC read/write logging in FSUIPC, and make sure you have no other FSUIPC users running (remove SB3 for now), then maybe you'll get some idea of what they are doing. There may also be a huge amount of control posting -- the FSUIPC event log can show those. I wouldn't think you could 'fix' it even if this dows show the reason, however. Regards, Pete

I'm pretty sure the middle one is wrong. 180 Mod 90 should be 0. This is the same as the % operation in C/C++. What an odd way to do it. Don't you have PI defined as a constant? An angle of 45 degrees provides a Tan of 1.0, so the ATAN of 1 will give the radian equivalent of 45 degrees, but it's an odd way. Don't know what that means. And it isn't used below. You use 127.3125 instead? You exclude exactly 0, 90, 180, 270 from possibility? Sorry, but you need to use a debugger to find out what is wrong. I assume VB comes with a debugger so you can trace through the results? If not, I would strongly advise a change of language. debuggers are essential. Regards, Pete

Installation is only a matter of putting it in FS's modules folder. If it is there, FS will load it. Check by going to FS's menu, Modules-FSUIPC. FSUIPC only provides button and switch programming facilities. It is not a replacement for anything GoFlight provide. However, to complement FSUIPC's button programming I have just recently provided a separate program called "GFdisplay" which can be used to program the displays. See the list of programs above and the Schiratti download page. You can mix them as you like, but bear in mind that if the same buttons are programmed in more than one place, all the actions so programmed will occur. This isn't the case when programming keypresses in FSUIPC, as these are intercepted and go no further. That cannot be done with buttons. Regards, Pete

The FSUIPC Log you sent was just the default log. At present I can't find anything wrong, so I need a bit more information please. To debug Button actions, please enable the Button logging in the FSUIPC logging page. Do this first, then operate one or two of the buttons you have problems with. Send me the Zipped up log. I'll assume the FSUIPC.INI is the same as the one you already sent. Regarding the odd duplication report, I cannot find any reason that may occur either. If it is reproducible could you send me a "Before" INI and an "After" INI plus a note of what you tried to re-program in the dialogue? So far yours is the only report like this I have received. There have been two complaints the other way -- where I fixed button programming so if one is programmed as Aircraft Specific is will not operate in the general section -- because some folks seem to have taken advantage of that original bug! Thanks, Pete

How is it that the previous logs you showed didn't have any of this? This extract is from WideServer.log. There MUST be a comparable log from the Client which shows the reconnections, and more importantly probably the reason for them. This is only half of the story. Interestingly the connection was problem free for the first 3 minutes (almost): After this the Client re-connected every 18 seconds, which is roughly the timeout when it sees nothing arriving from the Server. This continued for 2.5 minutes approx, after which there was a gap for 3 minutes: Do these odd timings mean anything to you? Were you starting/stopping programs on the client, or doing something in FS which may relate? In the performance summary the only worrying thing is this: What are you running on the Client which is attempting 72 frames per second? The transmission performance simply shows why the Client is reconnecting -- there appears to be few opportunities for the Server to send things to the Client which is extremely busy sending 72 frames per second to the server! Check the configuration of the Network at the client. It needs to be full duplex. Half duplex will cause this sort of blockage. Go through all of the settings. Something is wrong. I cannot tell you anything else because the important half, the Client Log, is not supplied. You really need to think both ends, not one or the other, please. I also cannot reconcile what you are reporting now with what you reported previously. It does not seem compatible. If you are running an application which simply sits in a tight loop making constant demands on WideClient, you could try slowing it down somewhat by setting the ApplicationDelay parameter (in WideClient.INI) to something like 30 or 50. Please see the documentation. Regards, Pete

What do you mean by "standard" COM-cable? There's no one "standard". Most serial cables are intended to link a PC to a serial device like a modem. Such a cable has parallel connections -- one end is a DCE the other a DTE pin arrangement, meaning pins 2 and 3 have opposite functions at each end. Extension serial cables are similar but have a male connector one end and female the other. Again, the links are parallel. To link two PCs together you have to use what is commonly known as a "null modem" cable -- called this because it can link two PCs without a pair of modems between them. Really only 3 wires are needed - common (pin 1 or shield), and pins 2 to 3 and 3 to 2 (crossing over the RX to TX and TX to RX). This is mentioned in the text file provided with GPSout. Regards, Pete

I see. All I can think of, then, is a process of elimination -- disable each component gauge in turn, via the PANEL.CFG file, till you find the one (hopefully only one) which is responsible. Then see if you can live without it. Regards, Pete

There's nothing wrong with either log, and WideClient has nothing to do until you run a program on it, so if the process is hanging it just has to be a bad network driver or card, or some other program is interfering. All WideClient will be doing is idling waiting for a program to be run. It will send an "I'm here" message every couple of seconds to the Server and expect one back. That's it. It's really dead simple basic Networking copied direct out of Microsoft's own examples. Regards, Pete

I've no idea why they'd need FSUIPC for altitudes in the A/P. Mostly the only thing FSUIPC is used for in these panels is TCAS. No more useful that what you already said, that it works fine without FSUIPC. The Gauge using FSUIPC is "PSS-Dash8.GAU" as is clear from the log, but I've no idea what it is used for. I see you also have the SB3 DLLs loading and they all connect to FSUIPC too. Have you tried without those in case there's some sort of interaction? Regards, Pete

Your ISP is caching it. Sorry, but I really have no other idea. I know nothing about websites. See if the PFC site has been updated. Regards, Pete

No. Sorry. Pete

There's nothing to go wrong if you got the trig correct. What does "not working" mean? I assume you've scaled it to fit your graphics. Don't ask me about graphics, i've no idea about that. Pete

The INI file only contains your settings. The FSUIPC.KEY file contains your registration. You only need to re-register if you re-install windows or move to a different PC. Otherwise copying the KEY file is fine. If your copy is correctly user registered then it won't be a delay due to PMDG module access checking -- all that is then by-passed. Regards Pete

Is AFCAD 140 the only one working on FS2002? It seems odd that someone would add spaces in those fields. The easiest way would be to correct the Version Information, removing those spaces. You can do this with "ResHacker", a freeware program. if you can't find it, zip up and send me a copy of the AFCAD 140 exe and I'll try to adapt it here for you. petedowson@btconnect.com. Regards, Pete

For 90-180 you can either use the formae exactly as above (sin goes -ve from 90-180), or, for clarity of thought, subtract the bearing from 180 and then do as above, but reversing the sign of y. Draw yourself a little picture. It will all be clear then 180-270 is similar, just subtract 180 and reverse signs on both x and y. 270-360 subtract from 360, reverse the sign of the x value. Regards, Pete

The fiddle factors are just that -- non-dimensioned multipliers adjusted interactively by me to get the best results. I tried them with most, but not all, of the default FS aircraft, and got good results except for speed control where the oscillations were still present when I released it. I'm sorry, but optimising is really a trial-and-error process. If you do find better values please let me know, but the current ones are certainly good with both the Cessnas and Boeings. I could imagine there'd be problems with aerobatic aircraft with fast roll rates, but it surprises me that a King Air doesn't stabilise quickly. Regards, Pete

But you imply that all was well until you re-installed FS9. So something has changed there. FSUIPC doesn't actually do anything which involved lots of computation of delays. It doesn't deal with any graphics, or files. A regular 2 second stutter sounds suspiciopusly like something else running in the background, unless one of the gauges or other add-in modules has something on a 2 second cycle. FSUIPC operates on a frame rate related cycle. There isn't anything on a longer cycle than half a second (this latter is for computation of some values not needed on every frame). Have you checked the FSUIPC log? Is your FSUIPC user registered? If not, this may be down to an access check failing from one of their modules and being retried every 2 seconds. Unlike PSS to fob folks off so. They certainly haven't contacted me, and they've always done so in the past when they've had any problems. I suspect they are desperately trying to resolve this and just want folks to leave them be till they solve it. Regards Pete

If you have distance and bearing (d, b) then you can convert that to some x, y coordinates for a Radar screen. It's simple trig isn't it? Tell me where you are stuck. To keep things easy I tend to do this sort of trig in the four quadrants separately -- saves confusion with signs and so on. For the first quadrant (bearing 0-90, Forward/Right), the (x,y) plot position would be: x = d * cos(b) y = d * sin(b) after converting b to radians of course ( *PI / 180). The other quadrants are variations of this with different sinces and +/-90 sort of fixes. On the other hand, just to map positions relative to the aircraft you don't need distance and bearing. Just use the Lat/Long values, made relative to the user aircraft by subtracting the latter. However, then you'd need to rotate the relative (x,y) coordinates to get bearing up, so you might be better off using distance and bearing in any case. But TrafficLook merely lists the data, including distance and bearing. it doesn't draw a map. You already have the data that TrafficLook has. Regards, Pete

Other than by a process of elimination (i.e. remove each possible candidate in turn), no, I'm sorry. The FS control system operates by Posting Messages and there's no way of tracing them back. Regards, Pete

WideFS cannot run parts of FS on other PCs, it only runs other programs. The PMDG aircraft are made up of parts of FS -- DLL files, MDL files, CFG files, Textures, Sounds and Gauges -- all of which need FS in which to run. They are not separate programs and cannot run alone. Regards, Pete

Where's the Log? Pete