Pete Dowson

I'm talking with Doyle Nickless about it. Don't worry further. I also found a slightly older version which doesn't need that DLL, and both are now provided in my Announcements above. I assume you mean the pressure setting, also known as the "Kollsman window" after the first such altimeters made -- Kollsman is/was a German company. Microsoft seem to mis-spell this as Kohlsman, and the controls for it bear this name. Whener you are in doubt over any control, use the keypress or mouse click for it after setting Event logging in the FSUIPC logging page. Then you will see from the Log what name that control has. Regards Pete

You only need WideFS if you have a Network of PCs (i.e. at least two PCs including your FS PC) and wish to run some program which uses FSUIPC on the other PC. It simply extends the FSUIPC interface across the Network. It is used extensively in home-built cockpits where there may be up to 10 PCs involved in supporting the one aircraft. If you are not using it then disable it (in the About & Register options page, bottom right). Hmmm. It sounds like you have one of the very serious SimConnect problems which we think must be associated with some anti-virus, firewall or other security program you have installed. It is mentioned in the "FSUIPC4 Read Me" (which of course you didn't, did you?) as Problem Type 2, and whilst there's a workaround (change "NoAxisIntercepts=No" to Yes in the FSUIPC4.INI file, before loading FSUIPC), this loses you the facilities for joystick calibration in FSUIPC4. But first, could you show me the FSUIPC4.LOG file please (it is in the FSX Modules folder). If it is too big, ZIP it and send it to me at petedowson@btconnect.com. You may be able to fix the problem by re-installing SimConnect (see the FSX Help announcement at the top of this Forum), but it is more likely that the only fix is to uninstall completely any added security software you have, test it to see if it then works, then gradually add stuff back being very careful what you enable, and testing each time. All this has been reported to Microsoft many weeks ago, and I hope they will fix it. It is but one of many problems with FSX and SimConnect. So it's okay when it is running? Sounds like something to do with the way the video driver is initialised. There's nothing any add-on will be doing to induce that. Certainly nothing of mine has anything whatsoever to do with visuals. There's nothing I know of in the Registry which will directly affect anything in FSX or my programs, though of course an inefficient Registry can slow the whole ststem. I use the registry compaction in Registry Mechanic. Hmm. My slowest PC is 3.2Gb. It is just about flyable with FSX if you turn a load of stuff off -- especially Autogen. That seems to cripple performance on anything less than the top of the range processors, and even then it can't go very high. It's best also to avoid larger airports as they can be pretty slow too. Two other things can really slow things down, especially on loading: a fragmented disk, and insufficient memory. FSX works best with 2Gb main memory, and certainly nothing less than 1Gb. After you install FSX you need to de-fragment the hard disk. Do it several times in fact, as the installer really does seem to screw it up well and good. You said, earlier, that Why, then, did you get FSX and not FS2004, which will perform adequately on your 3.2Gb PC with realistic add-ons, and has got all the reliability and add-ons which you need? Quite honestly, FSX needs a far better PC at present and the problems which are known and discussed here, in this Forum and others, are quite extensive and difficult to resolve as yet. We are all hoping for a fix from Microsoft, but when that will be I've no idea. Also, can you tell me why you bought FSUIPC4? Why did you install it? I know now you bought WideFS7 by mistake, but what was the motivation in the first place? Anyway, if you do want to persist and get things working, try the things I mention above. After that, if you still make no progress, we will need to get a SimConnect LOG (also described in the FSX help announcement above) and forward everything to Microsoft to help with their analysis of these problems. Regards Pete

Yes, maybe. But this really does show a big big weakness in the way SimConnect works. Here we are talking about errors occurring between DLLs running inside the FSX process and FSX, via SimConnect, and sometimes between an EXE in the same PC as FSX and FSX, again via SimConnect. I really would be most surprised (and rather shocked, from a performance point of view) if network drivers are really involved in comnunications between FSX and EXE's running in the same PCs, let alone with DLLs like FSUIPC4 and FSXCopilot running in its own process. Surely all that, even though it is via the TCP protocol, should be well within the Windows & Microsoft sphere of control. Nothing is faulting here other than SimConnect as far as we can detect or determine. It seems that the errors occur just because SimConnect or TCP gets "too busy". And the result of, for example, FSUIPC4 being denied further access to FSX is a gross loss of anything the user has set it up to do -- very often all his joystick, joke and button operations to start with, apart from all the instrumentation in a Project Magenta cockpit. Talking of which we have 6-10 PC Networks running with the FS PC as the server and instrumentation and controls spread all over the Network, and never have I seen any unspecified "I/O Error" occur with no idea what it is or how to recover. The fact that they occur within one process and not over real networks is rather odd, don't you think? Oh, Happy New Year by the way! ;-) Best Regards Pete

Erthis is not actually the same as in the Logs you showed me privately. When you say "I have no firewall", what do you mean? If you have XP installed (which you have, according to your private message), you have a firewall. You need to explicitly turn it off or tell it to allow the programs to talk. The log simply shows that nothing the Client is sending can be received by the Server. It is being blocked by something. Maybe, if not the XP firewall, something in your Router? Maybe you could try eliminating that as a test? From the logs, I admit this is unusual for a firewall problem -- usually I think even the connection is not accepted. However, here the connnection is accepted but then nothing, no data whatsoever, is being accepted by the Server from the Client. Everything, absolutely everything, I know about Networks, and more, in fact (thanks to contributions from others), is embodied in the WideFS documentation. If you are absolutely position that there is no firewall blockage occurring, then please go through every possibility listed in the documentation. There is nothing complicated or unusual about the WideFS network actions. The code it uses is all pretty much straight out of Microsoft example programs. I would not dare change it much as it is an area I know little about. The same basic Network code has now been working fine in WideFS for over 10 years. The complicated parts, the parts which are my design, are involved in the formulation and checking of the data which is carried, not in the networking. Please let me know how you get on. Whenever I have a Network problem it is always a matter of trial and error, seeing what can be changed and how it affects things. Regards Pete

Yes, I know of Piyali. He does testing for the team in this area. The loss of one or other SimConnect client after an logged "I/O Error" in SimConnect appears to be quite common with multiple clients on some folks' systems, but impossible to reproduce on others. I have FSX now installed on 5 PCs -- an Intel 3.0 GHz, Athlon 4000+, FX-57, FX-62, and Inte x6800, and I've not been able to make it happen once no matter how much I load them up, even on the slowest, whilst on some other folks systems it fails as easy as anything. I hope that there are enough inputs through Tell_FS to encourange Piyali or others in the team to try harder. I find it rather disappointing that it has taken several months from the first such reports before they even ask for more help in these matters. I had been hoping for some update fixing many of these things this month, but it doesn't look likely if this is an indication of how far they've come so far. :-( Regards Pete

Okay. After reviewing all the files you sent by email, the problem of the apparently bad keys comes down to the PC's System Date. You set it back one year to get around a problem in another package (which had presumably expired?). This made both the FSUIPC and WideFS keys look invalid because they were made after the actual "current" date as read from the PC. Correcting the PC's date rectifies this problem and the Keys will then work fine. Good flying! Regards Pete

Hi Bob, Thanks for the second log. Now this is COMPLETELY different from the first, and shows a serious SimConnect problem. I suspect that it is this which is preventing anything working properly at all. If you look at the FSUIPC4 log yourself you will see what I mean. It is mostly populated by this sequence, repeated: Do you have any buttons to press other than the PFC ones? Have you tried any of those? Because I suspect that no buttons, joysticks, anything, will be seen in FSUIPC4 Options if SimConnect is not cooperating. The PFC buttons scan, although internal between PFCFSX and FSUIPC4, is part of the main button scan which will not occur if Simconnect is not responding to general requests. I don't understand what has changed between your last log, which showed no signs whatsoever of any Simconnect problem, and this one which shows such serious problems. Have you changed anything else, installed anything else? I think next we need a SimConnect log -- instructions on producing one of those are given in the "FSX Help" announcement above. Pleasealso try again (tyhe same test) with the attached interim update of FSUIPC4, version 4.066, which has longer timeouts on initial connections in case some of the errors are simply because your system is so heavily loaded (SimConnect-wise) that it is unable to supply requested data withing the first second or two after connection. (What sort of frame rates are you getting in FSX?). Regards Pete FSUIPC4066.zip

I've been trying to replicate the problem here, with no success at all I'm afraid. Since the code for that part is pretty much identrical to the way it was in FS2004 this is not surprising (the complete re-write for FSUIPC4 and WideFS7 only applies to the main functions of FSUIPC, the interface to FS itself). The logs I asked for don't particularly help, as they do show what they should show for use of the buttons EXCEPT in the Options. Looking at what I asked you to do I realise it was my fault. I forgot to ask you to actually do the thing which you report as not working -- i.e. enter the Buttons options and try to see them pressed there. If I do that here, with that logging, I get Log entries like this (for the exact sequence you used for your test, as below): 182110 *** Entered Buttons option page *** 190188 ButtonCheck dwNow[16]=00210000, dwLast[16]=00200000 (pFirst YES) 190188 ButtonCheck res=1, *pFirst=4112 (0.16, 16) 190188 FirstButtonChange res=00001010 (0.16, 16) 191235 ButtonCheck dwNow[16]=00200000, dwLast[16]=00210000 (pFirst YES) 200985 ButtonCheck dwNow[16]=00220000, dwLast[16]=00200000 (pFirst YES) 200985 ButtonCheck res=1, *pFirst=4113 (0.16, 17) 200985 FirstButtonChange res=00001011 (0.16, 17) 201938 ButtonCheck dwNow[16]=00200000, dwLast[16]=00220000 (pFirst YES) 212360 ButtonCheck dwNow[20]=00000400, dwLast[20]=00000000 (pFirst YES) 212360 ButtonCheck res=1, *pFirst=5130 (0.20, 10) 212360 FirstButtonChange res=0000140A (0.20, 10) 213500 ButtonCheck dwNow[20]=00000000, dwLast[20]=00000400 (pFirst YES) 219907 ButtonCheck dwNow[20]=00001000, dwLast[20]=00000000 (pFirst YES) 219907 ButtonCheck res=1, *pFirst=5132 (0.20, 12) 219907 FirstButtonChange res=0000140C (0.20, 12) 220594 ButtonCheck dwNow[20]=00000000, dwLast[20]=00001000 (pFirst YES) 227485 ButtonCheck dwNow[28]=00000001, dwLast[28]=00000000 (pFirst YES) 227485 ButtonCheck res=1, *pFirst=7168 (0.28, 0) 227485 FirstButtonChange res=00001C00 (0.28, 0) 228516 ButtonCheck dwNow[28]=00000000, dwLast[28]=00000001 (pFirst YES) 234860 ButtonCheck dwNow[20]=00000020, dwLast[20]=00000000 (pFirst YES) 234860 ButtonCheck res=1, *pFirst=5125 (0.20, 5) 234860 FirstButtonChange res=00001405 (0.20, 5) 235485 ButtonCheck dwNow[20]=00000000, dwLast[20]=00000020 (pFirst YES) 244610 *** Exiting Buttons option page *** To quote from your email: This is actually the part I need to see on your system. At present I have no idea whatsoever how the button bits can be changing well (as shown in your log) yet be ignored in the Buttons option dialogue. It makes no sense at present. The Buttons dialogue merely looks through those exact same values for the first change. Sorry not to be of immediate help. Regards Pete

Hmm. Interesting but rather odd thing to want to do, but it isn't easy even with FSUIPC. Yes, bits in 310A, when set, will operate the disconnections, but these facilities were intended for program use rather than direct user control, and as it says there the bits are reset (axes reconnected) after about 10 seconds unless the bits are re-written. The parameter for both aileron and elevator would be 3 (Bit 0, worth 1, controls the elevator, whilst bit 1, worth 2, controls the aileron connection). "ToggleBits" reverses the current setting, so it isn't what you want. To disconnect them you need "SetBits" and to reconnect you need "ClrBits". The problem then, though, is repeating the SetBits every few seconds, so that the safeguard doesn't reconnect the axes. For a keypress you can only really do this by pressing the key combination regularly or holding it down so it repeats. The button facilities would be a better bet, if the button can be held on (as for a toggle switch) -- you'd use the "control to repeat while held". Assuming you have no holdable button then the only way I can think of doing it is to make the KeyPress set a "virtual button bit", and another press to clear it. Then the virtual button could be programmed as above. FSUIPC supports 288 "virtual" buttons, each represented by a single bit in one of the offsets fron x3340. To set virtual button #64,0 you'd program your Keypress for an Offset Byte SetBits with offset x3340 and parameter 1. To clear it you'd use Clrbits with the same offset and parameter. Now, it would be 'nice' if you could then simply go to the Buttons tab, press your keypress, and program it there just as discussed above. Unfortunately, though, at least for this (rather unusual) application, FSUIPC isn't processing your programmed keypresses whilst it is in the Options screens. If you think about it, if it did then problems could easily arise which scupper further attempts to use the options. So, I'm afraid you'd need to program the virtual button by editing your FSUIPC.INI file. You'd need to add two lines to the [buttons] section (create that if you don't have one): 1=R64,0,C0500310A,3 2=U64,0,C0900310A,3 Change the numbers on the left if these are used alreay -- allocate the next two in sequence. Details for programming buttons and keys in the INI file are found in the Advanced Users document. Regards Pete

ErI assume you have FSUIPC4 working, as you say you registered it okay. If not, what is the problem? Can you describe some symptoms at all please? As far as Registering WideFS7, the process is identical to registering FSUIPC4, except using a different KEY and pressing the WideFS button instead of the FSUIPC one. Can you tell me a bit more about what you are doing and what happens? I'm afraid I really cannot guess these things. You need to tell me what the problems are before I can help. Why worry about logs first, they may be completely irrelevant? Regards Pete

Got them. Thanks. I'll see to this today. Regards Pete

As long as it is lodged with them. I've written direct to Mr. Nickless as well. Meanwhile I will see if I can find the older version of GFDev.DLL and put this into the Announcements above as well, as an alternative solution. Regards Pete

Ah. This is a problem with GoFlight's latest GFDev.DLL package then. That's a blow. Certainly it should be okay if you put a copy of that MSVCR71.DLL into either the WideClient folder or the Windows\System32 folder, but that will only solve it for you. GoFlight need to be made aware that they are using a library that isn't on everyone's system. Can you report it to their Support too please? I'll tell them as well. I may put the older version of GFDev.DLL up in the downloads area above as well for now -- I only just put the latest up today! Regards Pete

FSUIPC4 recognising PFC buttons is nothing to do with SimConnect, it is a direct call from the PFCFSX.DLL into the FSUIPC4.DLL, which loaded it in the first place. Could you please do some logging? add Debug=Please LogExtras=2 LogButtonsKeys=Yes to the [General] section of FSUIPC4.INI, run FSX, go into the PFC Test page and check the logging for "only changes to decoded data". Then operate some PFC buttons (note down which), close FSX, ZIP up the FSUIPC4.LOG and the PFCFSX.LOG and send them to me at petedowson@btconnect.com. Thanks, Pete

This is as before, not newcorrect? What was this test for? FSUIPC won't be supporting any requests whilst you are in its menus, so connections will be lost. What are you trying to test here? Unfortunately the Log file is not complete -- I really need to see the end too, after FS closes. However, I assume it is as before. I really don't know what is happening on your PCsomething is messing up the Key checking. I have not seen anything like it before at all, in the yearsI've been using Keys. I'm wondering if the registry entries are corrupt, but you say the version you used before 3.71 was okay? Do you still not remember which it was? Could things have been corrupted since then? I'm afraid I'm out this evening, but I will be thinking of what to do next. Possibly first trying to re-register you with a slighly different name or address first, so that it rebuilds the parts of the registry they uses. To that end could you do this: 1) ZIP up the proper FSUIPC.KEY file, as you started with (I know you included it before, but I've lost it. Sorry). 2) Decide on a different way of setting your name, or a different email address if you have one, or both. Send these details to me at petedowson@btconnect.com please, not via the PM facility here. Regards Pete

Send all the details to me at petedowson@btconnect.com (ZIP up your FSUIPC.KEY file from the FS Modules folder please), and I'll issue a new FSUIPC key to match your WideFS one. Unfortunately I'm off out now, but i'll see to it on my return later tonight. Regards Pete

This is the release version I assume? This is worrying. I will need to find out why I am not detecting the insufficient privilege levels in my code. I can add the notes to the documentation to advise folks to use "Run As" for Registration, but I would still want to warn them if they haven't done so. Hmmm. Regards Pete

Can you tell me what Windows version you are using please? Pete

I have only heard of this happening on some Beta versions of Windows Vista. What version of Windows are you using? The registration process needs you to have Administrator privileges. I have code in the program to detect if you have or not, and this works in Windows XP and earlier, and, as far as I know, in the Gold copy of Vista. If FSUIPC detects that you don't have the correct rights, it won't let you register and you get an appropriate message. It sounds like it isn't able to detect this on your system for some reason. Please try logging in as Administrator, or just use "Run As" when running FSX in order to register. Regards Pete

Glad you got it sorted. Worrying though that we don't know what the problem was. Thanks for letting me know. Pete

That seems okay. I just remembered about one other user who had a problem with an old Game Port type joystick driver, which was causing FSUIPC to hang. but in his case it was only when he went into the FSUIPC "buttons" or "joystick calibrations" options. Just in case it is related to button scanning, could you edit the FSUIPC.INI file, and add this line into the [buttons] section (add the [buttons] line as well if you have none): PollInterval=0 Then try running FS again. I'll keep thinking. Meanwhile, I ask again, is there an FSUIPC Log file produced at all? If so is there anything in it? Regards Pete

Okay. The log files confirm that it is definitely the Key which FSUIPC does not like. But I cannot understand why, when the KEY data you sent to me before works fine here, and the Key is okay according to all other checks. This is a real puzzle. I may have to add more code to log details of what is going on differently in your system to all the others which work fine. But first, we can try two experiments. First could you again remove the KEY file and register, this time, only WideFS. Do exactly the same tests (don't use WideFS, just run SB3 locally -- if FSUIPC doesn't like the WideFS key either, the problem will remain. Then I can try sending you a different FSUIPC Key to try. Even if that worked, which seems a little unlikely as the first works okay here, I'd need to try to get to the bottom of this mystery. Regards Pete

Eryou mean you uninstalled and re-installed FS completely? did you delete the file areas FS uninstall does not, like add-ons, flights, and so on? Did you load FS with them set as default, though? If the corrupt WX file is loaded by FS, and not used, it can still wreck thiings. Best test is to delete or rename the FS9.CFG file. did you try that? Don't send me any DLLs. If you completely uninstalled FS and re-installed it, the ONLY DLLs there will be those of FS itself, and of course FSUIPC. Strange, yes, but it doesn't explain anything at all I'm afraid. I think I need more information. Version of Windows? Other things added? Pete

This really does nearly mean the registration is in error, which I don't understand because it is fine here. SOMETHING is mucking up the checking procedures somehow. I have never met such a problem before. I am really not sure how to proceed at present. Okay. I'll look at them next. But I am very worriednothing at all like this has happened before. It is acting as if the key is not valid, but it works fine here. I cannot imagine what is so different there. The same key-checking has been going on now for 3.5 years with no similar problems. It is very strange. I may have to start adding extra logging to see what is going on. It could take some time. Meanwhile, can you please tell me more about your system -- what Windows version, especially. Oh, one other thing. You said, earlier: Can you recall what version it was you had in September? Would it have been 3.70? It would still be a puzzle as the only difference between 3.70 and 3.71 in terms of registrations is that there is no need for Application Registration in 3.71 -- the checks are removed. User registration ihas not changed since 3.01. Regards Pete

FSUIPC has always counted from 0. The button numbers are actually bit numbers in a 32-bit DWORD supplied by the Windows API for joysticks. Bit 0 is the least signifcant bit and gives me button number 0, and so on up to a maximum of 31 for the top bit. The button number is actually used to produce a mask to test for the bit to change, so it must accord to the bit being seen from Windows. No, it isn't your system, and it won't cause any problems whatsoever as it is just an identity used to relate a button indication to some action in FSUIPC. I could have called them after characters in Alice in Wonderland (button TweedleDee and TweedleDum, for example ), but it would have taken more space. I thought numbers would be okay! :-( It is probably repeating -- "G" is a Gear toggle. Why convert buttons to keypresses which are then assigned in FS to FS controls? You never need to use any key presses for such things -- look down the list of FS controls and assign it directly! Please do peruse the documentation provided. It is all explained in there. Why on Earth would you want to? It is totally irrelevant. Just program whatever buttons you want, then go fly. Why worry about the numbers? No of course not!!! Use one or the other, not both! If you are assigning them in both places you wil get double actions!! No wonder your Gear button doesn't work! :-( I really don't know why you are using FSUIPC for button assignments, but a light perusal of the relevant sections of the documentation might help if you intend to. For the sorts of things you are talking about, what is wrong with FS assignments anyway? Regards Pete