Pete Dowson

Ah .... I must make a note of that, this time! In fact I'll put it into my FS9.CFG right now! Thanks Eric! Pete

Hmm. I can't claim the credit for much if any of that I'm afraid. The changes in serial port handling I mentioned were really only a matter of poll timing adjustments. Most of the other changes in this version are for the new PFC 737NG cockpit, which is why it isn't released yet, still under test! :wink: Maybe the USB to Serial adapter came with a better driver? I seem to recall that I had a driver once which would stop working after a while, same as you first reported -- they all appear to be FTDI made, I think, but the one which came with my first adapter was well out of date. Regards, Pete

Sorry, yes, the package's full name is "Visual Studio .Net 2003", but I only use the native code C compiler and debugger in it (oh, the IDE too). I don't think anything I use can be classed ".Net" at all. It was horrendously expensive considering how little of it I actually use, but it appears MS offer no cheaper choices for commercial applications these days. I couldn't afford it till the income from FSUIPC and wideFS registrations started coming. But in the end it was worth it. It is far better than MSVC/C++ 7 (at least I think it was 7 -- may have been 6) which I was using before. The code produced by the compiler is unrecognisably better! And the deugger is superb too. Regards, Pete

I think there are two ways to get rid of the assorted red messages on screen. One is by a patched version of one of the main FS DLLs, basically erasing the messages by replacing them with zeroes, but I think the other is just a parameter you can put into the FS9.CFG file. I'm afraid that's all I actually know (I know there's a parameter but I cannot recall what it is). You might find it by checking the FS2004 FAQ, via the main page of this Forums site. Otherwise, ask in the FS2004 Forum. Someone there is bound to know. Regards, Pete

It works fine, either with no FSUIPC registration and the Squawkbox freeware key entered, or with a working, legitimate FSUIPC user key. The change after 3.40 was a tightening up of the checks on keys in order to work against counterfeits which were being used. There is a problem also with time-limited keys, but very few of those have been issued. If your is a time-limited (demo) key, try the test version 6.466 of FSUIPC available at the top of this forum. It sounds like there is something wrong with your FSUIPC key. If you believe it to be a proper, legal, paid for key please Zip up your FSUIPC.KEY file and send it to me for checking. Send it to petedowson@btconnect.com. Please also include an FSUIPC Log file showing an attempt to use SB or whatever, but make sure you close FS first so it is a complete Log. Regards, Pete

I use Microsoft C/C++ -- actually part of Visual Studio 2003 now, which includes VB and Java and C# and all sorts of other stuff I don't use. I upgraded at great expense from MSVC 6 because the optimisation the compiler now does is so much better, and the debugger is extraordinarily good -- so much so that I only very rarely now have to resort to Soft-Ice. I changed to MSC years ago, in FS4 or FS5 time, because it was so difficult interfacing to MS programs with other folks' compilers. There seemed to be so many arcane rituals to go through. Before MS I used Topspeed then Watcom, both of which produced pretty good code for their time. MS only really overtook them for good object code recently. Before C was invented I used BCPL and before that Assembly Code, since 1963. :wink: I have dabbled in Apple II Pascal, old mainframe Fortran and APL, but not enough to remember much of any. Regards, Pete

I hope you get a useful answer, but from what I know about gauges I really think you are most unlikely to be able to get VB created DLLs to interface correctly to FS's innards. Maybe I'm wrong. Let's hope so. I wouldn't know where to begin with VB -- it's messy and complicated enough in C. Certainly not a good way to start with a new programming language. Regards, Pete

You are not actually writing a program for this, I assume? The SDK is really for programmers. There's no easy way to send strings to the display locations. The FSUIPC button and key INI file facilities do allow values as large as 32-bit (4 byte) numbers to be written to specific offsets, but strings require one byte for each character plus a zero byte at the end, and the control value of 16-bits too. This would mean, on your case, and taking "RIGHT" as an example, writing "RIGH" to 3380 as a DWORD, then "T" and a zero to 3384 as a WORD, then the control value as a WORD to 32FA. So, three defined actions for the same button. FSUIPC's parameters don't take strings as such, so you will have to convert the characters to hexadecimal (use an ASCII look up table), not forgetting to reverse the oder (Intel processors use Lo-Hi ordering, so the highest byte value in a 4-byte DWORD comes first). To take an easier example, the hex for "ABCD" would be x44434241. 44 is D, 43 is C, 42 is B, 41 is A. Regards, Pete

It's an unregistered gauge which is also unregistrable I'm afraid. It is using the external application program interface to FSUIPC, which is incorrect and can cause problems (especially if you get two or more of them) when used internally to FS. The special internal interface has been available in FSUIPC now for about five years, so the culprit must either be a very old (possible pre-FS2000 originally) gauge, or one written incorrectly despite the provision of an internal library. There are two alternatives: either locate the rogue gauge and remove it from the aircraft, or register FSUIPC as a user. The former would have to be by a process of elimination as, with the way it accesses FSUIPC, there's no other way of telling which it is. The latter will allow it to run okay provided there are no other such gauges or modules doing it this way at the same time. Regards, Pete

It does sound like power management. Are the PFC controls connected direct to a PC COM port, or to USB via an adapter? I found the latter to be much more reliable -- Windows support for "obsolete" ports like COM and LPT seems to be deteriorating -- but you do need to make sure power management is turned off. I have made some improvements in the serial port handling in PFC.DLL, but there are also large changes for other things and I've not yet finished those nor documentated them. However, you may like to try the attached version 1.912 to see if it helps. Regards, Pete PFCDLL1912test.zip

I have a small list of additional facilities folks have asked for, but the main change since the last User release is support for the PFC 737NG cockpit -- the overhead, extra console switches, stick shaker, motorised trim wheels, and so on. Plus a connection check to satisfy FAA requirements for training devices. It's been a lot of work and very difficult without access to the hardware here for testing as I develop. I am hoping that will be rectified in a few weeks or so then I can test it all properly and make a new release. Regards, Pete

It may be easy, in the Windows start-up folder. Or it may be started as a Service in XP -- you have to find it then in Control Panel - Admin Tools - Component Services (I think). You should be able to stop it there. Regards, Pete

So the DF737 hasn't been updated to work with an unregistered FSUIPC 3. You'd need to have FSUIPC 3 user-registered (i.e. paid for) in that case. You only need change the DLL. Ah. In that case it will be because nothing provided a Key to be saved. No accreditation was needed before 3.00. FSUIPC was free even for commercial aircraft back then. You will need to purchase FSUIPC in that case. Or use a freeware aircraft or one which has paid for its access to FSUIPC. Regards Pete

It isn't a problem with the devices, but one of the bits of software the installer puts into your system. According to others, once they stopped that running things on their system improved. I'll see if I can find the references, hang on ... ... Yes. See these threads (you may need to skim down a bit): http://forums.simflight.com/viewtopic.php?t=33942 http://forums.simflight.com/viewtopic.php?t=31582 In some cases the effect is more drastic, but one of the symptoms is definitely a slow down. And the mouse still works fine without the culprit process, apparently. The "regular" mice these days are optical, no ball, and I've yet to find any maintenance needed. Except, of course, the wireless undocked ones need new batteries now and then! Regards, Pete

Is the actual name of the FS control "View reset"? There's isn't one named the other way round. If it is "View Reset" you are talking about, yes, that is true. It seems to have lost its function in FS9. Using what? FSUIPC or FS assignments? The "View Reset" control certainly doesn't work here no matter where or how I assign it. Wherever it may be assigned, it is still the same control and the action would still be simply to send the View Reset control to FS. The default use of the spacebar in FS (without the shift) is an "eyepoint reset" which sets the eyepoint back after it's been raised, lowered or twisted. But that doesn't restore forward view nor restore a default Zoom level. In FS2002 and before the View Reset control did work, and operated on view direction and zoom level. It was, by default, assigned to the space bar in FS2002, and would work through PFC.DLL or FSUIPC.DLL or any other way. It even appeared in the FS Assignments List. I don't know whether MS removed it deliberately or just broke it accidentally, but it no longer appears in their assignments list and, as I say, the space bar is by default now an Eyepoint Reset, which doesn't do the same thing. All I can suggest is to program the button in FSUIPC to give View Forward, then edit the FSUIPC.INI file to add another line to make it also send a Zoom 1x control. maybe another line for an Eyepoint Reset too, for good measure. Regards, Pete

There's no different treatment by FSUIPC or WideFS for some parameters compared with others. It makes no distinction at all. It's all just data in offsets. This sounds like something in the ECAM software. Are you saying all the othr programs get correctly updating data, but that one program does not? Maybe it is stalling or waiting on something specific which is not changing? Try with nothing else running on that client. Try the ECAM on the FS PC. Can you ask PM Support to take a look? Certainly if that one program isn't updating but all the others are, it is something specific to the program, not to the data in WideFS or FSUIPC, as the latter cannot distinguish one thing from another, it is just data. If you know exactly what 'parameters' you are talking about you could download the FSUIPC SDK and use the program FSInterrogate to look at the values arriving at the client. Alternatively you can use the Monitor facilities in Wideclient.ini (see the WideFS document) to monitor just the engine parameters. I'm not sure which ones it is expecting, but look in the FSUIPC offsets list (in the SDK's Programmer's Guide, and also on PM's documentation site). For instance, for Engine 1 monitoring 088C,152 would cover all the main values. Regards, Pete

Looks like no one is able to help you with this, me included I'm afraid. I've been wanting to get into the ATC interaction for some time, mainly so that (a) it can be made programmable and (b) the window and its messages and repsonses could be handled elsewhere. But, no joy I'm afraid. Regards, Pete

2.974 is not only several years old, but it wasn't even the last version supported for FS2002! What are "mutitasking issues reported with pre 3.4x FSUIPC." I'm afraid I don't understand what that is about at all. How is your panel dealing with course selection? FSUIPC has nothing to do with that part of FS, it is left to FS and your gauges. Surely you do not use FSUIPC to access this? Missing from what? No .KEY file is supplied with FSUIPC. Like the INI and LOG files it is generated when FSUIPC runs, and FSUIPC runs if it is installed correctly in the FS Modules folder. It sounds to me like either the user does not know how to use Windows Explorer to see files, or has not actually installed FSUIPC yet. What issue? Surely you are not using FSUIPC for anything to do with course? What do you use FSUIPC for? It seems quite clear that you have a gauge (DF734NJ6.GAU) which attempting to use FSUIPC but which is not accredited to use it. I have no record of a key ever being issued for this gauge. The gauge appears to be reading part of the AI TCAS tables, so presumably it wants to populate a TCAS radar or ND. Again, this really has nothing to do with course selection. Regards, Pete

All my software is available in the same place it's always been, http://www.schiratti.com/dowson. There are also Beta updates and other things attached to the announcements at the top of this forum. Regards, Pete

Try removing the FSNav.DLL, see if that helps. Maybe it's an old version? I understand there were problems with the original FS2004 version. If you have the latest versions of both, then, I'm sorry, but there's something horribly wrong with either your FS installation or the system it's running in for such drastic effects to manifest themselves. I've really not heard of anything quite like the symptoms you describe before. Maybe it is down to something else running in the background. You wouldn't be running something like a Kensington mouse or similar, perhaps? Some horrible things have been reported with that. Either way, check all the other processes running and see if there are some you could do without. A process of elimination may show the culprit. Regards, Pete

The rudder control input at 0BBA does work. It is the main control for the rudder. Are you sure you don't have some joystick axis input interfering? You can disconnect the joystick rudder via bit 2 in 310A. The other possibility is that you have auto-coordination set (auto-rudder in the menus). With that setting the aileron control also operates steering. You can control the auto-coordination option via offset 0278. Use FSUIPC's IPC logging to check what your code is actually doing, and try things out in FSInterrogate. Regards, Pete

No. There should be no measurable frame rate difference with FSUIPC, unless something is using it. Then it depends upon the performance of whatever is using it. What else have you got installed in FS? There's something else in there which does nothing if FSUIPC isn't there. Assuming you have left the FSUIPC options pretty much all on their default settings then it really isn't doing anything except waiting for something to use it. Regards, Pete

Does it? Do you know, I've never noticed that. Does it say where this description applies to? When you download weather is gets it for a great many weather stations and they'll all have their own weather. Maybe your airport is not actually at one of the weather stations and it is only reporting weather for the nearest one to you? The weather is interpolated between weather stations. Alternatively, pehaps you are getting the weather reported at the place where your aircraft is, but the clouds you see are over so many miles away (I think the distance is something like 5 miles -- if there's no clouds above you, nor within a certain range, then it is clear). Try looking straight up, see if you see any clouds. If you are in one of those areas like New York or Los Angeles where there are a load of weather stations quite close to each other, the weather can be quite different in FS not so far away, especially if each station reports at different times or intervals. Try placing yourself in some place far away from many other airports and see if you get the same. If you have my FSUIPC package you will find a utility program inside called WeatherSet2. You can run that to tell you the weather at the aircraft and at any selected airport or location. Currently I use ActiveSky 2004.5 most of the time. I used to use FSMeteo, and still do occasionally. Regards, Pete

I wouldn't have thought so. If you've tried them and they do nothing they were probably added as part of some good intention which never amounted to anything. There are many like that I think, as well as some left-overs from older FS versions which don't work. Regards, Pete