Pete Dowson

Oh, sorry, didn't mean it like thatit's just that what was happening sounded so wrong. :-( Oh, goodthat's all right then. Phew! :-) :-) Thanks! Pete

What do you mean "as usual"? If you've not paid for WideFS it is not legal for you to use it. Please ZIP up the last FSUIPC.LOG and FSUIPC.KEY files so that I may investigate this. something is not right. Regards, Pete

That's not legitimate -- one of the recent releases was a Beta b mistake. It will expire one day soon in any case then nothing will work. Check the wideServer Log. it probably says you need to register WideFS. Yes, you certainly must! It's the only honest thing to do in any case if you want to use it! Regards, Pete

Not corruption. You were using version 3.48 which is too old for a 2006 user registration, as was clearly notified to you in the email with the Keys. There's absolutely no need to delete anything at all. If you do you lose all your settings. All you need to do is replace the FSUIPC.DLL with the latest version (3.65 at present). Regards, Pete

In that case it is most certainly a problem with your Key. That IS the FSUIPC.LOG file. What do you mean, you can't find it??? Version 3.48!!! No wonder -- if your registration was purchased in 2006 you need 3.53 or later! Current is 3.65! The log proves it is a Key or Version problem. Please ALWAYS use the latest version! Regards, Pete

Sorry I don't support old versions -- 3.53 is now over 6 months old. Current is 3.65. Please update. Pete

With FS2004 most of the old FS98 methods of doing things with weather don't work too well in any case. The weather is cleared initially because you cannot set "global"weather (which is all FS98 had) whilst the world is populated with localised weather. After the weather is cleared for you (which only happens the first time you try to use the old FS98 weather interface) then of course you need to set suitable clouds -- you cannot have any rain or snow without a cloud layer. Even then I have doubts. In FS2004 the weather becomes "localised" after a while, and then you cannot use the global weather settings unless you clear the weather again. Horrible. If you are really interested in dealing with FS2004 weather please check the New Weather Interface, which is designed for FS2004. Regards, Pete

This is probably one for the PMDG support folks. I don't know their aircraft. However, there are tow things I can think of: 1. Perhaps there's no power? The 737-600 has a glass cockpit system and needs electric power to show anything. Have you checked battery etc? The PMDG aircraft are quite sophisticated and usually it isn't a matter of load-and-fly. 2. If you do think it possibly has anything to do with FSUIPC (like, did this aircraft work differently BEFORE you registered FSUIPC?) then please load up FS again, load the aircraft, see the problem, close FS, the show me the FSUIPC.LOG file which you'll find in the FS Modules folder. Regards, Pete

Yes, but it won't accept any applications unless those too look for the different classname. Anyway, that wasn't what you asked, was it? I thought you wanted a Client running Squawkbox or similar to have the latter's PTT controlled from more than one Server? That would be two WideClients running on that client PC. Oh, I didn't understand that from what you said earlier, sorry. But the same principle applies. Don't send H though, use the PTT control. there's no need to use the ketyboard in either circumstance. Regards, Pete

No. If you want to manipulate axis controls just intercept the controls and change the values. They go through the main FS window (class "FS98MAIN") as WM_COMMANDs. Regards, Pete

No, they are analogue brakes. You have two position-sensitive brake axes, one left and one right. You need to calibrate them either in Windows or in FSUIPC, and go to FS Options-Controls and ensure that the sensitivity is at maximum (slider right) and then adjust the null zone to stop the brakes coming on too easily. Alternatively set the null zone full off (left) and use FSUIPC to set a dead zone. Test the brake axes too -- they may be reversed (ie. on when released, off when pushed). You can reverse them in FS or in FSUIPC. No, you don't need to. Regards Pete

You don't say what pedals they are, but it won't be the rudder control itself, but the toe brakes on the pedals. Assuming they are analogue brakes, using the Axis brake controls, you need to calibrate them correctly with an adequate null zone (i.e. leeway for slight pressure). It they are digital brakes (i.e. basically on/off buttons) then you may have them reversed, but generally such toe brakes shouldn't be a problem. Operating the toe brakes releases the parking brake on many implementations because it sends the controls to tell FS to do so. You need to sort the toe brake assignments and/or calibration out, or simply avoid pressing on the top part of the rudder pedals when moving the rudders -- for realistically sized rudder pedals keeping your heels on the floor is normally safe enough to avoid toe brake depression. Regards, Pete

Sorry, I've no idea. What you describe almost exactly also describes my setup, on two different machines -- the only difference being that I don't use "polyview" but Jeppesen FliteMap in one WideFS client and Memory Map Navigator in another. You could try using PortMon (from http://www.systeminternals.com) to monitor all the COM ports on the client and see if they are identified as you are expecting and whether appropriate NMEA data is emerging from one of them. You should also check the WideClient LOG file on that PC to see if it says it opened the right COM port okay. Regards, Pete

Yes, that's what I said wasn't it? ;-) Pete

No, sorry. ALL the protocol code in WideFS is using directed communications. What you are asking for would either have to be done by a separate mechanism altogether (broadcasting), or would need Wideclient to establish multiple links to multiple servers, quite an horrendous upheaval in code either way. Well that's too specific. WideClient talks to one Server. How it identifies that server varies -- you can omit identifying it in the INI file and it will find it (on WinXP or Win2K systems) by the occasional mailshots sent by any running server. It just latches on to the first one with the matching Port. No, it is nothing to do with security. What you are asking is a totally different way of programming network links. Broadcasting is not really suitable for the majority of what WideFS does. Don't forget its main job is to allow FS applications on client PCs to talk to FS and receive *specific* information from it as if it were running on the same PC. Broadcasting won't do that. For WideFS we need a one-to-one connection between application and FS. You can run another copy of WideClient in the same client PC with a different Class name -- see the ClassInstance parameter in the WideFS doc. In that WideClient INI identify your friend's FS Server. You don't need SendKeys for Squawkbox PTTs as they are built in. Just program the FSUIPC controls for PTT. Regards, Pete

Actually it does for all three protocols, but there is a bug in the current release which only occurs if you specify the Server in WideClient by IP address instead of either omitting it (the preferred method for several releases) or also specifying the protocol, as you have done. Sorry, I would have released a fix (it affects Wideclient only), but I'm in the middle of something else at present. Oddly, I did actually think it was unlikely that anyone would be using IP addresses when Names are so much easier and more flexible, and even more unlikely that the protocol was not also specified by those that were. So far I think there have been three including yourself. For the others please see thread http://forums.simflight.com/viewtopic.php?t=53340 Yes, it's a bug. Apologies again. I will release an update for WideFS, and probably FSUIPC, by the end of the month, hopefully. Regards, Pete

Hmm. Odd thatI found the opposite. I always used SPX on Win98, but with WinXP this was a problem. Since XP SP1 the TCP (and now UDP, faster and supported by WideFS) protocol seems better on my systems than SPX. Okay. Good. You do know that, if you are using WinXP all round, you can simply omit both protocol and server details from every client and select the protocol in the Server with one parameter line? Makes it easy to swap between the three now supported -- SPX, TCP and UDP -- to see which is really best on your setup. Regards, Pete

Interesting. I assume you de-assigned the axis in FS when you changed to the direct method? Otherwise it will be actioned twice. There are two possible reasons. The most likely is that the FS axis assignment has the sensitivity and null zone sliders set all wrong. This seems to happen a lot. For any FSUIPC calibration set the FS sensitivity to maximum (full right) and the FS null zone to minimum (full left). The second possibility is that you have an aircraft panel which is intercepting and dealing with the flaps control too, and this is interacting with FSUIPC's attempts. By going direct to FSUIPC, it is FSUIPC reading your joystick axis, not FS, and both FS and your panel only see the post-FSUIPC calibration results. Remember, the original FSUIPC joystick calibration system was really not so much a joystick calibration as an "FS axis control" calibration. It does NOT read joysticks, it doesn't know about them. It merely intercepts FS axis controls on their way to the simulation engine. It is FS which scans and reads the actual axes. The new Axis assignments facility in FSUIPC is a replacement to the FS axis assignments facility and allows FSUIPC to keep everything "in house" so to speak. Hmm, really? What about this: The bit about by-passing FS is important to note, as well as the bit about having access to axis types not even assignable in FS (which previous could only be used by editing parameters in the FSUIPC.INI file for "stealing" axes assigned to less useful things in FS). Regards Pete

No, for two reasons. First these log entries are only there for information -- the User registration here is fine. FSUIPC will not be adversely affecting that gauge's operation. Second, as far as I'm aware all Lee Hetherington gauges are well behaved whether they get access or not. Certainly it would be more efficient for the renamed gauge ILH_TCAS2.GAU to be changed back to its correct registered name ILH_TCAS.GAU, as this would stop FSUIPC wasting time searching through memory for the incorrect module, but with a user registered FSUIPC it really makes only that smidgeon of difference each time such an aircraft is loaded. Regards, Pete

Only if you are using FSUIPC's Axis assignments. You don't need to go that far just to assign and calibrate flaps in FSUIPC. Just assign your flaps lever in FS, make sure it responds (sensitivity slider max, null zone slider min), then use the Joystick Calibration page in FSUIPC. If you use the Axis assignments in FSUIPC you have to be careful to make sure FS is not also trying to assign the same axes. The safest way is really to do everything in FSUIPC then -- buttons and all axes -- and turn joysticks off altogether in FS. Otherwise it seems that sometimes FS can automatically assign axes it sees in a later session. Regards, Pete

Not sure why you are referring to FSUIPC here. It sounds like you have a corrupt aircraft or flight file. Try deleting your FS9.CFG file and letting FS build another (save a copy of the orginal if you wish). There's nothing happening here relating to FSUIPC, though it seems odd that it shows FS running happily for at least 90 seconds whilst you mention only 2? BTW I would strongly advise you to upgrade to FS9.1 in any case -- the improvements Microaoft incorporated in its update for FS2004 cured a large number of CTD problems. Yours might be one such! Also I suspect there are a lot of add-on packages now which may well be incompatible with the original release. Regards, Pete

Hi Bill, Try interim test version 3.651 attached. I've not done exhaustive testing, but is seems to work okay so far. "ShortaircraftNameOk=Substring" (actually "sub" will do -- it fills in the rest). Regards, Pete FSUIPC3651test.Zip

Try the attached interim test version of FSUIPC, 3.651. Pete FSUIPC3651test.Zip

Okay, received your ZIP, thanks. That helped a lot. I've now managed to map them correctly (for read only) to offsets 2A78 and 2A80, as doubles, with the BOOL handle flag in 2A88. I'll send you an interim update here tomorrow or the day after. I'm in the middle of some other small alterations too (substring matching for aircraft names in the [Keys, [buttons, [Axes and [joystickCalibrations sections). Regards, Pete

Sorry, but in the Log you sent me this evening there is absolutely no sign of any attempt by FSXpand to contact or interface with FSUIPC. I'm afraid you have a bad copy of that program. I suggest you contact the support for it as obviously there's nothing I can do at all as FSUIPC simply is not involved at all. Regards, Pete