Pete Dowson

The offset is 6D00, the value is 8 (bit 3 = 2^3 = 2x 2 x 2 = 8). Bits are numbered low to high. Bit 0 = value 1 Bit 1 = value 2 Bit 2 = value 4 etc. This is how the binary system of numbers works -- each successive higher bit is worth twice the previous one, much like each higher decimal place is worth 10 times the previous one. Hence the names "binary" for 2, "decimal" for 10. No, of course not. The whole Dword is handled by the Dword control. That's why it has the word "dword" in it! The byte controls handle bytes, that's why they have the word "byte" in them. There is some logic to the names of the controls, you know!! Yes. Because that is the offset, so it goes into the offset box. Oh dear. The instruction to set any bits (without changing any others) is "Offset Dword Setbits" as I thought you understood. There's no "instruction" to go into the parameter, just the PARAMETER -- the value containing the bits to be set! If you wanted to set ALL bits to 1 it would be xFFFFFFFF. For only Bit 3 it is x00000008 or, if you like, simply 8 which happens to be the same in decimal and hex (because it is less than 10). Pete

Two things wrong at first glance. First, the "UseSendInput=Yes" parameter is not a [Config] parameter (which concerns Network operations) but a [user] parameter -- you have it in the wrong section. Second, WideClient is not looking for any keypresses at all, because you missed the important bit: "Make sure you have ActionKeys=Yes as well". It is the ActionKeys parameter which tells WideClient to tell WideServer that it wants to receive key notifications. Not sure why you want the Roger Wilco actions listed too. Are you using RW as well? Regards Pete

Well, you can program these in the dialogue in FS which saves working them out, but in the example above you are using the Offset Byte Set control, which will only handle the lower 8 bits, not the whole 32 bit Dword. Also, the line is incomplete. The value to be written needs to follow, after a comma. If you used the dialogue the format would be sorted out for you. Yes, you seem to have completely misunderstood. You've suddenly changed from addressing offset 6D00 to offsets 6D07 (7 bytes or 7 x 8 = 56 bits later), and 6D03, which is effectively the top 8 bits of the 32-bit (4 byte) Dword at 6D00. I'm not sure why you are doing that, nor do I understand why you want to write the value "1" to those bytes. What do you think it achieves? Please keep to the offsets you have documented. Remember 1 byte = 8 bits, 1 word = 16 bits, 1 Dword = 32 bits. Addressing is by byte, so each offset addresses a separate byte as base. Regards Pete

Sorry, no. That's just a promotion by SimMarket as it reduces the workload selling both together -- one transaction instead of two. Regards, Pete

Installing a new FSUIPC.DLL doesn't touch the INI file. There's no INI file provided with the package. Just replace the DLL when you update. Well, there are a lot of changes in the INI since then, but none that I know of will cause any problems when updating. If you want to be really sure, then move out the old INI file, let the new FSUIPC make a new one, then cut and paste the Joystick sections from your old one into your new one. Regards, Pete

The "previous flight" thing is created anyway. The default flights are all found in the main FS Flights folders. I don't think it ever invents a set of weather excepting when weather scenarios are selected, then it generates them from a scenario script. Only user-saved flights are in the My Documents folders, so you only hid those. I think there's a GetWeather program (maybe different name) which essentially downloads the usual Jeppesen weather and stores it. But as far as I can see you may as well use FS to download it in that case. Regards, Pete

Correct. Any attempt by anything external, whether it be simply clear weather or set dynamics to zero, will make FS revert to "User Defined". I think all the weather programs initialise this in one way or another. No, FSUIPC never sets any weather, other than adding the occasional high level cirrus to clouds being set by a program, if that option is enabled. FSUIPC has absolutely no idea of what the previous weather was nor what "accurate weather" means. It is just a window through to FS's weather system for other programs to use. It is passive, not active. If that weather is not from the weather program, it is from whatever weather was loaded by FS from your default Flight (or the last flight you loaded). If you want to get rid of pre-recorded weather, delete the .WX files associated with your flights, or do a "clear all weather" and save new flights. Because the weather programs are asking FSUIPC to do something to the weather. This makes it "user defined". If you want to see more about what is going on with Weather through FSUIPC, enable the weather logging and check the Log.

Yes, thanks. There's enough information there. I'm not too well at present, but I'll get right onto it as soon as I can see and think more clearly! Regards, Pete

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