Pete Dowson

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

A "cpu loop"? Where? How do you know? Some folks have reported a problem with the standard windows dialogues used by FSUIPC with some video drivers, but these only seem to affect full screen mode. Can you see if you can register okay in FS Windowed mode, please? The only other problem I've heard of like that was with some Kensington mouse driver. Maybe there are some other drivers which don't get on well with the standard Windows dialogues used in FSUIPC. No, that should not be necessary at all. It won't make any difference to FSUIPC. Regards Pete

Okay. But before that, before you attempt to reinstall, please do obtain a SimConnect log as described in than FSX Help file. This is without FSUIPC. If you have no Simconnect clients installed then that will produce a pretty empty log, if it produces one at all. At least it will eliminate my worry about this older bug I've been describingor not. Regards Pete

Yes. There are two separate product lines - FSUIPC3 and WideFS6 for FS9 and before, and FSUIPC4 and WideFS7 for FSX. They use different sets of keys -- they are purchasable at separate kiosks in SimMarket. This is because FSX necessitated what amounts to a new product, a complete re-write -- a lot of work which is still ongoing (as indeed it still is, spasmodically, for FSUIPC3). Regards Pete

Okay. I have tested and compared the actions on FS9 and FSX. They are different, a little, and in fact FSX is better, more consistent. With FS9 writing 4800 to 0BD0 does Arm the spoiler (0BCC goes to 1), but unusually, when on the ground, FS9 is not then immediately raising them. This is actually inconsistent, because if you armed them using an axis (via the Spoiler Axis inputs calibrated appropriately), they do automatically raise if armed on the Ground. With FSX, the action is the same whether you control the spoilers via 0BD0 or via an axis input. If you are on the ground and you write 4800 to 0BD0, the spoilers will immediately deploy, and 0BD0 will actually change to 16384 (for 100%), not 4800. This is consistent with the way the spoilers behave using an axis. If you are in the air, writing 4800 does arm the spoilers correctly in both FS9 and FSX. I think the more correct action, for consistency, is that being done by 0BD0 in FSX. If I were to make them the same I would need to change FSUIPC3 rather than FSUIPC4. So, how does this affect what you want to do? Now you konw how it behaves I'm sure you should be able to deal with it? You don't want to arm your spoilers on the ground in any case. ;-) Regards Pete

It isn't that an existing SimConnect application would cause that error on its own. The original bug I was describing was one which occurred, inconsistently, when a NEWLY installed SimConnect client was held at the "do you trust this program" type dialogue whilst another, already loaded SimConnect user, was accessing SimConnect. I did think I had explained that -- evidently not well enough. Okay. Choose to believe that if you wish. All I can say is that to my knowledge your experience is unique, and there are many thousands of FSUIPC4 users. Unfortunately, if none of my software is running it cannot actually provide a Log of why it isn't there! ;-). You can, if you wish, enable SimConnect logging (instructions are in the FSX Help Announcement above). If FSUIPC does get to run it will produce a L?OG and INI file in the FSX Modules folder created by the installer. If it doesn't, then the SimConnect log may show why. Furthermore, the Simconnect log may show whether there are any other SimConnect clients loading -- something which you don't seem to believe is the case, but at least it would prove it one way or the other. I'll check a Simconnect log for you if you wish. However, when it gets down to it, if you are unwilling to even risk trying again there won't be any point in looking at anything. Maybe you'll want to do more when you try the next SimConnect add-on and get problems? Regards Pete

If you are using the offsets, I think you need to operate the 0BCC value as well. When you set that non-zero, the value at 0BD0 goes to 4800. It would be up to you to check the spoiler notch range if you have no microswitch for that. Hmm. That's interesting. In my drivers, for instance in the PFC drivers, I always do the 0BCC setting myself. I'll check the FSUIPC3 code to see if I'm doing anything with 0BCC based on writes to 0BD0. I don't think I am, but you never know. Maybe if FS9 does this for you but FSX doesn't, I need to add some code to FSUIPC4 to make them behave the same? Regards Pete