Pete Dowson

Did you read the sticky above entitled "READ THIS IF YOU LOSE YOUR FSUIPC or WIDEFS keys"? It isn't only your email and key which must be exactly correct, but also your name. It is quite amazing how many different ways folks have of spelling and entering their own names. All three parts of the registration need to be correct. Next time please make a backup of your FSUIPC.KEY file, as advised in the documentation. Regards, Pete

The user's aircraft, the one you are flying you mean? There are no such specific indications -- you have to deduce them from all the information you have. If you are flying it in person you will know in any case. Regards Pete

As far as I know the serial drivers for USB do make USB connections look like normal COM ports to the programming interface, so I doubt that this is the problem. The problem is likely to be much more to do with the fact that the software you probably installed to handle the nornal functions of your PDA (Active Sync or whatever) is grabbing the link as soon as the device is connected and switched on. I tried for ages to sort things out on my Ipaq and gave up. Sorry. Perhaps someone who succeeded (and I am sure there was at least one) can chip in if he sees your message -- else try to search through the forum, see if you can find who it was. Regards, Pete

Why not just go to FS's Options--Controls and disable the joystick input? That's all that's happening -- it is looking for one! Yes, but it would be far easier just to tell FS there's no joystick, surely? The PFC driver doesn't use anything to do with joysticks or HIDs nor does it access the registry. Regards, Pete

A zero ID field most definitely means that slot is now unused -- I simply don't bother to clear the rest of the structure as it is a waste of processing when the ID is the 'key'. The logical way is to stick to the documented rules -- zero in the Id field means that slot is not used. Always, no exceptions. I do not want to see anything showing zero Ids being treated as valid slots. They are not. Please change your methods. Regards Pete

My site? It isn't mentioned here in the forum. I have no other site. In any case, by "supported by FSUIPC" all that is meant is that the program needs FSUIPC to operate. It doesn't mean it will necessarily run on an unregistered copy of FSUIPC. I think the reason that program is unsupported is that it became part of a payware package, so unless the author requests it, I am not at liberty to make a freeware access key for it either. Regards, Pete

Well obviously that will make AI aircraft come and go a lot more, so the slots will get used, freed, used again and so on, but then yje 'range' business wouldn't have any beneficial effect. Can you please confirm that you are checking the "id" field", not just the flight number as you mentioned. It is the Id field which defines a slot's usage -- you must not use information in a slot with a zero id. Regards Pete

Okay. Thanks. I'm on to it! Pete

No, not that part. I have done all I can. On Jan 1st 2006 I asked them to put the warning in the notifications or receipts (preferably both) that any key (WideFS or FSUIPC) registered in 2006 needs version FSUIPC 3.53 or later. The explanation is in the Announcement at the top of this forum which I put up the same day. I have confirmation that they do warn folks in the receipts they send for FSUIPC, but are you saying there was no mention in the one for WideFS? I need to know, so that I can ask them to rectify this. Check both the receipt for your payment and the Key notification -- i.e. two different emails. Regards, Pete

I've not seen this, nor do I know how it is possible. The range check merely determines whether an entry will be made or not. Can you show me? Don't go by Flight#, please check only the IDs. Slots where the ID is zero are free -- you must then ignore the rest of the data. If you want to send me some evidence do so via petedowson@btconnect.com, but please double check these things first. The TCAS data provided is actually range limited by default and has been provided, virtually unchanged now, for well over three years, and I've never seen a duplicate in, for instance, TrafficLook, which simply displays everything it sees. It really does sound as if you are not checking the main "slot used" indicator, the ID, the first entry in the structure. Maybe what is happening with a range set is that some aircraft are going in and out of range, therefore appearing and disappearing and reappearing. They will likely get different slots each time they reappear. Regards Pete

The difference between 3.52 and 3.53 is that 3.53 accepts registrations purchased in 2006. Please check the first important announcement at the top of this Forum. You must have only purchased the Keys recently -- in the Emailed receipt you got from SimMarket, didn't it tell you you needed 3.53 or later? I'm sure they have amended their notifications. The explanation is in the Announcement. Regards, Pete

Yes, there is certainly something blocking WideFS communications. I really don't know what to advise. You can get me more information if you like, which I will look at for sure, but I suspect it will all come down to a blocked connection. For fully detailed Logs, set Log=DebugAll in the WideClient.ini and Log=Debug in the WideServer.ini. That will give me the most I know how to elicit from the system. Regards, Pete

I think Bob "Sticky" Church has written all this up someplace. Try CMNote02.zip on http://www.stickworks.com, or visit http://www.ch-hangar.com. Regards, Pete

First, you said "I have the latest registered version of FSUIPC (ver 3.52)", but the latest is actually 3.53. Did you purchase your registration in 2006 by any chance? If so you need to update FSUIPC. Please see the announcements in this Forum. Otherwise: I'm not sure about FSC75. The only FS commander I have listed as accredited for use with FSUIPC is simply called "FSC.EXE". Have you tried contacting FS Commander support at all? It is looking as if you need to. I really don't know what that program is doing. And did you follow my advice and check the WideFs connection? I said: If you want to test WideFS, try one of the additional little utilities provided in the FSUIPC package -- TrafficLook or WeatherSet2, for example. These only need the FSUIPC interface, no direct FS access Regards Pete

Well, I'm pleased that you solved it nonetheless. Regards, Pete

Reinstalling exactly the same copies of DLLs and EXEs would make no difference whatsoever unless you suspected data corruption on disk. If that is happening then you are in deep trouble in any case. Reg keys are not relevant. It is either registered or it isn't as far as connection is concerned. Bad keys affect data, not connections. The files attached show nothing at all as they are only of the Server. The Client Logs are more relevant surely? Regards, Pete

The log for Wideclient shows no attempt at all by any program to connect to FS. Both logs show WideFS running fine, but no program using them. Regards, Pete

Re-installing shouldn't need re-registration. It sounds like you deleted the FSUIPC.KEY file, by mistake perhaps? Regards, Pete

The only possible side effect of having FSUIPC poll buttons too frequently is lowering performance of FS -- so in the end it all depends on your system. So far Ii know of no problems with its default of 25 mSecs -- your button pressing must be so fast that it doesn't see them very often. It has to see both press and release, so the button press needs to be for 25 mSecs or more 910 mSecs or more now). Regards, Pete

Ah, that's one of the things I should have remembered to ask you to check -- multiple assigned controls. You don't need to uninstall devices, just make sure there's only one assignment per control in the FS Options-Controls-Assignments section. There's a drop-down there which lists the different controls attached. You can use them all, but, worse, by default FS will assign the same axes to the same controls in each device. This default assignment will occur whenever FS has re-generate its FS9.CFG file for any reason, or if you actually installed or de-installed devices it already had listed. I am working on a system for axis assignment in FSUIPC, so all the FS kerfuffle can be bypassed, but it won't be ready for a while. Regards, Pete

Actually, the three gear indications show the state of the gear, not whether ity is touching the ground. There's only one flag for "on ground" and I think that is set till there's no part of the aircraft touching -- but I'm not sure even of that. If I implemented such an option you would certainly never want to take off in a light aircraft in any amount of crosswind at all, because you always need to compensate for crosswind with aileron on the take off roll. Worse, if I suddenly switched from rudder to aileron just when the "on ground" flag cleared, it could make you very unstable at exactly the worst time! Conversely, with a 'heavy' aircraft there's no reason really why you should not use your aileron control also for steering, especially on the take-off roll where the amount of "aileron" needed to steering should be negligible. I'd be rather reluctant, if only for the reasons stated above. Please think it through very thoroughly -- I am open to persuasion, but you must realise that FS flyers have been managing quite well with FS's "auto-rudder" for steering for many many years now. ;-) If I do (eventually) agree then it would just be an item on a list -- if easy it may fit in sooner, but otherwise it would need more than one request to bring it to the top! Regards, Pete

FS uses DirectInput, which is detecting these things very much more often and at a lower level, and FS gets notifications. FSUIPC uses the Windows Joystick API and has to poll. The default polling interval I set is 25 mSecs (or 40 times per second) which has always been fast enough even for very complex applications. The interval is set by a "PollInterval" parameterint the main [buttons] section of FSUIPC.INI, but will be omitted if defaulted. Do you have a parameter like that there? If not try setting one with a lower interval -- it may help, it may not. Please read the details of this parameter in the FSUIPC Advanced Users guide. What sort of frame rates is your FS running at? Try limiting them to, say, 20 or 25 or so to see if that helps. Maybe FSUIPC isn't getting much chance to do the joystick scanning. Regards Pete

Does "GetModuleHandle(NULL)" always get the Instance? I always save the Instance supplied to the module in the DLLmain call, and use that. Otherwise I can only think that it doesn't like the resource for some reason. The "DialogBox" call I use works fine. Why not use the debugger with your compiler to set breakpoints and see what is happening, or at least build checks in (eg. for the result of the DialogBox call and GetLastError codes)? To use a debugger with FS2004 you will have to use the "No CD" crack for the FS9 EXE, otherwise it stops you. Regards, Pete

No, if GPSout is in the FS Modules folder, then it will be trying to send something. It will try to use the Port you specified in the GPSout.INI file -- please check the little bit of documentation provided. There are some things you need to set yourself. It cannot be automatic. There's a freeware utility called PortMon from http://www.systeminternals.com which can show you what is going in and out of each port. you can use that to prove to yourself that data is being sent. Yes, then edit the INI file to set your requirements. Regards, Pete

I have to repeat my questions, then, as you seem to have missed them? I cannot possibly even hope to help if you don't give any information. Have you got it repeating? Have you programmed it to do the same action on press and release (for a toggle obviously the second will cancel the first). Have you got conflicting actions programmed on the buttons some other way, such as through FS? If you go to FSUIPC's Logging page you can enable button logging and see if the presses are actually all being seen by examining the Log. Regards, Pete