Pete Dowson

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

Yes please. ZIP and email to petedowson@btconnect.com. Pete

I'm reading that myself here, but it is always zero for, for example, the Cessna Amphibian. The "handle position" changes from 0 to 1 or back (its a BOOLean) when I toggle the water rudder, but the values you want never change from 0. I suspect it needs an aircraft model with this part enabled. I can't test or develop anything without such an aircraft. Pete

I assume this was for an aircraft with such a nozzle? I can try to look for them here, but I need to know which aircraft to load, preferably one of the default ones please. Regards, Pete

If you mean reverse thrust, see the Throttle position offsets -- reverse is simply a negative value there. Pete

Do you mean you have both windows open together? That will certainly cause FS to struggle. In my experience having a second 3D window reduces FS's performance by 60% or more! If you don't mean that, does it still stutter with a simple visual model in spot mode? Have you tried any alternatives? It sounds simply as if in spot mode you are expecting too much of your graphics or processing system. Pete

You misunderstand completely I'm afraid. You cannot use anything whatsoever in FSUIPC to get any aircraft displayed in FS at all. The facility to inject TCAS data is intended to allow programs which are showing aircraft in FS via the Multiplayer interface visible on TCAS screens which use FSUIPC data to obtain the locations. That is all. The only way I know to get any visible and controllable aircraft into FS, apart from the user aircraft, is to use multiplayer. On the Microsoft FS website. It is one of the SDKs they provide I think. I know nothing more about it, I'm afraid. It isn't my in area of knowledge. Regards, Pete

It sounds like, probably uniquely, this panel is attempting to line up the aircraft using the same controls as you would, i.e. the normal aileron axis. It is obviously expecting more sensitivity, so certainly a larger null zone or a flattened response curve could lessen its ability to exercise the control it requires. Just adjust your aileron calibration in FSUIPC to give more sensitivity where this panel needs it -- near the centre. There's really no other way unless you can persuade the panel makers to change to using a different method (e.g. the inbuilt AP localiser tracking, or using aileron trim, or even by-passing the user control inputs and sending values direct to the SIM). Regards, Pete

You should most certainly be able to find a position on the lever movement which arms them. Don't test this on the ground, get airborne first. Why not try using the latest FSUIPC facilities for actually calibrating an ARM position? You can make that quite wide, so it is always easy to find. Yes, use the latest FSUIPC (3.65) and follow the very detailed instructions provided in the documentation specifically for setting flaps detente positions. Regards, Pete

Why not use cockpit mode then? Or possibly find a simpler visual model -- if there's a stutter in spot mode but not cockpit mode then I think it can only be the graphics causing that. An alternative would be to throw more processing power at it -- faster PC and video card. You could also try using normal flight mode by with the simulation set to zero sim rate (check the FSUIPC offsets). Pete

How have you assigned the axis as a tiller then? You mean you assigned it as another rudder in FS? FSUIPC options, "Axes" tab, then as per directions in the documentation. The tiller only appears in the direct to FSUIPC mode (as there's no such axis in FS). Calibrate both tiller and rudder in the Joysticks tab. Pete

As it says on SimMarket, get the software from http://www.schiratti.com/dowson. The ZIP file includes full documentation and other goodies. Pete

The current version is 3.65 and, as always, is available at http://www.schiratti.com/dowson, along with all my othe FS software (for seven years now). I'm sure it tells you this on the SimMarket sales page! Regards, Pete

It sounds like either you are using a bad (pirated) key for FSUIPC, or you are using a version of FSUIPC before 3.53 with a Key purchased in 2006. These are the only two known possible reasons for an application to work without registration but not with. Best to leave it alone then. I'm sure ActiveSky can manage very well in any case ;-) Regards, Pete

Yes, assuming you've not actually got a second copy of FSUIPC (renamed perhaps) in the Modules or the main FS folders, it sounds like something you've installed into FS is not terminating correctly. There will be a copy of FS9.EXE (with all its modules including FSUIPC) still running on your PC from the previous time you ran it -- the window etc has closed, but FS has not terminated because something is running a separate thread which isn't terminating. Check by using CTRL_ALT_DEL and looking through the Process list -- you'll probably find FS9.EXE there. Terminate it using the button at bottom right, then I think you'll find FS loads okay. Assuming this is what is occurring you'll need to find the culprit. I know early FS2004 versions of Active Camera could do that, but that was fixed long ago. Please note that version 3.53 of FSUIPC is over six months old now and not supported. The current version is 3.65. Regards, Pete