Pete Dowson

Thanks. I think those crashes may be due to a partially implemented expansion of the weather system. Ever since there have been clouds in FS only those four have been selectable. The other numbers were listed in some of the Microsoft SDKs with different, more complex, cloud types (like cirrostratus, stratocumulus, whatever) but only gave one of the basic types anyway when used. It looks like they changed that so that additional graphics could be selected but didn't follow through. Regards, Pete

Sorry, I don't understand this part. "Freedom" in the sense that it isn't imprisoned? Or freedom for people to use it and interface to it? Can you be a little more explicit, please? Well, it's merely one way of writing code to interface to FSUIPC. It's almost exactly the same as the way things were interfaced to FS5IPC and FS6IPC beforehand -- that was the whole point, compatibility -- so if Adam's publication of how to do it was "public domain" then I guess this is. It is an illustration, an example, as well as being a short cut for those who aren't interested in fiddling about with the interface workings. The other language variants were all derived from this, independently, by other people, not me. I provided them all as a service, with their permission. I've no idea whether they would regard their work as public domain or not. Sorry, I guess I'm not cut out to be a solicitor (lawyer). Regards, Pete

Can any reader here read this and translate it for me, please? It may be important, but I cannot tell. Regards, Pete

FSUIPC doesn't look at any location for built-in FS controls. All it does is send the control to FS, the rest is up to FS. There are many additional "pseudo-FS controls" added by FSUIPC (and more coming in the next version), but those certainly are not any of those. The same applies to NAV2 as well, by the way. Furthermore, the same happens when using the mouse on the radio stack -- try it! Interestingly enough, COM1 and COM2 are okay in this respect! It looks like a bug in FS specific to the NAV radios. Regards, Pete

As far as I can see, from all the references, this is using the USB connection as a standard serial port. If it looks like a serial port to GPSout, and the program you are sending it to can read that serial data, in NMEA format, yes, of course it will work. The problem I have with my iPaq on its USB cradle is that the USB link, although it certainly seems to be emulating a standard COM serial link, appears to be permanently "owned" by Microsoft ActiveSync at the PC end and some synchronising program in the iPaq end. I expect I could kill both processes and get access to the link as a normal COM port. But I've not really tried. To start with I have nothing for the iPaq which could make use of the data in any case. Quite honestly I prefer to use FliteMap and other programs on a proper PC with a nice large screen! :wink: I'm pretty certain there will be a USB driver there which is making the USB link operate as a COM link. I use this already with GPSout because I ran out of COM ports and had to use USB. I think that depends on the scenery you are using. The Latitude/Longitude system used in FS can measure down a lot more accurately than GPS in any case -- that's how scenery designers position things to the nearest fraction of a metre -- but if the resolution of the scenery is poor or someone's made a mistake and placed the lake in the wrong place, obviously they won't match. Microsoft make accurate detailed scenery for some areas, less detailed and possibly less accurate for others. Most of it will be derived automatically from satellite survey data and other databases which are available. There are many add-on scenery packages which are coming out with greater detail and, hopefully, more accuracy. They also often use satellite or aerial survey data to base their work on. In fact the UK VFR scenery is not only very accurate, it is made from real aerial photographs -- I can navigate over that using UK Ordnance Survey maps at 1:50000 scale with great accuracy as all that detail is present. It doesn't. There are add-ons (GPSout is one) which take data from FS's innards, process it into NMEA format, and chuck it out on a selected COM port. Regards, Pete

You have a corrupted installation of FS2004, one on which you have run the FS9.1 update but where that update has not succeeded. By the look of the error reported in FSUIPC's log, the CONTROLS.DLL, for instance, is the one from the original FS2004 release whereas the WEATHER.DLL is the one from the 9.1 update. If you look at the announcement I made in this forum about FS9.1, the one at the top of this forum, you will find a list of those DLLs changed by the 9.1 update. All those should bear a date in September 2004. Otherwise you have a partially installed FS9.1 update which is going to cause you problems. I have received a few reports like this, not actually the same as yours (usually the other way around -- an old WEATHER.DLL in an otherwise updated FS9.1), and it is really a bit of a pain, so I am currently testing a version of FSUIPC which tries to cope with any stange mixture of FS DLLs from FS9.0 and FS9.1. I will log two especially important ones (CONTROLS and WEATHER) so that folks can see for themselves whether their system is okay or in a bit of a mess. I hope to release this updated version of FSUIPC in a week or so. Meanwhile I can only suggest you check your FS2004 installation and try to correct the partial update situation. Regards, Pete

Has it been longer than 24 hours? As it clearly says on the purchase site, the Key will be emailed to you within 24 hours. If not, you need to go back and report a problem. I think there is a method of doing this called a "problem ticket" or something. I am not involved in this activity at all. This Forum is for technical support and announcements, but you should realise that human beings are involved in the sales process and they need to do other things occasionally like sleep and eat. Okay? :wink: Regards, Pete

Yes, with a registered version of FSUIPC and WideFS. This is how: In FSUIPC's Keys page, program each keypress you want to send as the "FS control" (actually one added by FSUIPC) in the drop down list called "KeySend". Allocate a different parameter to each one -- the values don't matter, just list them. First one parameter 1, second parameter 2, and so on. Then in the WideClient.INI file on the other PC (the Client PC), you specify what keypress each of these KeySend codes should produce. The parameters just say KeySend1= a keypress definition, KeySend2 =, and so on. Details are in the WideFS documentation for the latter. You can also get the keycodes for the keypresses you programmed in FSUIPC from the FSUIPC.INI file's [Keys] section. On their own these KeySendN= parameters merely send the key code to Windows using its "recorded playback" facility. Whatever program which has keyboard focus will see the keypresses. If your target program does not have focus then you would need to find a way to direct the keystrokes. WideClient offsers two ways -- one involves knowing the "Class" name of the window of the program to receive they keys. The easier way would be to get WideClient to load the program in the first place (using one of the Run or RunReady parameters). Then the SendKey parameters can be told which of those to send the keys to. There is one catch. If the program reads key presses directly, or via keyboard state details, rather than relying on the normal Windows KEYDOWN/KEYUP and CHAR messages, none of this will work. To get things to work for such program I think you would need a much lower level driver progam, sitting below the normal Windows API. Regards, Pete

I'm glad you sorted it out. That must be something to do with AS, as neither WideFS nor FSUIPC care about all that stuff. Maybe a note to the AS tech support so something can be added to their docs? Regards, Pete

That's a good advertisement for their products, I must say! :( Pete

I've not dared install SP2 on any of my PCs yet. I have heard of many folks having difficulties after that upgrade, and I have no time to spend the same number of days sorting them out as they did! I don't know the FMC, but the FreeFD stuff has always worked well on WideFs. No, nothing. I don't even understand those things let alone use any of them. My programs use the minimum number of Windows thingies as I can possibly get away with. There's no more used now in WinXP than there was when I first wrote it in Win95 days. Okay. Good luck. I'll be looking out to see if we can both learn anything. From what I've heard you have come off quite lightly if the only thing not working with SP2 is WideFs. I think you should also ask Katy Pluta over in the FS2004 Forum. She is a strong advocate of SP2 and also a WideFS user (with Project Magenta), and a bit of a Network Expert. Regards, Pete

As explained in the WideFS documentation, this indication can occur when clients time out the Server and re-connect. After a while without any queries from the now "unused" client connections, the Server will remove them and the number decreases. But the Server allows more time for the Client than vice versa. It sounds like no messages got out to one or more of your clients for quite a while. You say What does this mean? What did you kick? Are they going into some sort of sleep or suspended mode? You don't have some power management timeout operating on them, do you? Obviously if they stop receiving messages for any reason they whole thing will grind to a halt. Anyway, as with any sort of support request, if you want any help or advice I need version numbers and Log files. But first do please check these yourself, and especially make sure you are using the currently supported versions of WideServer, WideClient and FSUIPC, as listed near the top of this Forum. If you still need help, Zip up the files and write some description of your systems and the circumstances and send to me at petedowson@btconnect.com. Regards, Pete

Only SimMarket and Project Magenta then. Intercraft in Japan started after Christmas. I would have been the one if you claimed it in return for donations before July 2003 -- see the Announcement about lost keys above. Regards, Pete

Ah! So presumably this "Flight Gear" program is published under one of these, and the inquirer was wondering if linking it to FSUIPC would be against its license. Right? Looking at the link you quoted, I guess the question arises because of the business of "linking with non-free modules". That's an interesting one. Really, for freeware use in accessing FS internals, FSUIPC is a free module. There's a fee for commercial use only, but otherwise the interfacing aspects of FSUIPC are free. The user facilities should, in such cases, be regarded separately (indeed, I suppose they could, with some risk of inefficiency, be separated into a separate module, albeit with very close links to the other, and vice versa). Anyway, I hope the references to another successful implementation, that of PS1, was helpful to Pat. He's not been back yet to say. Regards, Pete

No, it means the MCP Kcodes as defined in the "FSUIPC Offsets" documentation from Project Magenta's website. I'd advise you to download that and use it for reference. I'm not surprised. According to the PM document: N11 K070 VOR1 Meaning, I think, that the K code "70" operates the VOR1 switch on the EFIS. I am not aware of such a problem, but you are correct. ALL of the PM controls offered in FSUIPC are PM-related -- FSUIPC merely operates the bits and values as documented in the PM FSUIPC offsets document. The rest is up to PM. Regards, Pete

This is usually a problem of some other (perhaps hidden) panel part being seen first by the DLL. In such cases the best way is to edit the [AdvDisplay] section in the relevant PANEL.CFG file for the Aircraft, specifying the window name it should be docked to -- usually "main panel" for the big 2D part -- please see the "Changes in version 2" section of the documentation, especially item 12. If this is also too difficult, perhaps because of some specialised panel design, the alternative is to "Lock" the display instead, and use the FSUIPC hot key to show and hide it. Of course that would need a registered copy of FSUIPC. Regards, Pete

I don't know "Download Accelerator", but perhaps it's not compatible with files on whatever website you got it from. You should check with the site. The file you should get it a ZIP file called FSUIPC.ZIP, and contains 13 items, only one of which is the FSUIPC.DLL. The 1.37 mb file is FSUIPC.ZIP. As I say, it contains 13 items including full documentation and some utility programs. Delete this non- FSUIPC.DLL from the FS Modules folder, as it is NOT FSUIPC.DLL. Please download only the ZIP file as listed on any website which carries it, then extract the DLL for installation. Regards, Pete

Oh, right. I am not familiar with their products at all I'm afraid. Well, I can look at and interpret logs from FSUIPC if you like, but I do not actually have any Elite devices nor do I know the least little thing about them. They don't seem to need my support, but since they presumably wrote the driver to work with FSUIPC (or had it written?), they would know something about it. And why aren't they responsible? Regards, Pete

You don't mention the version number, but I assume you are talking about FSUIPC 3.40? Didn't you keep your FSUIPC.KEY file -- it would have saved you re-registering, unless you also reinstalled Windows or moved to another PC. There's no change in the registration system, and hasn't been since about version 3.02. In all cases like this it has turned out to be a case of incorrect entry. All three parts (name, email, Key) must be exactly as per the original notification. Cut and paste to be sure. If you still have no joy, send the details to me at petedowson@btconnect.com and I'll check them here. Regards, Pete

It is not only the key which must be exact, it is the name and email too. Cut and paste all three entries. If you still have a problem, send the details to me at petedowson@btconnect.com. But all cases like this so far have turned out to be incorrect entry of the data. Regards, Pete

Thanks. Send it to petedowson@btconnect.com please. Regards, Pete

Not that I know of. I never fond any way into that part of the system. Yes, only one visibility layer is implemented throughout. Although FS's weather structures have long had provision for any number of layers, in practice when I have tried to use these everythnig has gone horribly wrong. They don't work. Well, not at that time. THE GLOB weather is merely the default weather set for a Station that has no specific weather set for it, but weather stations only get 'populated' as needed as far as I can see. Naturally, if you ask for weather for a far-off station (or any point far off) this would invoke routines in FS to compute the interpolated weather there, and it would need to assume the GLOB weather. Of course, as I've argued and demonstrated before (see discussions in this forum and my documentation), GLOBal weather doesn't stay global forever. The air mass is dynamic and things change. I think it only actually computes and progresses the weather stations around your position - not sure how many, but something in the order of 50-100, probably depending where you are. However, it can store weather *ready* for computation for all of the METAR stations in its list -- you'll find a file containing all the 4-letter ICAOs in the same folder as your FS9.CFG file. It is called "wxstationlist.BIN". It is there rather than in the FS9 folder because it can change -- when you download weather using FS the stations may be updated. Sorry, I don't know. Refresh scenery after clearing the weather? There is an assignable control to refresh the scenery. Regards, Pete

Sorry, but I don't have anything to do with Elite or its panels. You need to talk to Elite support. They have never talked to me or asked me to support anything to do with any of their products. Why do you think FSUIPC or anything else I produce is in any way involved? Please let me know if there's something which I can help with, but at present I cannot see what. Some Elite products are actually made by PFC (http://www.flypfc.com), whose digital products I do effectively support through my "PFC.DLL" driver for FS, but I think all those supplied through Elite use their own proprietary protocol, not the PFC one supported in my driver. Regards, Pete

This sounds the same as FSUIPC's "extend max METAR vis" option. This interprets 9999 and 10SM as meaning "something beteen 10kn/10SM and max vis", and generates a skewed random visibility instead -- for weather injected by third party programs only, of course. What did this replacement WEATHER.DL convert the "9999" to, then? Really? I've not noticed that! What does it set for the visibility in these circumstances, then? Thanks for the info! Regards, Pete

Oh, rightwhat benefits did this one provide? I didn't know anyone had been modifying it! Not to worry, I;m glad it is now all sorted out! Regards, Pete