Pete Dowson

Actually, it does not need registration to run PFC. When you say "latest", the PFC website is usually well behing the Schiratti site. Can you check the VERSION numbers against those details in the "supported versions" announcements at the top of this forum, please. Sounds very strange. I've not heard of anything like that before. The PFC driver is hardly changed for FS2004. Is everything okay with just FSUIPC installed, no PFC.DLL? If you had all the PFC stuff working well in FS2002, why not just copy over your FSUIPC.INI and PFC.INI files to the FS2004 Modules folder. This will ensure everything is configured the same -- you really don't want to go re-calibrating all the PFC stuff again if you had it right. Sounds good -- though I have heard of folks complaining about stutters with the Radeon drivers. The 9800 gives better frame rates than the nVidia cards, but isn't as smooth, apparently. Certainly I would have hoped a P4 3.0 with that card and that much memory to give better than 20 fps. Have you got a frame rate limit set (in Options-Settings-Display-Hardware). If not, try setting one a little lower that the fps you are seeing, if you have, try adjusting it. The fact that you seem to be saying that the frame rate drop was noticeable BEFORE PFC even had a COM port assigned is really surprising. It doesn't actually do anything until it has a COM port. The usual reason for sluggish behaviour is the *wrong* COM port, as virtualy every call on the equipment times out somewhere deep in Windows. Can you re-confirm that this is really what you meant? Pete

The Flaps calibration in FSUIPC was added because there was no facility in FS for this to be done. I didn't even know that MS had now added the facility to FS2004. In that case, you do not need the FSUIPC facilities, or if you do, you can surely still use the same method as in FS2002, i.e. assign the original FLAPS_SET control to your axis. Please see the FSUIPC User Guide and Advanced User Guide for details. I've just checked the list of controls in FS2004 and I do see the "AXIS_FLAPS_SET" control, which is certainly new. I will add this to the list recognised by FSUIPC in the next update. Thank you for pointing it out. Regards, Pete

No, none. I have absolutely no idea where to find this information at present, and have never been asked for it before so I've never looked. I can consider it as a future enhancement, when I get time, but please ask me again in a few weeks so I can put it on a list. You really wouldn't believe how busy I am at present, so it'll only get lost now. If you think I ought to know because I wrote AutoSave, then bear in mind that all autosave does is call the same routine in FS as the Save Flight menu entry (or the ';' facility) does. It doesn't create the files itself. I had intended to get it done this week and release it at the weekend, but that won't happen now. I've not even started yet because I am inundated with emails and other questions. Sorry. Regards, Pete

That confuses me. Aren't %c and %x just markers for a single character and a hex integer in Printf and Scanf library routines, and their derivatives? In C, at least, you can read the 5 character DME string at 0C29 by: char chDME1[6]; DWORD dwResult; FSUIPC_Read(0x0C29, 5, chDME1, &dwResult); chDME1[5] = 0; then you can print it directly from chDME1. For a frequency, or any unsigned 16 bit value you'd use (for example, NAV1): unsigned short sFreq; FSUIPC_Read(0x0350, 2, (BYTE *) &sFreq, &dwResult); Regards, Pete

Are you using a language which doesn't support 16 bit ("short") variables? If so just read it into whatever is big enough and ignore the rest. Sorry, I have no idea. What does "string by char array" mean? If you say what language you are using perhaps some other programmers using the same language can help. If it is Visual Basic you are using, I am starting to think that it must be just about the worst language in the world, because 99% of the queries on "how to program" come from VB users. Or maybe it is just the books about it are so bad? It is very depressing. Good luck, I do hope someone can help you. Pete

It's a printable string already. It does actually say this in the SDK. Just read the field as 5 characters and print them. the last character may NOT be a zero, so add that as a 6th character first. Pete

WHY ARE YOU SHOUTING? What "new" flaps control. What would which module be doing recognising any control in any case? Can you explain what it is your saying a little clearer please. Identify (a) what module you are talking about, and (b) what new control you are talking abnout, and © what you are doing and what you expect. Okay? Regards, Pete

A knot is a nautical mile per hour. There are 60 seconds in a minute and 60 minutes in an hour. Therefore to convert metres/sec to metres/hour, multiply by 60 x 60 or 3600. Now you need to convert metres to nautical miles. Since there are 1852 metres in a nautical mile, you divide by 1852.giving you nautical miles per hour, which are knots. However, this is never going to make 1297.9 anything like 385. So my question to you is: How are you reading a 32-bit integer as 1297.9 anyway? There are no fractions in integers. Pete

Er .. I don't. Well, I've certainly not got any of that straight! . Thanks. Pete

I'm a little confused by what you say. The "getting ready" on the Server replaced the old "stopped" message which confused some people. After that it should display "waiting for clients". The client never says "waiting for client" -- it might say "waiting for a connection"? I need to see the FSUIPC.Log file, the WideServer.LOG file and the WideServer.ini file (all from the FS modules folder, and possibly the WideClient.log file and the WideClient.ini file, from the WideClient folder on the other PC. Please ZIP them up and send them to me at petedowson@btconnect.com with an explanation of what you see happening. Thanks, Pete

If this is on the same PC, you can copy the FSUIPC.Key file, from the FS modules folder, from one installation to the other. Pete

No, if it is freeware you do not pay anything. But you wil need an access key for it. Please write to me at petedowson@btconnect.com and I will send details directly. Pete

Yeah, I changed that way back, soon after the first version 2 came out I think. It now says to only do that if you skipped a few years of updates .. well, that's an exaggeration, but it is something like that. These days many folks have too much invested in the parameters -- all their favourite settings, key and button assignments, calibrations, and so on. I take a lot of steps now in the code to delete obsolete parameters and add new ones so that the INI is still okay. It even preserves these for unregistered copies, even though many are not being applied until after registration. Regards, Pete

Oh, dear. I can't win! Due to poular demand I changed the default mode of WideFS to TCP/IP long ago. Unfortunately I forgot to remove the parameter "UseTCPIP=No" from the INI files supplied. I got loads of emails telling me it didn't work! So, I remove the parameter so now it behaves correctly according to the documentation. And I get problems reported by folks, the other way round!? Really you should keep your INI files. If you replace them every time you update your copy of WideFS (or FSUIPC or anything) you risk losing anything you've set up to get it working well on your system. Most folks use things like the Run options in the INI files to load up ancillary programs, expecially on the clients. Are you re-entering such things on every update? It doesn't make sense. Maybe I should simply remove the sample INI files from the ZIP and force everyone to either use their existing ones or make them from scratch? :( Pete

Yes. In fact when they are on the same PC you don't even have to enter the registration twice. Just do it on one then make a copy of the FSUIPC.key file for the other, in its Modules folder. I am just now releasing FSUIPC 3.02 which fixes some problems registering FSUIPC on systems which already have FSUIPC applications running. Regards, Pete

That's not very realistic, though -- real aircraft don;t have such a facilitiy. Perhaps you have the aircraft sounds up too high, or is this in a light aircraft -- they are much noisier in the cockpit than, say, airliners? Are you using a headset for RW? Sorry, I don't understand this at all. If you are using joystick buttons, where do keystrokes like "R" come in? You can assign the KeySend and its number directly in the Buttons page. All you need to do is program the KeySends on one button, then the sound control on another, make sure they both work okay, the close FS and edit the FSUIPC.INI to make both buttons the same button. This seems a bit of a mess. Delete it all and start again, using only Buttons. There's no need for ANY keystrokes at all (no wonder you are getting delays, you are getting things going round many loops!). Program KeySend 1 and 2 on one button, program the FS control "Sound Off" and "Sound On" on another button. Then, with FS closed, edit the INI and make both button numbers the same (i.e. the 2nd number after the P and the U). Regards, Pete

It is going to take a while for all the shareware and commercial, and even freeware, folks to bring out new versions both tested with FS2004 and with the access key built in. Some may simply provide you with an access key to type in (there's a manual "Program Registration" facility in FSUIPC as well, to allow for this). I am aware that Damian is working on ActiveSky, so please check his support forum to see what progress there is on an FS2004 version. Maybe he can get you a key for the older version too. It is really in his province, rather than mine. BTW the newer release of FSUIPC I made yesterday (3.01) may wrongly produce a Message Box saying a program is not accredited even if it is. This depends upon the method the program uses to pass they key. I found this bug this morning and have fixed it now, but I will test it a bit more before releasing it in case I've mucked something else up! :cry: It will be version 3.02 and should be available some time tomorrow (Monday). I'm afraid that the donation system was a bit of a failure ultimately, and is closed. Sorry, Pete

Sorry, but you are most certainly not clear at all on the subject. You don't seem to have read the announcements, nor folowed the threads on this which flogged it to death ad nauseam. The two things are NOT the same. Users are NOT paying me for the right to use add-on programs, whether they be freeware, shareware or out and out commercial. The user registration is for the additional facilities in FSUIPC, those which are completely unnecessary for the interfacing of external programs but nevertheless which are now the bulk of what FSUIPC is all about. If you only want to run programs and not use any of the facilities, just pay me nothing, don't register. It says all this in the announcements. It even lists the facilities, briefly. It also spells them out in more detail at the SimMarket registration pages. Read before you buy. If you don't like, don't buy. Regards, Pete

You mean a Beta version of FSUIPC, for the proper release of FS2004, or a Beta version of FSUIPC for a Beta version of FS2004? Sorry, I'm not understanding any of that. You are using FS2004 downloaded real weather? Is this what you mean by "connect"? FSUIPC really hasn't anything to do with any of thatcan you explain what you are doing and what weather options you are setting in FSUIPC, if indeed you are using a weather program with FSUIPC? If it is a Beta version before 2.991 then there were virtually no weather facilities in FSUIPC back then! You get FS2004 weather. FSUIPC does NOT supply any weather. If you use an external weather program you get the weather you download or create with that. FSUIPC is not a weather program! Pete

Thanks for telling. One other possible cause of registration problems has been confirmed, and another one reported but mystifying. The confirmed one occurs when there are unacredited programs attempting to access FSUIPC whilst you are actually in the Registration Dialogue. There's some interference due to simultaneous calls being made to non-re-entrant code. I'm working on solving this at the moment. I expect to release 3.02 tomorrow. The other one is very odd. One user couldn't register until he changed his local settings. But there's nothing setting dependent in my code and I've not been able to reproduce it. Regards, Pete

No, there is nothing there that shows any interaction with SSWA310.DLL at all. What is that DLL in any case? I've never heard of it. Does it even use FSUIPC? Does it run without FSUIPC installed? If it gives so many problems in any case, surely the suppliers have something to say about it? Sorry, but I really don't think I can be of any assistance in this case. But keep us posted. Regards, Pete

I always answer!! I am investigating this now. It looks like it might be a timing problem, but I cannot reproduce it here. The only thing I can think of is that FSUIPC is loading later than WideServer and taking a time to check the registration codes, by which time WideServer has checked in with FSUIPC and got rebuffed. I may have to provide a test version of WideServer with a delay loop built in, so it doesn't give up so quickly. I can't make it fail here, so I'll be dependent on feedback. Write to me on petedowson@btconnect.com if you want to try any tests for me. Regards, Pete

Have you cleared the weather first, and elected to set this to all stations? Have you turned dynamic weather changes off? FS2004, unlike previous versions, is actually running in what I used to call "local weather mode" all the time. My so-called "global weather" is merely the default weather which is applied to any station which doesn't have its own weather already. FSUIPC's weather settings are constrained to affecting just that global "fill-in" weather, it won't operate on local weather stations -- except those set by external programs using the New Weather Interface in FSUIPC 3. At present I really don't see it as likely. I can only deal with global (i.e whole world) weather in any case, and as I say, the visibility system is now so good it really makes things worse to impose anything like that, not better. The main reason for its introduction on FS2000 was to help with frame rates -- the lower the visibility nearer the ground, the better the frame rates despite the increasing complexity of ground imaging. I don't think this is a consideration in FS2004. Discarding FS2004's beautifully done realistic local weather simulations, which give nice effects of weather different in the distance, changing smoothly as you fly, and substituting something not much better (except for cloud graphics) than FS2000 or FS2002 seems a real waste to me. Why not stick to FS2002 then? The weather engine in FS2004 is easily the best improvement in the whole sim (IMHO). Try some of the weather themes. Try downloading the FS real weather. Try, when they appear, the new weather programs which will make use of the New Weather Interface in FSUIPC 3 to set *local * weather. After a few weeks I'm sure you'll agree. If not, get back to me. Regards, Pete

Sorry, I don't know everything, and I don't have every accessory there is. I think I do have a copy of PSS A320 here, but I've never had time to install it. No, FSUIPc can't really have any affect on such things. As I said, they probably only use FSUIPC for TCAS. If I am asked for a key for freeware and provded the information, yes, of course. But, again, does his panel use FSUIPC? I'm sure that there aren't many that do. I think that is wrong. whether things work with FS2004 or not is not just a matter of FSUIPC support, or, for many products, not EVEN a matter of FSUIPC support, as they don't use it. For me to imply that something will work with FS2004 when I haven't seen it do so and when its own publisher hasn't announced it will would be very wrong of me, and, worse, make it look like programs that had no access keys would not work, which is even more wrong. Sorry, but in each and every instance your recourse is to the author or publisher, as it always has been. Why do you think it would be any different now? Please do NOT try to make me into some sort of regulator. That is completely wrong and false! I cannot comment on that. It really has no place in public discussion. If you register your copy of FSUIPC it would be totally irrelevent to you in any case. If you don't, then you need to wait for appropriate announcements and releases from publishers in any case. And since they have at least to test their products out with FS2004, and very likely make changes in any case -- whether they use FSUIPC or not -- I can't see that there's any alternative anyway. :x Pete

Sorry, I don't understand where the discrepancy comes in. Where are you setting the surface visibility, and how does FSUIPC come into it? Where are you setting these "upper and lower altitudes"? Is this all in WeatherSet or WeatherSet2? You really would miss some of the best improvements in FS2004 if you achieved this. The experience of ascending above a low level murk into clear visibility yet still see the ground below only through the murk is much more realistic to me. This is why I didn't do all the work needed for the old FSUIPC graduated visibility, it just seemed a total waste of time and to spoil the god new effects in FS2004. Regards, Pete