Pete Dowson

These are the logs from which you quoted two lines only from each originally? What logging options did you have enabled? It would be helpful to see what commands resulted in what you see. Why keep the rest a secret? It is possible the WidevieW reads visibility from FSUIPC in one and writes visibility via FSUIPC in the other. But there are three different interfaces through which it can operate, and the oldest one of these (the FS98 compatible system) doesn't support visibility layers. Even if it uses one of the other interfaces (AWI, FS2000, global only, or NWI, FS2002/4 with global and local support), I don't know how it might be using them. Using the WeatherSet2 (NWI) and WeatherSet (AWI) programs on the Server PC, as I asked, would allow you to verify that those interfaces were reading the visibility as you set it. That's why I asked you to try them. If they are reading okay, but WidevieW isn't, then that would be a WidevieW matter for sure. Alternatively, it could be that WidevieW is reading them okay but writing them incorrectly, so logging of the weather data on the client, especially the weather commands, would have ben illuminating too. It may also then show if it is a problem of actually setting the weather on that PC via FSUIPC. By releasing your information in little tidbits it is taking rather a long time and a lot of effort to not get very far. I don't mind helping here, but please see if you can do something when asked, and possibly supply more inofrmation. Also let me know what WidevieW support have to say. Considering both FSUIPC and WidevieW have been around for many years I am surprised this has only arisen just now, well into FSX developments and over three and a half years after FS2004 was released. Maybe no one has ever used WidevieW for weather transfer before? Seems rather unlikely? Regards Pete

No, you shouldn't publish or send copies of bits of FS. But you could publish instructions for other users. I think they knowand I checked. It is already bugged. I think it just hasn't risen high enough in the long list to get fixed yet. I think they've had too much to do with all the performance problems and other more serious bugs. Regards Pete

OkayI'm not actually sure how WidevieW reads and sets the weather, so your question will really need to be put to WidevieW support. Are FSUIPC's weather settings set to minimum? Are there any visibility options set, such as graduated visibility and so on? I thought that was obvious. I mean that, having set the weather in FS's weather settings, as you described, did they apear to operate the way you set them in FS on that specific PC. Forget the other PC, we need first to check that it is working on the first one. [sorry, I don't really know how else to say it -- I don't understand what is so hard about the way I worded it in the first place]. Sorry, I don't know what those are. I don't know WidevieW and I've not used it since FS98. No, see below. And what about my point that visibility is NOT cloud, as you seemed to assume? Other questions: 1. Are you using local or global weather? i.e. is the weather you are setting specific to a weather station? I am not clear how you are doing this. 2. Do you clear all the weather first? Please, try using my WeatherSet2 program to read the weather on the PC on which you set the visibility. Read both the global and the weather at the weather station. See what visibility data is being set there, as readable by program. WeatherSet2 reads FS9 local and global weather. I do not know what WidevieW reads. I get a strong feeling that your question is really aimed at WidevieW. Let's just check that the weather is setting correctly on the prime PC first. If it is and it is readable, then it becomes a question of how WidevieW is reading it there and how it is writing it at the other end. Regards Pete

Er .. questions arising immediately include: 1. In FS98, FS2000, FS2002, FS2004 or FSX? 2. Are you using FSUIPC at all? Or WidevieW? 3. If FSUIPC, which version, and what settings have you got? 4. How are you setting the visibility? By dialogues in FS, or by program, or what? 5. Is it being set that way on the computer on which you are setting it? 6. How are you having it transmitted to another computer? 7. What is running on the other computer to receive it and act upon it? Without at least some information, I can't really help much can I? Note that until FS2004 multiple visibility layers were not supported -- only a surface visibility is available. I don't think multiple visibility layers work correctly in FS2004 or FSX -- when attempted they've been very problematic. Generally the one and only working visibility layer, which is the surface visibilty layer, is set to begin at -1500 feet so that it reaches the ground all over the world. What has cloud got to do with it? You need to set a cloud layer if you want to break out of cloud. The visibility effects from cloud layers are not the same as those produced by the visibility layer. Regards Pete

Yes, confirmed. I'll bug it with Microsoft directly so it gets fixed one day. I doubt that it would be a priority job, even though it is probably only a minor editing exercise in the XML panel data -- even a clever user could fix it, but it needs to be properly listed. Perhaps you could also please report it via tell_fs@microsoft.com. Regards Pete

Please scan down the Announcements and sticky threads at the top of the Forum. One of those addresses this very point. Regards Pete

I assume you mean the visual switches on the cockpit overhead, not the controls and indications themselves? Both 2D and VC? I'll have a look here. Regards Pete

What in the PFD is there from your waypoint to be updated? Surely both the PFD display and the ND are in one window, from one program (PFD.EXE) on your client? That sounds absolutely awful. What does PM support say? Have you checked the performance of the PFD display on that client? If you press 'F' (I think) it will display the assorted frame rates - graphic, data and FS. A process of elimination would be useful too. Try just the PFD client without the CDU.MCP -- fly with the FS autopilot if necessary. See if the gagues perform responsively. Then try the MCP only, using FS defauult instruments to see what you are doing. and so on. You really do need to narrow it down. Please, it isn't any good sending me PM logs -- they are for PM support. I assume you are talking to them? What is your average frame rate in FSX by the way. It looks too good to be true for a mere 3GHz PC from the Logs -- averaging 16 frames per second update rates on both clients. Are you only flying in country areas with no autogen? I can't get such good frame rates with the release version of FSX on a Pentium Core2 Extreme 6800! Have you tried limiting the frame rate in FSX? If you are really achieving 16 average, try limiting it to 15 or 16. Is FSX your first FS with WideFS and PM? If not, can you make sure it all runs well on FS2004 or FS2002 first? Now this WideServer log is nothing like the previous one you posted, which showed no errors at all for 2659 seconds (44 minutes) when you closed down. Now you show disconnections and reconnections several times over the course of 3335 seconds (56 minutes), starting after only 8 minutes! Why is this one different to the last? What was different in what you did? It LOOKS like you simply closed and restarted the Clients several times, hence the disconnections. I say this because the two error-free Client logs you supply start at 17:05, a full 41 minutes after WideServer started, so only relate to the last 15 minutes of the session during which there were no errors logged. There are no problems shown in the logs, though of course you aren't showing me the whole story by supplying a WideServer log for 56 minutes with Clients relating only to the last 15. I can only think of three possibilities: 1) Data is getting queued in the TCP/IP link from FSX to SimConnect, and that queue is building up. I don't think this is that likely, but there have been one or two cases reported, early on, with such symptoms -- even on a single machine, not PM. I think these were fixed by uninstalling firewall and security programs and moving to ones known to work okay with FSX -- Windows XP's firewall is okay, and I think AVG and Norton Antivirus are okay. Note that merely disabling them doesn't fix anything, they have to be completely uninstalled in order to remove the hooks that are getting in the way. 2) Data is, for some reason, piling up in the memory buffers of the Fs Pc (the Server) because it isn't being swallowed fast enough across the Network. This could, I suppose, be a wiring or hub problem, or maybe even a Network Card or Network driver problem. Check all of these -- reinstall the Network cards and their drivers (literally if necessary). Try alternative network cards if available. Don't use Wireless. 3) Data is piling up in the Client TCP/IP queues because WideClient isn't getting enough time to process it. Since the PM programs aren't that heavy on processor usage, this is more likely to apply to the PFD PC and be down to graphics drivers taking the processor for large chunks of the time. This has been quite a common cause in the past -- you need video cards and drivers properly supporting OpenGL hardware acceleration and working well. The CDU and MCP don't use OpenGL (well, it is an option on the CDU but I've never used it). If the problem really is on the PFD PC, and the CDU/MCP work okay without it, then this really is the most likely. You should discuss these sorts of problems on the PM forums, because there will be folks who had this and dealt with it before. PM used to have their own Newgroups/Forums, but sadly they don't now. Try the group at MyCockpit. http://www.mycockpit.org/forums/forumdi27981&f=99 Regards Pete

One other observation: Have you perhaps got Client1 and 2 named the other way around from your description? I would expect next to zero data reception at the server from the PFD program, which is a display only, but qute a bit from the CDU and, especially, the MCP which is controlling the plane during autopilot modes. Regards Pete

Are you sure these are Network problems and not problems with the graphics drivers for the PFDs? "Abends" meaning what, precisely? Is there an error report, a hang, or what? No problems according to the WideServer Log, but the other logs you provide are for PM, not I. I'm afraid you need PM support for those. Are there any errors listed in the Wideclient logs on the clients? And please also check the FSUIPC4.LOG, as any problems with SimConnect may cause stuttering -- not crashes nor hangs however. If your PFDs are crashing the most likely suspect is video drivers on the clients. PM support may be able to help. BTW, it probably isn't terribly important, but I think it best if you run the latest versions of WideClient on the two client PCs -- 6.72. Regards Pete

Really? How did it do that? Sorry, that is something I don't recall at all. Can you provide a reference? The only thing to do with default flights was this, in FSUIPC3, corrected in January 2006 after being that way for five years: This cannot apply to FSX because there's no interception of any routines in FSX. The information and facilities relating to Flights is provided nicely by the SimConnect interface. Regards Pete

http://kennethhunt.com/archives/000933.html Thanks! Useful! ;-) Pete

I don't know, I've never tried. It just passes the whole string onto a Windows API to create the process, so if that API procedure accepts these codes then it would work, otherwise it wouldn't. The facilities for %...% are new to me -- I've seen them in other places, but I know nothing about them anyway. What does %homepath% do, exactly? And where did you get it from? Is there a list of these someplace? I suspect that they are macros only recognised by the Windows Shell. Possibly if I executed the programs via Shell calls it would work -- but I cannot do that and also automatically get the process handle, which I need for the other options I support. Also I cannot assume the facilities will be available on all systems supporting FS98 to FS2004. Have you looked at FSAutoStart or other similar programs? I think they can load stuff as well as closing processes you don't need. Whether they use Shell calls or not I don't know. Regards Pete

Good. I'd be grateful if you would confirm this to Simkits / TRC support. Thanks, Pete

No, it can't be okay, because FSUIPC4 is not FSUIPC3. They are different products. An FSUIPC3 keywon't work with FSUIPC4. Please check the documentation, and the sales booths at SimMarket. Regards Pete

Not off-topic. I'n here to answer questions on all my FS-related programs. The main functions of that program were not for FS at all, but more for Radar Contact, Squawkbox, and Project Magenta (and, going a long way back, EFIS98). And of course quite a lot of other programs that can use SBP and FS PLN text formats. I understood that FSX could actually still read older FS PLN formats too, even though it doesn't output them. I've never tried (I use Project Magenta and Radar Contact with FS2004 and FSX). Have you tried? Have a go and let me know. Yes. Horrible, aren't they? Try with the older plans and let me know. If needed I can look at doing an update to produce XML plans but it'll have to fit in between more pressing things. Regards Pete

Ah. Thanks for pointing that out. That's a left-over from the original section there accompanying the previous interim update. That should now read "in a Boxed section in the User Guide", as, of course, as always, it was incorporated in updated User documentation for the main 3.74 release, thus: I would have thought that the subject of this note was obvious from the original text in the Announcement however. Why did you think it might apply to you? It was a new facility, but only available by INI editing, as it said. Hmm. Unless this is a signature or key problem that is indeed rather odd. Nothing is changed in the actual interface that should affect things so much. I always strive to maintain backward compatibility even when adding new features. The log file shows nothing out of the ordinary. Everything looks fine. I am afraid I am at a loss to know what differences your FSCargo program finds between 3.71 and 3.741. Possibly it is making some presumptions about previously unassigned areas of FSUIPC offsets which have now found some use. Either that or, indeed, somehow I have made a mess of somerthing it needs. But I am realy not in the correct position to determine what the problem might be. Sorry. Can you get the FSCargo folks to check, and get in touch with me if there is really a problem. If possible i will fix it as soon as i know. Regards Pete

Only the FSUIPC INI and KEY files, from the FS Modules folder. You'll still need to re-register afterwards, but you can cut and paste from the FSUIPC.KEY file, which is a text file. Regards Pete

I'm not sure what you are really saying, but it sounds like you mean that FSUIPC4 is giving you problems, and that, in fact, IVAP is completely irrelevant. Correct? If so, please tell me exactly what is going wrong, and show me the FSUIPC4.LOG file -- you can get it from the FSX\Modules folder. I cannot do anything at all without any information! I don't know how you expect me to! So you do not care if things are fixed or not? you do not care if other people have problems? Why did you bother to write to this Forum if you don't want any help? If you expect to get help you must surely realise that you must provide some information. How else can anyone help? You have sent many messages already, and none of them actually contain any description of your problems! Pete

I really do hope you do not mean the "first version" of FSUIPC -- you must always use the current, latest, version. 4.09 at present. And as I said, there are no apparent problems using ONE SimConnect client. SimConnect seems to have problems with MULTIPLE (i.e. more than one) clients when FSX gets busy. You say IVAP works without FSUIPC4. Try FSUIPC4 without IVAP. That works too, right? Together: 1 + 1 = 2, that is MULTIPLE clients for SimConnect, and that's where, when FSX gets busy, it falls down. There is NO INTERACTION between FSUIPC4 and IVAP, it is NOT FSUIP4 causing problems for IVAP, just as it isn't IVAP causing problems for FSUIPC4. I know you don't understand English, but please get this translated properly so I don't have to keep repeating myself. I might be able to help a bit if only you'd provide some information, but you do not! Regards Pete

I'm sorry, I don't know. They won't be specifically problems between IVAP and FSUIPC, but instead both with SimConnect (part of FSX) -- it is known that SimConnect can have problems with multiple clients, especially when it gets heavily loaded. There are two ways to find out more -- look at the FSUIPC4.LOG, in the FSX Modules folder, and check SimConnect. Ways of getting SimConnect Logs and of re-installing SimConnect are provided in the FSX Help Announcement above. We are hoping that the forthcoming SP1 update for FSX will fix a lot of the SimConnect problems people are facing, but whether it does or not is unknown at this time. Regards Pete

I've no idea what you are asking I'm afraid. If you want some help please try to describe the problem, not simply say "it has never worked" which doesn't really help at all. Also please state the versions of everything involved, -- if not the latest supported releases, try those first, and show the FSUIPC4.Log file so I can see if it is one of the known SimConnect problems. And have you asked IVAP support? Regards Pete

FSUIPC doesn't get involved in any of that stuff. It sounds like some add-on program is doing things. Can you please detail all the add-on programs you are using? No, you never have to make changes in the INI -- where did you read that? Start FS with FSUIPC 3.741 installed, get the problems, close FS down, show me the ocmplete FSUIPC.LOG file please. Regards Pete

USB ports are simply the "new" serial ports. The name isn't "COMn" that's all, but something more complicated and longer. There's an example someone provided me in the GPSout docs. I think the main problem with GPS's is that the USB connection connects to some sort of Active Sync driver which you will have already installed. It is not easy to disable that to free the connection for other programs. On top of that, whilst the 396 may be okay (I don't know), very few GPSs actually provide any way to feed in positional values to override their in-built GPS system -- and many of those that do do so for external antennae systems which have a totally different type of output. The few GPSs which do allow NMEA positional or Aviation input are specialist aviation GPSs. There seems to be a general misunderstanding that my GPSout system is designed to drive GPS's. It isn't. The very opposite is true. It is designed to make the whole of the PC running FS look like a GPS for those programs, moving maps and the like, which are designed to take their input from the OUTPUT of a GPS -- hence the name "GPS OUT". Ah, well, in that case it will be a matter of uninstalling or otherwise disabling the Active Sync program which insists on grabbing it as soon as you plug it in, and finding the correct port name for the USB connection. It'll be something like "\\.\WCEUSBSH001", as far as I know. Good luck! Regards Pete

Er .. only if you are assigning the axes themselves in FSUIPC. That is clearly documented. The joystick calibrations section can deal with FS or FSUIPC assignments -- the mapping of 2 to 4 throttles is on the 4 throttles calibration page. I'm sorry, but your replies are leading to more and more confusion. What are you using and where? Have you calibrated at all in FSUIPC? In that case it won't be anything to do with the joystick at all, as that will be ignored -- unless of course that PMDG option only ignores the normal "one for all" throttle assignment, and not the individual ones. Also, there are two sets of individual assignments -- the "THROTTLEn SET" ones, which include a reverse zone, and the newer "AXIS_THROTTLEn_SET" ones, which don't. There's an option on the FSUIPC 4 throttles calibration page to avoid interfering with one set -- did you try it? If the IN value carries on rising whilst the OUT value stops at 16383 or 16384, then there is a max dead zone, yes. But surely you'd know this because you yourself would have set it during calibration? Ignore the VC, look only at the main quadrant graphic in the 2D panel. I don't believe half of the VC graphics. And for more accuracy, seeing exactly what is going on, compare the changes in IN values in relation to the OUT values, in FSUIPC, as you move the lever. Regards Pete