Pete Dowson

I cannot support such old versions, sorry. Please see some of the announcements at the top of this Forum. Current versions are FSUIPC 3.45 and WideFS 6.45. Far too much has changed since the very old versions you are using. I cannot work out anything from small extracts from log files. Please make sure you are using supported versions, and if you still have problems show me the log, not a distorted line like this. Thanks, Regards, Pete

Yes. As it says in the documentation, both FSUIPC and WideFS have to be registered with the same personal details. The old details really should have been mentioned to SimMarket at the time. However, all is not lost. If you send both your FSUIPC emailed Key notification and your WideFS one too, to me at petedowson@btconnect.com, I will make you a new Key for one or the other. Just decide which details you want and I'll re-do the other. If you opt to change you FSUIPC Key you will then need to delete the FSUIPC.KEY file from your FS Modules folder and then re-register both. Regards Pete

Here's a version (1.913) with the connection checking unlocked. You will still get them if one of these conditions is true: 1. No COM port specified or it cannot be opened (e.g. something else is using it) 2. The version of FSUIPC installed is earlier than 3.45 3. You have selected the 737NG cockpit as your 'console'. Good flying! Pete PFCDLL1913test.zip

Well, that was not a recent version at all, but several versions ago -- dating back nearly six months! The main change just after that was the tightening up of user key registration, because of a number of counterfeits being made. So far ALL cases like the one you report have been related to bad user keys. To test that, remove the FSUIPC.KEY file from the FS Modules folder, then load FS and re-register the freeware programs via the "register an application" button. If that fixes it, Zip your original FSUIPC.KEY file and send it to me at petedowson@btconnect.com. I need to see why it doesn't like your keys. If not, I still need to see the logs. There is certainly no rush to fix anything in 3.45 if it has been this way, for you, since after 3.40. After all, 3.40 was only a supported release for about a week and no others have reported problems with these specific modules in the months between. Regards, Pete

Yes, they should do. But I did lock them for some tests. Maybe I forgot to release that lock, I'll check that. Thanks. Regards, Pete

Can you be more specific, please? How are you trying to turn them off, and what console are you telling PFC.DLL you are using (I don't mean what you are actually using, just what you've told it). There's nothing turning any brakes on or off in any of the checking code. It merely checks inputs, there's not one output call in the whole thing. It sounds like you have so button operating that. Please clarify. Well, I'm not sure. But I've found USB serial port adapters, providing you get a recent driver which doesn't stall like my first one used to, more reliable and generally faster (more "responsive", rather). After all, although the simulated serial port they provide is limited to the set speed, the USB channel itself is much faster. It also is not reliant on the sort of interrupt handling that the real COM ports are -- I tend to think the IRQ handling side of the serial port drivers is one of the problem areas. On top of that MS and the hardware folks have been concentrating on USB (and firewire) as the connecting method of today and the future, whilst the poor old COM and LPT ports are left to fend for themselves, poorly. Regards, Pete

Really? There's been no change in that checking. Have you tried the test version of FSUIPC available through the announcements above? What previous versions please? Be specific. If your last "previous version" was 3.40 then a lot has changed. If it was 3.44 then little to nothing has in this area. It is quite significant, therefore. I can do nothing whatsoever at all without information. Show me the log. Providing you have no logging options you should be able to show the details here. It would have been better to do so straight away than go though the boring part of me saying I don't know because there's no information, don't you think? :wink: Regards Pete

You would certainly have to edit the INI file. Multiple actions on a single button are not possible via the options window. As I said, the system is not designed for passing strings at all, only 8, 16 or 32 bit numbers. That's why you have to convert your strings to look like numbers. After writing the string to 3380 you have to send the command to 32FA, as described in the Programmers Guide. That's another 16-bit value on the same button, but it must be last (higher numbered line). FSUIPC doesn't "update AdvDisplay". Messages are sent to Flight Sim. If AdvDisplay is running it intercepts them. If it isn't they display on the screen in the translucent green window over the top. All that is in the Advanced User's manual, the definitions of all of the FSUIPC-added controls are listed there. Regards, Pete

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