Pete Dowson

I don't understand where you can "load FS9" here -- if it isn't running already you can't use FSUIPC. What is it you actually mean? 12 fps seems extremely low in the first place. Is that the sort of frame rate you normally get? I cannot imagine what is happening with this time discrepancy to cause FS to slow down, but you could try sending it the Scenery Reload control via the FSUIPC interface too. Maybe that would do the same as "OKAYing" in the Time menu. If you are going to go into the time menu in any case, why not change the time there? Or am I missing something here? But that is a temporary affair. Of course there will be a frame rate drop whilst it is changing the textures, the shadows and so on. (You can reduce this somewhat by turning shadows off). I thought you were implying that there was a permanent drop? If there is, how do you explain that, other than your different time textures are more massive or cause some extra graphics workload? I must admit I am finding all this rather mystifying. Regards, Pete

The test version only modifies the way in which buttons are polled. The symptom of the problem is an actual FS crash, not "unreliable" results with any specific types of buttons. I've identified the problem as being due to calling certain FS facilities from a different thread. The fix is to post messages to the main thread and call them from there. This fix will be included in the next release, probably this coming weekend. Meanwhile the work-around is to simply put "PollInterval=66" into the main [buttons] section in FSUIPC.INI. This will slow button polling down a little. But from what you say it isn't related to the symptoms you are experiencing. Regards, Pete

No. It doesn't matter then. Sorry, I thought I had sent you an email asking for a test with "PollInterval=66" set. That makes FSUIPC 3.212 revert as far as button handling is concerned to the slower poll. Regards, Pete

That seems very unlikely. I think you are maybe confusing the 64 bit FIXED point numbers in FS -- like Latitude and Longitude -- with 64-bit FLOATING point numbers. There are completely different formats. 64 bit floats are the standard type of floating point in Intel processors and as far as I know are supported in all languages. There's also a 32-bit float (in C called "float" rather than "double"). FS SDKs use the terms FLOAT64 and FLOAT32 for clarity. There are problems with handling 64-bit FIXED point numbers in most languages unless they support "long long" or "__int64" like most recent C compilers. This format is not a native Intel format on its 32-bit processors, but presumably will be on the 64-bit ones, hence the addition to compilers with backward compatibility. The latter is the reason there is an extensive explanation of a possible way of handling the Latitude and Longitude in the Programmer's Guide, but not in any of the double floating point cases -- no further explanation should be needed for the latter as it is a universally supported format. Regards, Pete

FSUIPC is an interface to FS. I can provide most things that FS provides, if I can find them, but FS does not simulate anywhere near enough for a 737NG overhead. This is what keeps the third party add-on folks busy -- it's a lot of work simulating all the subsystems and details Microsoft left out. They are not simulated in FS. You have to write them yourself. This is what PMDG and other such panels are mostly about. They are not simply re-working FS's own efforts, they are adding to them. If you want an implementation you can configure and program to suit external hardware you could investigate Project Magenta -- Enrico is busy now with an accessory product called "pmSystems" which will enable all this stuff to be done. Regards, Pete

400 mSecs!? Good grief! What's this running on, a Pentium 1GHz? Assuming the PC is fast enough to run FS2004, try limiting the latter's frame rate so it shares the processor a little more. Either that or make sure you use a Pentium 4 3GHz or better with hyperthreading enabled. Regards, Pete

So what is "InMiles", as defined by: Dim lnMiles As Double ? If "Double" in VB isn't the same as a "double" in C, what on Earth is it? Sorry, I don't know VB, but perhaps you have some reference book you can look it up in? Seems essential to have some reference when using any language. Regards, Pete

Current supported version is 6.221. You seem to be rather out of date in any case? Regards, Pete

Yes, it works fine here. Though I spell it "ClassInstance". Not sure if Windows is case insensitive for Profiles or not. The parameter needs to go int the [Config] section of the WideClient.ini file. There's never been any change to this since I added it, whenever. Regards, Pete

There are rather more that 1.8 metres in a nautical mile! Try dividing by 1852. Why is the destination for the result declared as "currency"? Surely you want that to be a double float too? Pete

When you change the time, and especially the date, FS will load new textures and so on and this may affect frame rates. If you change the data back to where it was before do the frame rates revert? FSUIPC isn't doing anything when you are not calling FSUIPC_Process, and in fact when you do in the above case it is only writing those three locations. There's no magic or other activity started up. It has to be something to do with the change in time or date. Try a process of elimination -- choose somewhere else to write to, then add one only of each of the writes above in turn. The one which I would be most suspicious of is the change of date, as there are quite a few programs which can change the time without a problem (eg FSRealTime). Regards, Pete

I am working on this still. But can you tell me how the CRS button is programmed in FSUIPC please? You can use the test version I sent with "Pollinterval=66" added to the [buttons] section (the main one, not an aircraft-specific one), and it will revert to polling in the same way as 3.201. That will tide you over till I fix it. I'll probably send another test version later todaybut for testing please remove (comment out by putting a ; in front) the "PollInterval" parameter. Thanks! Pete

Okay, that's great. Thanks for letting me know. I'll add these notes to the list in WideFS.doc! Regards, Pete

Good catch! There appear to be two identical controls on that display and the second (unused) one is overlaying the first one. Your option is actually checked (you should see "CloudIcing" set to Yes in the INI), but it is being overlaid with a box which cannot be checked. Sorry about that. It'll be fixed in the next version, maybe at the end of this week. Regards, Pete

As far as I know the VSI value is the VSI value which is the VSI value. It is used, for instance, in Project Magenta and seems to give admirable results, without any filtering that I know of, in cockpits using said software. Why would you think there's another? Maybe you are looking for a non-instantaneous indicator (airliners use IVSI, as do many GA aircraft as far as I know). Maybe that, in those aircraft which have such a damped and delayed effect, are down to coding in the gauges themselves? Having said that there is another value at 0842, but as far as I know (and I haven't tested this) it should agree with the 02C8 value when converted to the same units. Of course, there are also the more technical values later (30A0, 3188, 31A0) and also, for FS2004 only, the GPS read-out at 6078 (I think). Enough choices to consider, I think? :wink: Regards, Pete

Possibly. It has only been discovered today, and seems to be related to the use of a separate thread for button processing in the latest version. I am sending an interim test version (3.217) for you to try. Regards, Pete

Yes, you are completely correct. I'm afraid the only overall answer, short of writing to FSUIPC offsets to control these things, is to get your switches synchronised with their state in FS at the start (load) of an FS flight. There is no other way. If you want to be adventurous, you could investigate using the facilities in FSUIPC to write values and set or clear bits in specific FSUIPC offsets. There are special controls in the drop-down list for these. They are documented in the Advanced User's Guide to some extent, but to know the offsets and what they do you'd need also the Programmer's Guide from the FSUIPC SDK (see http://www.schiratti.com/dowson). Not without writing a program. But most things are controllable with specific 'on' or 'off' actions via the offsets. Almost everything is possible, but some things are more complicated than others. Yes, but the controls you mention are all the controls that FS itself offers. FSUIPC has expanded on this list, but I am not going to expand it forever. The things you want are possible, it just takes a little more effort. Okay? No, I'd do the same for any one. But many congratulations, in any case, and welcome. I hope it all works out for you all! Regards, Pete

No, 32 buttons. There are 8 extra "buttons" which are derived from 8 cardinal directions of a hat -- this is following an old convention in FS to number the 8 driections 33-40 (32-39 counting from 0). The restiction is not FSUIPC's, but the Joystick API it uses. That only provides one 32-bit value to indicate button settings. DirectInput (used in FS since FS2002) allows up to 64 buttons per joystick as far as I know. A device providing 256 buttons won't be usable in that way on FS or FSUIPC. In fact I don't see how it could be used unless either they split it into 4 or 8 "virtual" joysticks, or only allow it to be programmed by their own drivers. Please read the discussion on this exact question in the FSUIPC User Guide. Regards, Pete

I've found a problem with button operations which is to do with a recent change to use a separate thread for button scans, to speed things up a little. I don't know how it affects PMDG -- so far the only bad result I know of is the operation of the extra "Traffic Density" controls offered in FSUIPC. However, I'll send a test version to you (3.217). Let me know if this fixes things. Regards, Pete

Okay, so you mean FS is crashing when you use the dials. Now, what about the other questions? Are you programming those dials in the GofLight driver, or in FSUIPC? If in FSUIPC, are you programming them with keystrokes? If so, what keystrokes and do they work when using the Keyboard instead of the dials? You see, some sort of process if identification and elimination is needed even before anyone can start looking. If you are doing this with FSUIPC I also need to know the precise FSUIPC version number, please. When you uninstalled did it remove the DLL(s) it installs into the FS Modules folder? The active component may be there. Are those there now dated for the 800/900 release? Regards, Pete

No problem, don't worry about it! Good flying, Pete

I have EPIC buttons here which work okay, but on a USBEPIC. FSUIPC only recognises the change from the button state being zero (off) and non-zero (on). For normal buttons this should be okay. I see you are using "BtnToggle" for the Enque action. Why? Please read my Epic documentation. For "BtnToggle" it reads: which explains EXACTLY what you are seeing. Please consider how you want to use your buttons and select the more appropriate action. Just a simple BtnPulse might be okay for this sort of use, but if you want to be able to hold it pressed for repeat actions you program the On and Off for press and release separately. That doesn't access the buttons through the VXD at all. You should check things with my own utility, IsEpic or something like that. (Sorry, I've not used an ISA EPIC for many years -- I have no computers left with ISA slots!). Also check the buttons with the Windows Game Controller. Regards, Pete

Can you explain by what you mean "not exiting FS9"? Are you configuring some Keystrokes in FSUIPC for the new PMDG aircraft which do this? Or is this something special in the GoFlight drivers for PMDG? If you are configuring keystrokes in FSUIPC, do those same keystrokes work on the Keyboard? If not then it is obviously a case for PMDG support. Regards, Pete

There are two ways that I know to link two or more copies of FS -- one is FS's own multiplayer, the other is WidevieW (not WideFS, note -- WidevieW is by Luciano Napolitano -- see http://www.wideview.it). Regards, Pete

I think you would have to read the AI aircraft data (supplied for use in TCAS gauges and the like) and somehow work out where the turbulence areas would be, second by second. Obviously you'd disregard light aircraft and maybe even only concentrate on the bigger jets. Then, when the user aircraft passed through an area you had worked out as turbulent (bearing in mind that this will be moving with the air mass, so you need to adjust for wind speed), you could try to impose turbulence on the aircraft -- maybe through control interference, or maybe trying to write to some or the assorted accelerations and velocities (those used for aircraft carrier catapults and tail hook operations). I'm sure it could be done somehow, but it would take someone far more knowledgeable in spherical trigonometry and fluid dynamics than I, and it sounds like a lot of work, indeed, much of it experimenting to see what might work. Oh -- a fast machine would help too, once the computations get complicated! Regards, Pete