Pete Dowson

FSX doesn't offer any calibration. It relies completely on Windows (driver) calibration. What do you "reset" and how? You must ALWAYS calibrate, before running FSX, in Windows "game controllers" or, possibly, the driver that comes with your device. Normally installing the device will update the driver which Windows' games controller accesses. THEN when you run FSX you have a choice. Assign in FSX or assign in FSUIPC4. You need to decide. if you are already assigning in FSUIPC4, why are you making that choice when you have things working well with FS assignments? If you assign in FSUIPC4, again there is a choice -- assigning direct to FSUIPC4 calibration or, the default: assigning to the FSx controls. Whilst the former is more efficient (it cuts some paths out), sometimes the add-on aircraft you may be using need to see the FSX controls. That is why that route is defaulted. If you do assign in FSUIPC4 and not in FSX you should be very careful to ensure that the same controls are not also assigned in FSX -- you will get conflicts if you have dual assignments. Generally it is much better to either assign everything in FSUIPC4 and disable controllers in FSX completely, or to assign axes only in FSX. Note that if controllers aren't explicitly disabled FS does have a tendency to re=assign automatically, especially if you ever unplug your controllers and plug them in again, even in the same sockets. THEN, no matter how or which way you assign, you can still calibrate in FSUIPC4. If you assigned "direct to FSUIPC calibration" then you MUST calibrate in FSUIPC4, else the controls won't work. But if you used either of the other two methods of assignment, the controls should still work without FSUIPC4 calibration, and the latter is merely something you do for more accuracy, or a different type of response, or possibly to map your single control onto multiple ones in order, for example, to get a reverse zone on a throttle. If any of this is giving you a problem then please identify exactly where you have the problem, and how you got to that stage. Maybe showing your FSUIPC4 settings (the FSUIPC4.INI file in the modules folder) will help show what you've done. I seem to recall i mentioned other types of information which might come in useful, too, like logs with Axis logging enabled? Some time ago I think. This thread seems to have got rather, er, stretched? Regards Pete

I don't think FSInn uses FSUIPC either. They use their own module called FScopilot. I think to use it on a network you have it installed and running on both PCs and it talks to itself, so to speak. ;-) Again I'm talking from only what I think I picked up after a brief look. Pete

I'm afraid Squawkbox 4 only uses SimConnect when connecting to FSX. I've a feeling there's no choice, even though it can use FSUIPC on FS9 and before, because it also has modules running inside FS, and the FSX versions presumably won't handle the interaction with the remote SB4 via WideFS. This is my understanding, in any case, but you'd probably learn more about it all on the SB Forum. http://squawkbox.ca/forum/viewforum.php?f=4& I was going to learn about on-line flying with SB4, but found that since doesn't use FSUIPC it also doesn't provide any way to operate the Transponder modes from a hardware transponder. I have requested facilities to be added to allow this (it only needs a mode switch and an Ident), as I'm sure they can be done in the same way as the PTT -- with support added to FSUIPC4 and WideFS for these actions -- but I've had no positive response at all, and in fact no response from the developers despite occasional emails to them, for over a year now. I assume they've given up on SB development. FSInn has been recommended to me, and that does have the facilities needed, but I've read the occasional things about that, too, which put me off. It seems pretty good on FS9 but some say flakey on FSX? Regards Pete

No, you'd have to put it in. It still operates the same. If you are only assigning in FSUIPC, yes it would! ;-) Regards Pete

IMPORTANT I'm pretty sure I've now undone the change which had the weird effect on the COM and ADF frequencies. I have not managed to work out why the small code change I had made (it was in 3.953) had the strange and very selective affect it did, but it appears related specifically to those with PMDG aircraft installed, even if it appeared to affect others too. Please download and try version 3.965, now in the Updates Announcement above. That should fix it. Please let me know otherwise. Regards Pete

Timing out the new Joystick Timeout I added to prevent lockups in the buttons ansd Axes tabs through rogue joystick drivers. The timeout is on the "joyGetPosEx" call to Windows. That should always return, no matter what the joystick driver is doing. But a lot of hangs in the FSUIPC options have occurred simply because it is scanning all possible joystick numbers and sometimes folks have had old drivers installed for long-gone joysticks which then take an age to return. If that time is longer than the poll interval, it appears to be hung. Yes, but a lot of folks are assigning direct in FSUIPC these days, so FS's stuff doesn't come into it. On FSUIPC3 the joyGetPosEx calls are still used, not the DirectX ones. For buttons and switches FSUIPC4 also uses joyGetPosEx, not directX. Thanks for all the info. I'm sure it'll help some. I've got no CH gear at all these days. Best Regards Pete

I'm afraid there's more than one "mistake". I don't know VB but I can see several at a glance: Two things wrong here: First the data starting at 3210 is an ARRAY of DWORDS, or 32-bit values. In VB you probably have to treat them as integers -- but check the size your compiler produces for that. Second, if you assume that the first slot, the one at 3210, is "free" and simply write to it, your program will not cooperate with any other program using hot keys or menu entries. As the documentation says, you should search for a free (all zero) entry and use that. The document tells you that the first byte must be the SLOT NUMBER (I). You would have seen the slot offset computed by 0x3210 + 4*I. So the slot at 3210 would be slot number 0 (zero). Right? You've used "1". not even the NUMBER 1, but the CHARACTER 1, which, assuming the VB compiles into ASCII, is actually a byte value of 49 (hex 0x31), not 0 nor 1! And that's assuming your VB compiles into normal ASCII. I think VB might default into compiling into wide characters or Unicode or somesuch. Pete

Rotary "ticks" alternately switch the "button" on and off, one action per "tick". To use both actions you have to program both the "press" and "release" in FSUIPC. Pete

Never heard of that happening, but I cannot really help at all without knowing what version of FSUIPC you are talking about. If it isn't the latest (3.96) please install that. There's also a later version 3.964 available in the Updates announcement above which you should try. Regards Pete

I've managed to reproduce it, but only after installing the -800/-900 update. It is most odd. It only affects the COM and ADF radios, not NAV nor Transponder, nor anything else as far as I can see. It is very odd indeed. Certainly FSUIPC doesn't have anything to do with those, other than reading all of them for the benefit of appliations -- but it has always done that! And it doesn't seem to be dependent upon load -- its just sitting on the runway and the FPS is between 70 and 90 all the time! I do see that the aircraft constantly sends these 4 controls to FS: It does this very frequently indeed, the whole time. Rather a performance waster if you ask me! However, they cann't be the culprit. Anyway, I'm happier now i can reproduce it so I shall study it during the week. I'm afraid I cannot simply drop everythnig else, but I won't let it go! ;-) Regards Pete

I might have those someplace. I'll search. Time doesn't seem to be a factor here. It's been running for a few hours and the radios are just as responsive. But it isn't under much load. Maybe you could get the sim to the state where this is occurring, and save a Flight for me to try here? ZIP and send the FLT and WX files please. If you are over add-on scenery please let me know what it is -- better over default if you can repro it there. Also please tell me what sort of frame rates you get normally and if they are any different when it happens. Has anyone asked PMDG if they can look at it too? With FSUIPC not really being in any way involved in radio tuning with mouse, and with the PMDG radios being standard FS radios (just graphics changed), whatever is going on must be something else, inside PMDG's code, and presumably in something where it is interacting with FSUIPC. The trouble I have is that none of the facilities offered to or used by any FSUIPC3 applications has changed between 3.93 and 3.96. The changes have all been realted to user facilities -- and with the test using a default INI file you've proven those aren't involved. It is very puzzling. If PMDG can't help it may not be solvable. My PMDG contact was Lefteris Kalamaros and he's not with them any more. I suspect he's also the only one who really knows the 737NG. Regards Pete

Okay. Thanks. I couldn't get my install of the PMDG737 working but I've found the original install files in my back-Ups. I've installed the -600 and -700 version 1.3 from January 2004. would that be close enough to whatever you are running? The mouse works fine on the Radio Stack I then bring up. This might take me some time to work out what is happening, but first i need to be able to reproduce the effect. Is there anything else you can tell me to make it more likely to happen? I notice that in the PMDG options menu there's a facility for adjusting the 2D and VC update rates. Have you found these to have any affect of the problem? Regards Pete

The log shows nothing useful or odd. The modules list shows "Actigate.dll" which I'd like you to try without, please. WideFS applications will make no difference. What version of windows are you using, BTW? And does the problem exist with both 2D and VC PMDG cockpits? I've been trying to get my ancient copy of the PMDG 737 running, but FS9 complains about the MAIN gauge and loops forever complaining about it. That's on Win7 64-bit. Maybe it isn't compatible? Otherwise I must have some parts of PMDG corrupted -- very long time since I last tried it. And I can't find the original files! :-( Pete

There are different solutions for different problems. Without information no one can help. I suggest your first port of call is the FSCommander support Forum. Be prepared to expand a little on your complaint though. Regards Pete

Hmm. Maybe it gains such prvileges somehow, else I really cannot understand why you'd need to elevate WideClient. No, that doesn't happen. I know that for sure. But certainly it means that TeamSpeak's folders are read-only unless you have elevated privilege. It is something to do with the read-only folder problem then. But why, I couldn't guess. Regards Pete

You are mistaking FSUIPC for a hardware driver. It isn't and has never been such an animal. it is a module which runs inside FS and opens an interface for programmers to access FS internals. They do this by writing programs to do so. if you want to drive a serial port connected display you need to write a program. The FSUIPC SDK provides the interface information you need. Alternatively you could look at using one of the proprietary interface cards now available which come with their own drivers interfacing to FSUIPC and which are configurable using parameters or scripts. Regards Pete

nothing extra initially, but I'd like to see the default log in case any errors are logged. When I have the answers to the other questions I may ask for more. I've not got a lot of time today so it may get delayed till tomorrow (monday). Regards Pete

Thank you. Is this perhaps because you are running Teamspeak 3 "as administrator"? I expect Win7 refuses to pass SendInput data between programs of different privilege levels. The same applies to anything using the FSUIPC interface -- both FS (or wideclient) and the application need to be at the same privilege level. Regards Pete

How many are experiencing this issue? If there's more than one I can't really see how it could be a hardware or FS installation problem. What on earth can hold a mouse click for "several tens of seconds". Can you do anything else whilst you are waiting? You are also using a PMDG aircraft? Are you all using the same one? Can I take it this is not happening with default FS2004 aircraft? If you don't know, please try one of those first. If it is occurring with default aircraft and going back to an older version of FSUIPC "fixes" it I'll certainly need to dig deeper. If it is only with PMDG aircraft it must be somehow related to how they are using FSUIPC. Possibly their code is taking advantage of some undocumented feature 9"bug" in the older versions of FSUIPC which is now fixed, so I'd need to know about that too. Either way I'll need more information, like: 1. Is the FSUIPC registered? 2. If so, if you remove the FSUIPC.INI file (temporarily) from the Modules folder, before loading FS, does the problem still occur? If it doesn't I need to see the FSUIPC.INI file please. 3. What external applications are running which may use FSUIPC? 4. Are you using any Lua plug-ins? Is there an "ipcReady.lua" or "ipcInit.lua" file in your modules folder? Is so I need to see it/them. 5. Are there any other non-FS modules in the Modules folder, like pmdgOptions, actigate, squawkbox ones, fscopilot, fsinn, etc etc? (If you are all using PMDG aircraft I'd assume that there will be at least pmdgOptions.dll?) Maybe I need to see József's log file after all: Please send the ZIP as an attachment to an email addresses to petedowson@btconnect.com, please. Apologies for not understanding that this was a more general problem. My previous excuses cannot apply if the exact same thing is happening to more than one user. But I cannot do much without more information. Thanks, Pete

But you ran the FSUIPC4 Installer under the user called "Administrator", as shown by the Log you posted: Looking for the current user's Application Data path: ... found as "C:\Users\Administrator\AppData\Roaming" You MUST run the installer when logged in as the user who is going to run FS!! Pete

Ah! In that case, FSUIPC cannot possibly have anything to do with it. Why did you post your problem here if it wasn't anything to do with FSUIPC facilities? Don't "enable almost everything"! Why on Earth would you do such a thing. I certainly don't want to ever see such a log, and I don't need to see it for non-FSUIPC operations like using a mouse on a radio stack because it cannot be involved. There simply is no possible relationship between FSUIPC and mouse clicking on a panel. If it looks that way it will be a coincidence related to something like memory arrangements, each version of FSUIPC being slightly different in size and memory usage. It really does sound like you have some sort of memory problem on your PC, or possibly a corrupted FS installation. [LATER] I see from another user report that my explanation above cannot apply. Please ignore the above and read on. I had not related all this to the specific point about the PMDG aircraft, which does use FSUIPC. If you still have that Zipped log, send it to me at petedowson@btconnect.com. Apologies for my earlier disbelief. Regards Pete

Sorry, "most recent" only means "the most recent one I'm aware of". Folks have said that who were using a year old version. Always quote version numbers please. That's what they are for. I assume you mean WideFS? MyTraffic merely installs more AI aircraft models plus BGLs containing the routes. It cannot possibly affect WideFS operations. I use MyTrafficX which is the non-Aerosoft version of the same package. What is the symptom? Is WideClient "waiting for connection", or is it simply that FlightKeeper isn't connecting. More information is needed: FSUIPC4.LOG and WideServer.LOG files from the FSX Modules folder, WideClient.LOG from the WideClient folder on the client PC. And a fuller description of what you see happening. Regards Pete

I notice you posted in the MyCockpit forums. The RC support forum is actually over in Avsim, here: http://forums1.avsim.net/index.php?showforum=135 Pete

There no difference to FSUIPC4 between mixture prop or throttle. they are all just axes, all the same. How are they assigned, in FS or in FSUIPC4? If in FSUIPC4, are they assigned direct or via FS controls? It is difficult to suggest anything to help with no information at all. Perhaps you should enable Axis logging, do your thing, show both FSUIPC4.INI and FSUIPC4.LOG files. From what I've read quite a lot of folks seem to have difficulties trying to use both CH Manager and FSUIPC4 for the same controls. Could this be a source of confusion, perhaps? What do the folks over at the CH Hangar site say? Regards Pete

If it is in Beta I assume there's a support address or forum? Wouldn't the developers be the best folks to help? They must realise that their program is used is such ways? Regards Pete