Pete Dowson

Really? I've never heard of anything like that before. The dialogue facilities FSUIPC uses are standard Windows facilities, nothing special or different at all. The only thing I've ever heard of which does cause dialogue window problems is something called "Window Blinds", which is an add-on for Windows which tries to provide user-controlled tailoring for Window appearances. It sounds like you may have something like that interfering. Maybe not that exact product, but possibly something like it? When you say the SCREEN goes black, do you just mean the FS window? Or are you running in full screen mode? If so, try switching FS to Windowed mode first. If it works okay then it is likely to be a problem with your video drivers, not correctly supporting standard Windows graphics in full screen mode. It changes depending on where FS is installed? That makes no sense. FSUIPC doesn't care at all where it is. Are you running FS9 on Vista? That may possibly make a small difference, though Vista treats FS9 as an old program needing special treatment. Please always specify the Version of FSUIPC when asking questions. If you are not using the latest, do try that (3.75), as well as Windowed mode. Regards Pete

Sorry, I do not understand what you are asking. You have a program which is working, but it doesn't? What DLL are you trying to "open up" and what exactly do you mean by "open up"? What is "run32"? Regards Pete

But that's really weird. There's no dependency on hardware built into FSUIPC, and the Key checking code is identical in both the FS9 and FSX versions! And it is okay with the new motherboard you put in? Regards, Pete

Please don't confuse the "EFIS" flight hoop facilities provided by older versions of FS with airliner EFIS control panels. Those offsets you refer to relate to the FS facility for hoops/squares, T's or "yellow brick roads" displayed in the air in the 3D scenery view to guide beginners into the ILS for landing. None of those offsets have been supported since FS2000, if then, and they may have only applied to FS98. I don't really know. The EFIS switch panel to which you refer is a gauge mode thing. There are no in-built FS facilities for that, it is just one part of the panel telling the other what to display. As such there are no assignable FS controls. If you are using an add-on aircraft with sophisticated gauges there may well be specific keypresses you can use, and some may even have known offsets if they use FSUIPC. I use Project Magenta which has its own range of offsets for these things. Failing all of that, if those controls are only operable by mouse, you'd need something like Luciano Napolitano's Key2Mouse program to drive them from keypresses. Regards Pete

Using a registered install of FSUIPC you can re-assign any of the PFC buttons and switches, and even the axes (but in the latter case you have to disable them in the PFC driver too). Just go to the Buttons & Switches option tab in FSUIPC. Operate the Gear lever, then reassign as you wish, to FS controls or to Key presses. Unfortunately the FS parking brake control is a "toggle", meaning there's only one control and it switches on and off alternately. This means you'd need to synchronize the lever to start with. Alternatively you can program the "off" position ("released") to write a zero to the FSUIPC parking brake offset -- Control "Offset word set", Offset xBC8, Parameter 0 -- and the "on" ("pressed") to write 32767 to the same place -- Control "Offset word set", Offset xBC8, Parameter 32767. Then it should be in sync as soon as you use it. Regards Pete

Yes, I've replied by email. Pete

One (or both) of the Keys you are using to register FSUIPC and WideFS is not legitimate. Where did you get them from? If you like, ZIP up the FSUIPC.KEY file (from the FS Modules folder) and send it to me to check. petedowson@btconnect.com. Regards Pete

FSUIPC doesn't do anything surreptitious like that. It is a DLL in FS and it keeps to doing its job, not messing about in your private affairs! You would have to buy a new registration and re-register. The email address is only used as part of your identification, tying that Key irrevocably to you. A street address would have done too -- those are used for folks with no Internet connection. A new email address is unnecessary for registration (as it is never used as such), but you can buy a new key if you wish. ;-) Regards Pete

Yes, I understood that. But I don't think you need to be quite so mean on the amount of data being sent! ;-) You might like to look at "pmRemote" too -- see http://www.projectmagenta.com . It produces web pages containing info, acting as a little web server, so you could use Internet Explorer at work. Regards Pete

Good! Well done. Me too. Not sure where you are looking. Maybe I didn't lead you quite exactly enough. Let me do it whilst I'm typing ... Start - Settings - Control Panel - System - Device Manager. Scroll down to "Universal Serial Bus controller" and, for each "USB Root Hub" you find, in turn, do this: Right click - Properties - Power management. That should show a couple of options. One of these is "Allow the computer to turn off this device to save power". This seems to get checked by default. Uncheck it. Regards Pete

The packets of data are probably going to quite small in any case. Why are you wanting to reduce updates to such an infrequent level in the first place? I can understand you not needing to match the FS frame rates (which is what WideFS tries to do), but a few seconds would be no hardship, surely. I really do think there will be connection problems if you try to make them too infrequent. Regards Pete

Well, it isn't designed to do so. You can experiment if you like, but it may fall foul of internal timeouts. I really don't know. The client has to send "I'm here" messages a lot more often than 300 seconds in order to stop the Server assuming that it has disconnected and closing the link. The timeout is of the order of 30 seconds or so, so I don't think you want to set "pollinterval" less than 20000. The responsetime parameter is in seconds, not milliseconds, so this one should be 300. However, if the Server isn't sending out stuff more often than that the timeout may expire. Generally you need to allow a lot more -- say 450. Are you landing the plane from a WideFS client? Or do you mean you have another client at home with the FMC? You can't change these parameters dynamically. With FSX you can disable WideServer, alter the INI file, then re-enable it, all without closing FSX, but you can't do that with FS9 or earlier. Regards Pete

I suspect these will all be specific to the particular panel. If the authors have not provided keystroke shortcuts to control them, only mouse clicks, then I'm afraid there's no way to drive them from buttons unless you have some sort of mouse driver, like Key2Mouse by Luciano Napolitano. That allows you to make a key press perform mouse positioning and button clicking. Then you can program your buttons to send the selected keystroke. Regards Pete

That's very strange. The values are all kept in the INI file, so unless that is somehow being lost or corrupted I couldn't explain that -- unless possibly the device was coming up with a different joystick number sometimes? I believe that can happen on Wind98 and before, but it was certainly fixed in the USB drivers of the later Win98 and WinXP/Vista. Did you ever notice the joystick number referred to there was different? Another possibility, though one which should right itself, is where power management is being applied to the USB ports. If Windows withdraws power it may upset the device. Check in Control Panel - System - Device Manager. Find the USB Hubs and make sure power management is off on all of them. Very strange. What version of Windows are you using? And please do check those power management settings. Regards Pete

The type is specified in the Programmers guide. It is part of the description. Try using FSInterrogate which will give you real-time updating values to view in an asortment of formats. I'm not surprised -- 65536 * 65536 is one more than the maximum that can be accommodated in a 32 bit unsigned value, let alone signed. You need put the original value into floating point form first THEN do your calculations. Obviously for accurate angles an integral value (in degrees!) in not much use! Pete

Well, that's not so much "too often" as "off the beat". If you are writing comfortably at 25 try limiting FS's frame rate to 25. Really the main enemy you have is FS's own simulation engine trying to do its thing -- every beat you miss it will fill in. You are fighting it all the way. I think the usual way to get things smooth is to defeat the sim engine by putting FS into slew mode, or possibly pause mode. If you only want the views not the gauge readings then either might work better for you. Another alternative is zero sim rate (actually setting the sim rate value to 0). Otherwise you have to beat the Sim Engine into submission by matching the frame rate, and one way to do that is to limit FS's. This also has the good side effect of generally making it more constant, easier to match. There are ways but they involve hacking to hook into the right routines, and they are different in each version of FS. Best these days to use FSX -- then you get official SimConnect support for all this stuff. There are no SDKs for DLLs in FS2004 or earlier. Regards Pete

It isn't whether FSUIPC is fast enough, it's the frame rate you can achieve in FS. FSUIPC cannot feed data into FS faster than its frame rate and to try to do so merely has the opposite effect. There are only two areas of overhead in this interface - first is process switching, if you have the interfacing program running in the same PC. The other is simply the normal Windows message queuing system, which can also of course sometimes defeat they synchronicity. >> My program will be a simple FS DLL that has a second thread reading/writing FS's lat, lon, alt, pitch, bank and heading. << Having it as an FS DLL helps reduce the process switching overhead, and by using the module access method you avoid the message queuing problems, mostly, too. But take care not to introduce stutters in FS by using its processing slot too much. Your "second thread" should be the main thread -- i.e. the same one as FSUIPC and most of FS is running in, otherwise you won't be able to lock into the frame rate and there may well be other problems if you manage to make FSUIPC try to use non-re-entrant parts of FS from the wrong thread whilst they are being executed from the main one. Make the UDP part the separate thread. Regards Pete

I replied to your post about this in the AVSIM Simconnect forum, as follows: Yes, but only a small subset of facilities are available. Should be okay. Try it. The "official" interface for FS98 was actually FS6IPC. I developed FSUIPC for FS2000 and made it work in its basic form (as an interface to FS variables) in FS98 just to make sure I had the same things -- i.e. that it was compatible. So, if you have trouble with the later, much more developed FSUIPC versions, see if you can find FS6IPC. (The interface is the same). Regards Pete

You surely mean control the elevator and ailerons? A yoke is an input device such as the one you are trying to interface. Instead of thinking "affect the yoke" think "affect the aircraft controls". A yoke controls two sets of surfaces on an aircraft -- elevator and ailerons. FS's controls for these are called, respectively, AXIS_ELEVATOR_SET and AXIS_AILERONS_SET. You can send values for these using SimConnect's "SimConnect_TransmitClientEvent" after assigning an ID to these Sim Events by using "SimConnect_MapClientEventToSimEvent". The associated parameter values for these vary from -16383 to +16383, with zero being straight and level. Regards Pete

Probably your potentiometer output is not identical to his. These things do vary. This is why calibration is needed. Just using the same values in your INI as your friend is not going to work if different values are arriving from the throttle. I bet if you borrowed his throttle and used that it would work on your PC too. Yes, because you assigned it to the steering tiller. Pete

When the engines are in "IDLE" at 48%, how do you know they are in IDLE? It doesn't seem likely -- surely 48% is too high? On Boeing aircraft the only way you know its "idle" is by (a) the throttle lever is in the idle position and (b) the N1% is low, like in the 20's, or at least decreasing towards that sort of value. In your case, where is the throttle lever? Or don't you see one, just a set of switches? If the throttle lever is not at its idle position then you need to calibrate it to move it there. For a normal axis-based analogue throttle the OUT value from FSUIPC's calibration would be 0 (zero) for that idle position. It sounds like yours is not. I did notice that in your [Axes] section, shown earlier, you had no assignment to the throttle axis in FSX, only to those Numpad+ and Numpad- keypresses. I don't know how you control the throttle correctly with those alone I'm afraid, but evidently they are not enough to get you to Idle correctly. The reason you cannot engage reverse is the same -- you have to reduce the throttle to idle first. Maybe all the problems are nothing to do with your calibrations, but an error in the flight model you are using. Is it an add-on aircraft? Does your friend in Berlin also have an idle of 48% and no reverse? If not, maybe he can help you solve this problem? The 0 line won't have changed anything. That merely sets the default increment on the throttle axis. The 9 line was this: 9=0R,256,D,36,0,0,0 which appears to be assigning your Rudder axis to the Steering Tiller. If you have no other axis assigned for the rudder, then you won't have a rudder, only a steering tiller which only works at low speeds whilst on the ground. The steering tiller won't work unless you go into the FSUIPC calibrations and calibrate it. You need an extra axis for a steering tiller, otherwise you have to use the rudder for both, as in FS default settings. Regards Pete

Isn't IOCP a hardware interface, for buttons and so on? If this "OGS" is written to talk to FS only via FSUIPC then there won't be a way to change it via any "protocol" parameter. There are only really two possibilities I can think of 1. With FSUIPC also installed on the second PC, in FS, will it supply your OGS with the information it needs? This really depends on whether WideView is transferring enough information to drive the gauges correctly -- you can check that by looking at the FS gauges on the 2nd PC. 2. Add another Monitor screen to the main PC and run your OGS program on the 1st PC instead. That's not a sensible question I'm afraid, as WidevieW does not offer an external program interface. Certainly, however, the author of the "OGS" program (which I've never heard of, by the way) could offer a parameter to allow you to change the FS class it uses to interface to FSUIPC -- it will be using "FS98MAIN" or "UIPCMAIN" at present. If it was changed to "FS98MAIN01", then it would interface to a Wideclient running with the parameter "ClassInstance=1" in its INI file (the Technical document in the WideFS package explains this). I've not tried it, but I thought FSX had its own multi-PC interface built-in, as part of its "multiplayer" facility. Surely the facilities used to allow the same aircraft to be piloted and co-piloted on two separate PCs would also show the correct gauges and so on on both PCs. All you'd need to do is run FSUIPC on the 2nd PC and use your OGS program there whilst showing the scenery view instead of the cockpit view in FSX. Maybe this doesn't work so well as WidevieW, I don't know -- are there known advantages to using WidevieW over the default FSX facilities? Regards Pete

Well I'm sure that is not true. Others have done so. I would have hoped someone here might have been able to help. But have you asked in other Forums -- for instance the cockpit builders forum? Or a Forum for the Airbus models? Regards Pete

I assume you really meant you delted the INI file, which would have contained your previous settings. Re-installing an unchanged program won't fix anything by itself. It's just one little DLL. You want it sensitive enough to reach the extremes but slower and smoother near the centre. When you've calibrated in FSUIPC, select Slopes and change the response to one with a flattened mid section. Pete

Okaythere's nothing wrong with that. Oh, bad ram can result in all sorts of odd crashes, but it is quite rare these days. I wouldn't have thought of that. Regards Pete