Pete Dowson

One other thing to try, please. Assuming you've not tested this yet with the official user release at present (4.40), do you think you could try that and let me know? I need to know if this problem might be due to recent changes (4.401-4.409) or whether they existed before. In order to get the 4.40 installer to install 4.40 you'll need to remove the FSUIPC4.DLL from the FSX modules folder, as it refuses to replace a later version. After that, could you also try 4.411 (now in the FSX Downloads Announcement above), as there are some other changes in that. Thanks. If I cannot resolve this tomorrow (Thursday) it is going to have to await my return on the 29th. Regards Pete

I assumed it was related to the CoPilot DLL problem, which was known, as the originator didn't come back after that was mentioned. I'm going to have to think about how to narrow this down more when I return on the 29th. Sorry. Regards Pete

I thought you said you were using a P8, push buttons, not a T8 with toggle switches? You have the same key combination sent when the button is pressed AND when it released. Why is that? It is most unusual to do that with a button and keypresses. It would make sense with a toggle switch. The sequence sent when it was pressed is this: Everything there is fine, except that the KEYDOWN for key 49, though it was sent, was not received by FSUIPC. I assume it's been detected earlier in the chain by the add-on you intended it for. On the release: which is fine, as far as it goesbut there appears to be a delay then before the button releases are sent. In fact, just after the next button is pressed: The emboldened entries are those for the key releases from the previous press. Then we get the releases from the second pressed button: which are fine, then the release action on the same button: and that looks perfect. So, in this example at least, there appear to be no "stuck keys" except in the few seconds between releasing the first button and pressing the second, when it rectified itself. I'm really not sure how that delay arises. Would the key releases have occurred if you had not pressed another GoFlight button? I'm afraid your log, whilst showing that there might be a problem, doesn't seem to show THE problem. It is really a shame you pressed the second button. Now I have a better idea of what you are doing I will try to reproduce this here. Meanwhile, could you try actually reproducing the stuck keys case with them actually stuck, not apparently cleared by another button press. And could you clarify whether you are using buttons (as on a P8) or toggles (as on a T8)? Regards Pete

Well FSUIPC's log did confirm that it added its entry. It can do no more than that. The rest is up to SimConnect. Perhaps you've discovered a new SimConnect bug? A SimConnect log may prove useful -- see the FSX Help announcement above for instructions on how to produce one of those. I'm also wondering whether something Squawkbox is doing is getting the menu entry removed, somehow. It is installing / running before FSUIPC. Maybe it's causing SimConnect to reach some menu limit, or other. Could you try temporarily disabling the Squawkbox items in the DLL.XML file -- change their False entries to True. If that works, then try getting FSUIPC loaded first -- cut the FSUIPC block from the end of the DLL.XML file and place it at the beginning. The FSUIPC block is this: FSUIPC 4 False Modules\FSUIPC4.dll Just move that section to just before the first line in the file. Best make a safe copy of the DLL.XML file first. Neither FSUIPC nor the Installer ever delete any files. So did you? Haven't you run version 4.411 yet? If you have then there will be a LOG file, and the timestamp on the INI file will have been updated. If FSUIPC is now not being run then it will not be able to create or update either. Regards Pete

Okay. A few points there: That version is no longer supported. The current version is 4.40. There is an interim update in the Announcements here, too - 4.411, but you need to install 4.40 first. If you already purchased it, why didn't you registered when prompted to during installation? You will have to re-run the installer in any case when you get around to registering. There is nothing wrong here. It has connected to Simconnect and it has added "FSUIPC" to the AddOns menu. Where are you looking? The AddOns menu entry occurs in the Menu bar, obtained when you press and hold the ALT key. It is in the menu, not in any dialogues or anything. SimConnect is part of FSX and it is the part responsible for creating that entry, and the log certainly confirms it has done so. Regards Pete

It's actually "Dowson", not "Dawson", but you can call me Pete. I never understand why folks don't download and install first, THEN purchase? ;-) FSUIPC should install and produce a menu whether or not it is registered -- for many purposes registration isn't necessary. I see you have Squawkbox 4 installed. Doesn't that need any Add-Ons menu entries? You included the FSX.CFG and FSUIPC4.INI files, which aren't relevant. I don't need those. The FSUIPC4 install log is good, and the fact that the FSUIPC4.INI file is produced means that SimConnect is actually running it. So, the answer is most likely to be within the FSUIPC4.LOG file, which is the only thing needed which you omitted. Regards Pete

Why did you send me all those pictures? They show nothing more than what you already told me! Pete

So, if you installed a Microsoft debugger, do you think you could break in at the point of the hang and see where it was and how it got there? Is there a cursor flashing, one of the slim text insertion flashing cursors? Sounds like all it should be doing it trying to place that ready for your input (i.e. via a SetFocus call). I think the Vista 64-bit nVidia 180.xx, so far at least, series has serious problems. On both my Vista 64 systems (different motherboards, memory, disks, video cards) I've been getting hangs, blue screens of death, all sorts of problems -- not frequent, usually half-way through flights, and then not every flight. I had to go back to 177.xx or 178.xx versions -- no problems since. Could that be something you could try? If you have a GTX 260 or GTX 280 card it may not be an option. I don't recall which driver version they added support for those. I'm currently using 9800 GTX+ cards, with my GTX 280 awaiting good drivers. The reviews of these cards with FSX specifically seem to show that the 9800 GTX or even the 8800 GTX are best performing in any case, at present. Maybe Vista detects that FS9 is not Vista aware in any case, so still lies to it about what version it is. Would pictures help at all? If so you can send them in an email to petedowson@btconnect.com. Of course. A very last resort, every time! Regards Pete

Okay. It didn't quite work out the way I planned, and in fact i am now not using the SimConnect SimVar at all for the spoiler setting as there is no SimVar for the Arm setting so, when using the two different methods, there's no way of ensuring which gets done first. Therefore I reverted to using the same sort of methods as I use in FSUIPC3, and these seem to work okay. Try version 4.411, already available in the FSX downloads Announcement above. Regards Pete

All macros are named : in the drop downs. This is as documented for macros in general. Obviously I can't allow just the macro names in the list with no qualifications, as many files might use the same names, especially for the same functions in different aircraft. Mouse macros are simply one type of macro which can be generated in FSUIPC. The facility for macros in general has been in FSUIPC for a lot longer. Regards Pete

Sorry, I don't know what else to suggest. With a complete debugging setup on your PC I could trace through it line by line and see which call to which Windows library is hanging. That might give us a clue. But unless you are a programmer yourself I would have to be there in person, and install the Microsoft development system on that PC. If we could narrow down exactly when it was getting into the problem, maybe I could provide you with a version with almost line-by-line logging to a real-time display program, and maybe that would tell us. But more than likely the timing changes that would induce would not create the right results in any case. Have you tried different video drivers, as I think I suggested originally? You could try 3.856, from the Other Downloads announcement above. I doubt if it will be any different, but you never know. Looks like you are getting Vista to tell FS that it is running on XP. That should be totally unnecessary. However, it is a good idea NOT to install FS9 into the Program Files folder, its default destination, as Vista protects all folders in that area and does weird things with aliassed folders -- all this makes it very difficult, if not impossible, for many add-ons which are not Vista-aware to cope. If you can't fix it before December 29th, when I get back from my Christmas break (I'm going away from tomorrow night till then), please tell me in as exact detail as you can what actually happens -- i.e. exactly when it appears to hang, by the keystroke/display change. I will then try to work out a way of diagnosing where it is, exactly, so we can get more of a clue. I should tell you that on the very few previous times this has occurred (maybe 3 or 4 in the last 5 years), only once has it not been due to some additional program like Window Blinds, or a mouse driver problem, or a video driver, and in that case we never did discover what it was. The user concerned reformatted his hard drive and reinstalled Windows and never got the problem again. Regards Pete

Surely you would have downloaded and installed it before purchasing? At least so you could read the User Guide and made sure you really wanted to pay? I don't have a "home page", so i assume you mean the one put together by Enrico Schiratti? That's where most of the references point. Well that is surely a mistake on "SonicWall"s part, then, because there is no chance of any infection, and the program content is codesigned to prevent tampering in any case. I've never heard of "SonicWall". Are they a reputable company? Anyway, you really need to tell them so they can clean up their program. It is an erroneous diagnosis. You'll have to get that "SonicWall" program fixed, or tell it to override its warning, or really disable it. You evidently did NOT disable it or it couldn't have produced the error! Disabling a program does actually mean to stop it doing what it is doing! Regards Pete

FSUIPC just sees the each dial on the RP48 as a set of 4 buttons -- fast left, slow left, slow right, fast right. Maybe if your hardware is reversed they'll come out the other way, but that isn't too relevant -- you just assign whatever functions you like to each. Best really if you download the FSUIPC ZIP file and browse through the User Guide, make sure you want to go that way before actually buying it. Regards Pete

How strange. Is that a faulty RP48, or a faulty GoFlight driver? Have you checked with their support? FSUIPC allows you to program the RP48 knobs and buttons as you wish, but it doesn't work without you doing some work yourself, assigning the appropriate controls. FSUIPC itself also does not operate the LEDs on the unit. There is a free "GFdisplay" program I provide but again it takes some work to get the LEDs doing whatever you want. So, the answer is "yes", but not "out of the box". You have to work at it. Regards Pete

That's rather sad, then, to find the pipe mechanism cannot cope with such rates of update. :-( Pete

Do you remember the macro filename? Are you looking for that? The controls are named WITHIN the file, so the filename comes first. I'm sure it is all explained. This is not specific to "mouse macros", all macro files are treated the same. I even supplied example Macro files -- check those! Pete

"XPNDR SET" takes a BCD value as its parameter (e.g. 0x1234 for 1234). You could easily have tried it to see what it did. No harm would have befallen you! I gave up trying to document FS's controls years ago. The last/best effort I ever did was in FS2000 days, and pretty much all of that still applies, except of course that it doesn't include new controls added since. You'll find the FS2000 controls document still available on http://www.schiratti.com/dowson. For controls actually used in FS or added panels you can use FSUIPC's "Event" logging -- when you operate the control, by keyboard or mouse, the log will show if that was done by a control and if so which it was and what parameter it used, if any. Regards Pete

It means what it says, that the macros you created are loaded and ready for assignment in the Buttons & Switches tab, and also in the Keys tab. You go to the Buttons tab and assign the button!! Your macro will be in the list. They are in alphabetic order. If you remember the name you gave to the file and the name of the macro you should be able to find it easily! The same as any other control assignment! What do you actually think might otherwise be meant by assigning a button or key? Have you never assigned any buttons or keys to any FS or FSUIPC controls before? If all this is new to you perhaps you should refer to those other chapters in the User Guide first? Regards Pete

It seems to be a problem in Simconnect, as the same data written via an axis control works fine. I could make the write to 0BD0 work as an axis control, but I think I'd rather just check for the value (4800-5620 as you say) and convert it to anSpoiler Arming request instead. I'm about to test this out now. If it is okay I will post an update. That will probably be sometime tomorrow (4.411 I expect). Regards Pete

I cannot reproduce any such problem with 4.409. Could you enable Button and Key logging (in the FSUIPC4 logging tab) please, then use one of the programmed buttons. Show me the resulting FSUIPC4.LOG file (it will be in the FSX Modules folder). This is quite urgent -- I will be away from Thursday night until December 29th. Regards Pete

If you wish, but I am changing FSUIPC4 to do this in any case. Later ... Pete

Is that a single engined aircraft? If so, use the normal single throttle. If not, with the latest interim FSUIPC updates you can elect to have no reverse zone by checking the option for this top left. In previous releases it can be done too, by setting the idle zone with one value close to or the same as the minimum (the reverse setting), so that there's no reverse. Pete

Strangely, this bug was reported in FSUIPC 3.853, and was fixed in 3.856. I don't believe it occurs in version 4.409. the current interim FSUIPC release. Have you tried it? Regards Pete

Hmmm. FS tends to use 100% normally in any case (it soaks up all the idle time), but that is suspicious when in a dialogue, for sure. Hmm. nasty. There's could be some problem with the video driver, though. Some driver versions install their own copy of COMCTL32.DLL -- the Windows library used to provide the dialogue tabbing mechanism. However, if you are getting the FSUIPC options showing okay, and only get a problem when it is expecting keyboard input (I assume that is when it occurs -- is it?), then the only place it could be is in the mouse or keyboard driver. All of FSUIPC's use of Windows libraries, for its dialogues, are perfectly standard, and quite innocuous. There's no interaction in the registration window with any other part of FS or Windows excepting the normal dialogue facilities and the registry, so it amazes me that it causes problems on some systems. I don't understand it. I assume you did run FS "as administrator", by the way? I don't think it would make any difference to this problem, but the registration won't take effect if you didn't, in any case. Regards Pete

Hmmm, that's odd, it should accept 4800. FSUIPC is only sending these values direct to FS. I've just done some more tests, and you are right. It all operates perfectly, arming / disarming, until you set a higher value. After that, it won't arm with any value. That's truly weird. A bug in FSX, surely! I'll look to see if I can automatically set 0BCC when you write 4800 (or any value 4400 - 5200 I think). Regards Pete