Pete Dowson

Of course you haven't. You have no need of programming GoFlight buttons in FSUIPC either. If you only need the functions GoFlight provides by default, what's the problem? The provisions in FSUIPC and GFDisplay are only for those who want to do something different. If you don't, then I'm not sure of the point of the original question. Regards, Pete

How are you programming? If you want to program a button or keypress, just use the Offset controls in the FSUIPC drop-down lists in either the Buttons dialogue or Keys dialogue. Your spec says 6D00 is a "long" which really means a 32-bit DWORD. You can set a complete value there with Offset dword set, or change bits with Offset dword setbits, Offset dword clrbits or Offset dword togglebits. As for bits > 8, a DWORD has 32 bits, so the numbering goes from 0 (for the 1 bit) right up to 31 (for the top bit, or 2^31, or x80000000 in hex). If you are writing a program then you just use FSUIPC_Write of length 4 and the values you want to set. The Offset controls provided in FSUIPC are documented -- a brief mention in the User Guide, and the parameter formats in the Advanced guide. They are very simple. Regards, Pete

Interesting that those values are obeyed in slew mode at all. That's quite a surprise. As for ailerons, I really don't understand why you can move the left one but not the right -- can you move it both up and down with different signed values? Pete

No. That is the question. Please let me know. No. No, the procedure I call in FS doesn't tell me. Regards, Pete

That's weird then. There's no 17+2 second cycle in AutoSave. It simply wakes up at the interval specified in the CFG file and calls a procedure in FS which saves the flight. It's been virtually unchanged since FS2000 days and I've not heard of any stutter problems with it before. Sorry, I don't understand what is happening there. Pete

That's weird, because exactly the same list is used for both! It's the same list in all the cases where you can re-program buttons in PFC.DLL. I can't get such a thing to happen here no matter what I do, on any of three different PCs. This is also not an area which has been subject to any change whatsoever, since the facilities were first programmed. Very odd. If I can think of any way to find out what's going on there I'll get back to you. Meanwhile, can you check the same drop-downs for all the other buttons, and on the other pages in the dialogue please? Maybe if there's some pattern to it something will become clearer. Regards, Pete

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