Pete Dowson

I've no idea how SB works nor what it is doing -- have you had any answers from SB support? I've never used it at all I'm afraid, so I don't know anything about it. The PTT controls sent by FSUIPC are simply those defined by the SB programmer. Why are you using KeySend still? Since version 6.50 of WideFS last August) and version 3.50 (also August 2005) there has been direct support in FSUIPC & WideFS for PTT on/off controls with no need for any action in the WideClient parameters, and certainly no need for KeySends for this action. Are you using very old versions by any chance? That definitely sounds completely wrong. Even the "RWon" and "RWoff" facilities originally provided for PTT via KeySend used two special commands for RW & SB -- one to switch the mike on and another to switch it off. You should certainly NEVER have any KeySend set to repeat. I think that may cause problems with WideFS in any case. Really? How odd. I don't know how FS would be doing that, unless it thought your joystick was newly connected -- i.e. didn't have the same ID as the last one, as defined in its FS9.CFG. If the ID is changing it sounds like a problem in the GoFlight drivers. FS will do auto-assignments if it things it's a new device. No. Even if FS was doing something with the button as well as FSUIPC, if it is assigned in FSUIPC then FSUIPC will act upon it. It cannot, as "reinstalling" FSUIPC isn't really possible. You can disable it by removing it and re-enable it by putting it back, but if the parameters are the same each time you have returned to exactly the same state, so there's no difference. Well, there appears to be a great deal of information you are not telling me -- first, if you are really using such old versions of my software please update to the latest. Even get the interim versions from this Forum (see Announcements). Then program the PTT correctly using the PTT controls, and delete the KeySend assignments in the WideClient INI file(s). The fact that you say you have to enable Repeat to make it work even when it does suggests that, even with the old KeySend method, it was most certainly not set correctly in the first placeperhaps you could tell me exactly what versions you are using and how you attempted to program PTT some time? Regards, Pete

If the button above the IN and OUT values says "SET" then the axis is not being claibrated. You click it to start the process (and it changes to RESET). Then you set each of the other four values using the Set buttons above them (same button for the centre range). It doesn't need any engineering or programming skill. If you understand enough to fly FS at all, or even install it correctly, then this is simple. Just because it has numbers instead of wobbling spots like the Windows calibrations doesn't mean it is any harder. Please refer to the numbered steps again and tell me exactly which ones are so complicated for you. What words exactly are so confusing??? :-( Pete

When you uninstall FS it doesn't uninstall everything. For instance, all your flights are retained, and so on. Sorry, then, I have no idea. But as I have said a number of times, it does NOT!!! So be it. But remember that you have a problem which is not and cannot be anything whatsoever to do with FSUIPC, as you proved to start with by removing it to no avail. Installing an old version is not going to "fix" something which no version is causing! You call it a 3.6 experience, but it is not and cannot be as you have proven. You have even ignored me every time I pointed out that FSUIPC doesn't intercept ATIS messages and you somehow continue to assume it does. I'm sorry I cannot help, but it really is not FSUIPC you should be looking at. It cannot be, it is not possible as you have clearly demonstrated. Regards, Pete

Hmmmnot enough for Radar Contact though, the main user of the multi-line display facilities in FSUIPC. Yes, I see from the SDK that the application can retrieve the size of the display and then has to provide a bitmap for the display. The code it needs is relatively trivial, but the text font calculations and conversion to a bitmap, using Windows GDI facilities, is bulky and tedious. I've not got enough time to fit this in at present. I've made a note of it and may consider adding support some time in the future. Meanwhile it may be worthwhile seeing if some other programmer may like to write a utility for it -- as Jose Oliveira did with the Showtext utility for displaying the messages in a window separate from FS (even on a WideFS client). Regards, Pete

Sounds like a complaint/suggestion to the makers is in order? ;-) Regards, Pete

No. There's an option for messages being sent THROUGH FSUIPC (i.e. from an FSUIPC application) to the FS message window to be encoded for white text, but there is no code in FSUIPC to intercept any FS messages let alone change any of their parameters at all. The ONLY code which intercepts messages in FS is in AdvDisplay, but even that doesn't change parameters for FS's messages. No, that is simply not possible. FSUIPC is completely self-contained in the one DLL module. There is nothing separate possible to "hang around", and as I said in the first place, FSUIPC doesn't intercept FS messages in any case, it simply directs application messages. The colour option only applied to them. Well, something else is going on then. I'm very sorry, but I've no idea. Well, there is really nothing in FSUIPC which would change all that behaviour, sorry. As far as I knew the Show ATC Text option had little to do with the ATIS message in any case -- the latter is a completely separate window, and FS's ATIS stuff has been in FS for many more releases than ATC. Well, I'm sorry, but that can only be a coincidence. And most certainly a fresh (COMPLETE) re-installation of FS would restore it back to its normal operation. So evidently you did not truly uninstall it all beforehand. Try removing the FS9.CFG file and restarting FS. If it is anywhere it will be there. I'm not aware of any registry stuff for FS9 other than the usual install data. I assume you mean "No"? Anyway, that's only an option for application messages. There is NO WAY for FSUIPC to change the ATIS message because it does not intercept it. No, because as I said it is only AdvDisplay which did that, and then not for ATIS messages. If you are getting the wrong colour messages without FSUIPC or AdvDisplay loading, it is an absolute dead certainty that neither of these have anything whatsoever to do with it. Have you even tried simply deleting the FS9.CFG file? That is usually the very first thing to try when you get any odd behaviour from FS! Regards, Pete

Program the buttons to send either F2 keystrokes (one button all engines) or THROTTLEn DECR controls. For the latter, enable repeat. You would have to reduce throttles to idle, then hold the button down, just like holding the F2 key down. Pete

A .reg file? That would be nothing to do with FSUIPC. I'm pretty sure that the ILH_TCAS gauge has a valid key, but it looks like the gauge has been renamed to L_ILH_TCAS2 which will make its key invalid. Regards, Pete

There seems to be quite some difficulty with FS2004 overcast. I think the better weather programs like ActiveSky get around this by using more than one layer. FSUIPC can set weather at weather stations, and you can select stratus. But you have no direct control of the rendered graphics, and they are moved by the wind not by any "cloud flight controls". Sorry. Not FSUIPC and not, I think FS directly, except via multiplayer,, but that's for "aircraft" not clouds. Regards Pete

Only if it can be set to receive either NMEA position data or AV400 "Aviation format" data. Most GPS's provide OUTPUT, like GPSout, and don't accept input positions except from an aerial. Refer to your GPS manual. Regards, Pete

Since FSUIPC does not dynamically change anything, but simply reads the INI each time it loads, this really cannot be happening the way you say. Simply putting in the same parameters as were there before would make no difference whatsoever. It simply cannot do so. It sounds more like you have done something strange, such as selected "repeat" or similar on the button programming. Tell me more details about exactly what you are doing and I'll see if I can spot anything wrong. Pete

What is the clickspot supposed to do? If the folks who programmed the panel are using FSUIPC for something then I could see how that could produce a problem if something were in error, but the only thing I know about like that was related to a gauge called ATN, and the problem was fixed in one of the interim versions available here. Did you check? Please see the Announcements at the top of the Forum. Regards, Pete

Ah , for the last few years all my holidays have been on steam railway tours, and mostly with the Railway Touring Company -- check http://www.railwaytouring.co.uk. Regards, Pete

FSUIPC doesn't drive any displays. You'd need GFdisplay to operate the LEDs. I have used a GF-T8 successfully for lights -- from what you describe it sounds like your problem is specific to the particular aircraft. Have you tried it with the default 737? Do so, to check. It is quite likely that the panel programmer is controlling the lights directly -- you would have to find out if there's a key assignment you can make to operate the panel's switches instead. Pete

No. There are absolutely no permanent changes FSUIPC makes to anything at all. Simple removal of the DLL from the Modules folder is a complete uninstall! Sonds like there's something else happening in your system. It is AdvDisplay which intercepts FS ATIS messages in any case, not FSUIPC -- the new message facilities in FSUIPC can foward external application messages to FS for that display (and with the colour option) but it cannot interfere in FS's own messages. Sodo you have AdvDisplay installed? Regards, Pete

I'm using it in my 8 PC cockpit setup. There are occasional rare errors with blocks arriving out-of-order -- unlike TCP and SPX there's no guarantee of arrival in order (nor even of arrival at all) -- but so far those don't seem to do any harm. Avoid loops in the Network though (i.e. two separate paths) -- I had a FireWire loop originally, and that produced a lot of out-of-oder block problems. I think the performance I'm getting is a bit smoother, and the FS frame rates a little higher, but I can't quote any precise figures at present. Regards, Pete

They are probably not mapped into FSUIPC as no one has asked for them before. Can you be more precise over what you want and how I would possibly recognise it if I saw it? Pete

ErI didn't think the BRAKES message came on with auto-brakes, only manual braking. Are you using the latest interim version of FSUIPC? Please try that if not. All those calibrations seem far too "precise" or "reguar" to be true calibrations. Are you sure you are leaving a small dead zone at either extreme? Even the centre zones for the main controls seem impossibly contrived for manual calibration! Without any "parking" place for the brakes when off it is likely that they are appearing to be on a little, on occasion. Pete

Well, of course. You could put the microphone and the recognition software on the MCP client and use PM's keystrokes instead, provided the MCP has the keybopard focus. Otherwise, only by asking Enrico to add voice recognition to his programs. ;-) Which aircraft are you simulating trhat has voice activated controls, by the way? Or are you just simulating a CoPilot? Regards Pete

You could write a program interfacing to FSUIPC to do such things, yes, though changing the autopilot values won't do anything unless the autopilot is engaged. You can move the airlerons and rudders and elevators direrctly too, or their trims. Get the FSUIPC SDK. http://www.schiratti.com/dowson. Regards, Pete

They sound like reasonable INput values, yes. You calibrate in FSUIPC to change the OUTput. If you calibrate max correctly you will always get 16383 for max OUT. Min would give you -4096 or similar, whilst the whole idle zone (which can be as large as you like) will certainly give 0. You simply need to calibrate in FSUIPC by following the numbered steps in the documentation. It couldn't be easier. You are currently mistaking INput values for CALIBRATED values, which they are most certainly not. If the OUT value is identical to the IN value, then you haven't even enabled the calibration! Pete

No idea what NetBIOS is nor how to program it. There is no Netwrok code whatsoever in GPSout -- if there's any relationship it will be something you have installed whoch is hooking COM2. Check by using COM1 or any other port. On Win2K or XP, WideServer by default sends a mailshot every 1 second so that its Clients can identify it. I have no idea what Ports Windows uses for its mailshot service. No, nothing of mine tries to do any such thing. Sorry. Pete

Not seen any of those. How many lines/characters per line? I'm not really developing Advdisplay any more, having moved the main point of it into the latest FSUIPC versions. However, I can take a look for the latter. Any links to details? Keyboard names/ids etc? Pete

Yes, each correctly configured WideClient can and will receive the same GPSout transmissions. Pete

Since there is no difference between them either electronically or programmatically -- they are only mechanical levers, with no identifcation readable in the firmware/software -- that was really an unnecessary expense unless you like tyo be totally realistic and also have positive "latches" for the "centred" idle points. Whilst I had one of eachtype of quadrant for development, all the testing could have easily been done with just one 6-lever quadrant. An ordinary lever has two points of intereset -- maximum and minimum. So for such levers that's all that needs calibrating. On levers which have three specific points of interest (eg max, idle, reverse or max, idle, feather, etc) then obviously calibration of the "centre" zone is needed. For the levers with latched/gated centres you need to calibrate that latch point with a defined area (just above, just below the gate), to allow for small variations in the pot reading. Just follow the directions and it will work. Pete