Pete Dowson

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

No of course not! The dcumentation and announcements above have always made it very clear that you are paying for version 3 or FSUIPC, version 6 of WideFS. That means any Version 3.xx and any version 6.xx respectively! All you need to do is download the ZIPs and copy out the FSUIPC.DLL and WideServer.DLL to your FS Modules folder, and the WideClient.exe to wherever you put that. Updating is just that, one step, exactly as documented. Regards Pete

Where are you expecting such a message? It would only show that in the FS title bar -- you will only see that if you run FS in Windowed mode. There is no "message" as such, it is just status. Why are you expecting a message? If WideClient says it is connected then this "FS Commander" should certainly connect -- if it is an FSUIPC application and doesn't need direct access to FS, of course. I'm afraid I don't know the program myself -- perhaps you could ask the author or his support site about this? If you want help from me I need more information. I need version numbers of WideFS and FSUIPC, and it would be useful to see the WideClient.LOG file at least -- you will find that in the same folder as WideClient. I would also need to know how you are deciding that you are "not able to connect ..". What are the actual symptoms? What does FS Commander say? Possibly it needs the FS folder access or something else, not only the FSUIPC interface (which WideClient is certainly providing). 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

Dowload the latest from http://www.schiratti.com/dowson. I don't support old versions in any case -- see the Announcements above! What is the point of sticking to old versions in any case? Pete

Ah! Can you tell me what fixed it please? Pete

Okay, in that case it is normal for FS, it's the way MS implemented it. It isn't anything in FSUIPC and certainly nothing it its parameters. I'm not sure why you've not noticed it before. It's a very widely discussed complaint with FS2004. Your parameters for FSUIPC visibility options seem fine -- in fact they appear to be more or less the default values. What was the surface visibility set to? With 20 miles, as you stated earlier, I'm pretty sure you don't normally get a top-of-layer cloud imposed. I thought they only appeared when there was mist or fog on the surface. You could try raising the minimum visibility so that it is never low enough for the cloud to be imposed, but that way you'd never get fog either. I think the real solution won't be possible till the next version of FS. Regards, Pete

There has been no changes in the visibility options in FSUIPC for many releases. How old was the previous version you used? What are the visibility settings you have -- show me your FSUIPC.INI file. It's easy enough to change them, in any case. If you are seeing a large rectangle of "cloud" below you, which moves with the aircraft, then that is the top of the visibility layer and the visibility below that is limited. Microsoft, in their wisdom, tried to solve the "see-through from above" problems of fog by overlaying a thin cloud layer. It is pretty awful, but it means you don't have graduated visibility enabled, or you have but it doesn't start where the FS visibility layer leaves off (set to 0 to do that automatically), and/or doesn't continue to a decent altitude. The fact that you say you have a visibility layer finishing at 5000 feet seems to indicate this diagnosis. Regards, Pete

What aircraft is this with? Does it have an autobrake setting '5'? Is it the FS autobrake -- add-ons like PMDG aircraft do their own thing I thinkj. Test it with the default 737 or 747. Pete

Sounds like a graphics problem. Why do you think it is anything to do with FSUIPC? Pete