Pete Dowson

Are you seeing the Goflight buttons in FSUIPC's "Buttons" option page? If not then check what versions of WideFS and FSUIPC you are using, and that you have installed the GoFlight driver on the WideClient PC. There are all sorts of ways of doing this for Boeing amd airbus cockpits, but I don't know if they are applicable to PM's RJ also. This is a question for the PM support team, I think. You could try the PM Newsgroup -- there's a lot of experienced folks there. Not sure what you mean by that -- the PM controls through FSUIPC won't normally be by a key press. You need to clarify all this with PM please. Sorry, I don't really understand this statement. Pretty much everything that can be done with PM modules can be done through its FSUIPC interface. Those commands which are not explicitly listed in FSUIPC's drop-down are available through the assorted controls by parameter functions I added. It isn't WideFS which controls anything. You program the buttons in FSUIPC. The first step is to find out why you don't see the GoFlight buttons in FSUIPC. After you get that working (and it can only be a matter of wrong versions or missing GoFlight driver), then you assign the appropriate PM controls in FSUIPC's drop-down list. Which those are for the RJ cockpit I'm not sure. I would think they share the Boeng/Airbus controls for those which they have in common, but this is something to check with PM. Regards, Pete

The SDK contains examples of VB usage is the ZIP called "UIPC_SDK_VisualBasic.zip". There are also extras for the VB.NET programmers in another ZIP, also in the SDK. I am not familiar with VB at all, but looking at the files in the VB ZIP it certainly looks as if you should have enough there. The main example source file appears to be "General.bas". I'm not sure what all the other files are for, but I'm sure that as an experienced VB programmer already you should recognise them. Regards, Pete

This is a problem with the most recent versions and is corrected in the next version, 3.22, which will be released this weekend, I hope. The work-around for the time being is to add the line PollInterval=66 to the main [buttons] section in the FSUIPC.INI file before loading FS. This will slow down button polling a little (but not much compared to earlier versions). Just remember to remove the line when you get version 3.22 or later. Regards, Pete

That's a bit extreme isn't it? It doesn't destroy files, and Microsoft published a tool plus instructions on how to remove it and keep it away. Look at these (thanks to Katy Pluta): KB Article: http://support.microsoft.com/?kbid=841720 Download Location: http://www.microsoft.com/downloads/details.aspx?familyid=76c6de7e-1b6b-4fc3-90d4-9fa42d14cc17&displaylang=en Online version of this tool in the form of an ActiveX control here: http://www.microsoft.com/security/incident/sasser.asp You always need to keep a note of all those outside of the PC -- you never know when disaster will strike. If it isn't a virus, it could be a disk crash. Sorry, I don't keep a database nor do I issue the keys. I do the programming and the technical support. The sales and registrations are all done by the suppliers. If you bought it from SimMarket, simply go to http://www.simmarket.com, open your account there, and retrieve your key. I've been told it is quite easy to do. Regards, Pete

Two points there: 1. You can set an option in FS to use the system time instead of the Flight time. Have you tried using that? 2. In any case, it would surely be more effective to write the time you want it to load with into the default FLT file? Ah .. this is what you meant by "load FS" -- the reloading of the textures? This is not an FS reload as such. It has to reload the textures because they change according to time. No, you have to change both local and zulu time, not just one or the other. Maybe you are not getting them in correct synchronisation? Regards, Pete

Yes, that's the whole point really. Whatever language you are using, it is best to read the variables into the correct types to start with. I've searched for info on VB and for floating point there are types "Double", "Single" and "Decimal" in VB6. I don't know what "Decimal" is but I'd be amazed if Double isn't the same as C's double or FLOAT64, and "Single" C's float (FLOAT32), The only ones that may give problems in VB are the 64 bit fixed point numbers and, for some weird reason completely unfathomable to me, strings! (VB seems to have the worst most incompatible string system that could be invented, judging by the number of questions and problems this area causes). However, from the same source which gave me "Double", "Single" and "Decimal" for VB6 (the book "Visual Studio.NET for Dummies"), it seems that VB6 also supports "Long" for 64-bit FIXED point numbers (!), and Short for 16-bit numbers, as well as the common Integer for 32-bit. Otherwise, for the 4-, 2- and 1- byte values you can of course read them into a standard 32-bit Integer, but that must be initialised to zero first so that the unused bytes of the 4 are clear and don't give a false value -- some support queries have arisen from this being forgetten too. Regards, Pete

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