Pete Dowson

It's a bit odd then that I've never heard of that happening before. As well as WideClient wanting to use TCP/IP on start-up there are many other programs doing this, which actually install that way -- I use Mailwasher, for instance, which starts up with Windows and checks your email for you, immediately. I really find it hard to believe that Windows would dare start any object program before starting its installed services. Regards, Pete

Not at present, no. For many years now it has done its check for the Server at start-up, and if the Server is unknown it has always issued a failure. I always thought that was unrecoverable, but it seems you've found a case where, somehow (even if the Server PC is up and running?) Windows just doesn't know it. Yes, that confirms the problem is that Windows doesn't know the Server. At that time is the Server PC switched on and ready? (not necessarily with FS running -- Wideclient will wait for WideServer). Same here, but I don't think it is that. If you don't use fixed IP addresses for each PC, that could be a problem (and it isn't a good idea in any case as it can lead to performance impairment -- stutters etc). If you are using fixed IP addresses, see if it will connect using that rather than the name. I will certainly consider changing WideClient so that it keeps retrying this "unrecoverable error", but I can't do this immediately. Let's see how you get on first in any case. Regards, Pete

Processor: P4 3.2 GHz, 1Gb memory System: Windows XP-Pro including SP1 (not SP2), and, I think, DirectX 9.0c but it might be 9.0b Video: Matrox Parhelia 256Mb Flightsim: FS9 including the update FS9.1 Add-ons: Almost everything I think! Not sure there's anything useful you can get from that, though. Regards, Pete

Seems odd for Windows to try running programs before basic services are available. I would tend to think it more likely that it cannot convert the Server Name into an IP address. However, a Log showing the error would be useful, that may tell us. I could maybe consider retrying the connection every few seconds until a connection is successful. Maybe display a Message Box with the error after n seconds (adjustable), but perhaps even then continue trying until someone clicks an "Abort" on the error message. I'd clear the message box in any case if a connection was later obtained. I think it used to retry but message boxes used to pile up, one upon the other, so the fix was to make such an error fatal. Maybe it is time to reconsider. I'd like to see the Log first though. Let us try to understand what is happening first. Also, try specifying the IP address instead of the name (I assume and hope you are all using fixed IP addresses, not having those also allocated for you? Otherwise this can also be a problem, and certainly a common cause of stutters and jerks). Regards, Pete

Good, well done! Thanks for confirming. Good flying now! :wink: Pete

It sounds like something isn't ready in time to support the link, or perhaps the Server isn't ready. Why not check the WideClient Log file to see what error is reported? Maybe the connection is being attempted before the names of the connected PCs (the Server in this case) have been discovered -- I assume this might happen if your "name server" is not ready/accessible/running at startup. If this is the case, why not try specifying the IPaddress in the INI instead of the name? Regards, Pete

Sorry, you can disagree all you like, but I think you are wrong. By your own admissions, you didn't even bother to install FSUIPC and look, or even scan the documentation to see what options there are. Please, why don't you go and do your own proper investigations before coming here with what appear to be unfounded accusations? It will only do that if the options are selected, and it can only do that for the base (default) global weather. There is a single button (originally designed for WidevieW clients) to clear down default options in any case, and for FS2004 there's a checkbox on the Technical page which, if not selected, stops FSUIPC changing anything but weather injected via its own interface. Note that other weather programs, FS's own downloads included, do not suffer the problems you describe in any case -- surely, if your theory was true there would be a general outcry against FSUIPC's alleged "interference"? I'm sorry, you may well have problems but I think you are diagnosing them incorrectly. If you would like to back off a little from what appears to be some amount of agression and discuss things reasonably, maybe we can move forward. To me, it sounds more likely that there is some conflict between the way your program accesses the FS weather facilities, and what FSUIPC is doing. I would certainly be willing to cooperate in sorting that out, if possible, but I would need to know more, as is seems so would you. I do not fly on-line and do not want to start now. I can look and try to determine what interaction is going on if you can provide some easy to set-up test version of your program which doesn't need to be online to show the symptoms. Otherwise I suggest that you look to see why your weather access is causing this, from your end. Okay? Regards, Pete

I think thart's one of the dangers of SP2 -- it changes a lot of stuff on your network to "protect" your system. This is why I have avoided installing SP2 so far -- I really don't have the time nor Network/WinXP knowledge to sort all that stuff out. It will undoubtedly be due to the protections, firewalls, filters, whatever, which WinXP SP2 has "adjusted" on your behalf. If the SP2 documentation or help is insuffiicient I suggest you post on the FS2004 forum, ask for Katy Pluta. She is a big advocate of SP2 and also the best Network expert I know. Regards, Pete

Version 3.30 will most definitely NOT work on a properly updated FS9.1. That is a 100% certainty. It sounds like your update didn't work after all. The FS DLLs in the Modules folder should be dated 1st September 2004. Are they? That sounds like FS is not actually closing down even though it looks like it is. Check using Ctrl-Alt-Del and see if the FS9.EXE process is listed. If it is you'll need to terminate it before re-running it. If this is hapening it sounds like you have a partially updated FS2004 which is misbehaving. Run the FS9UpdateUninstaller and re-install. I don't know how you managed to get into such a mess though. Normally it either works or it doesn't. When it doesn't it's one of the reasons MS lists. Regards, Pete

Sorry, I don't know FSBus. I know it uses FSUIPC, but what part of FSBus doesn't work? There's nothing at present I am aware of that wouldn't look the same through FSUIPC with or without the FS9.1 update. If you can be more specific about what "does not work" means, then maybe I can help. There is also a possbility, of course, that FSBus has other dependencies in FS than just FSUIPC. Is there any FSBus support at all? Regards, Pete

Yes, but they probably know in any case. I sent them all the details from the logs I got a while back, and also offered to try it here. That is why I now have the aircraft and have tried it, without seeing any problems. All I've succeeded in doing is proving that it isn't FSUIPC and to help narrow down which part of their code it may be in. I believe the chap I contacted doesn't know the aircraft and was passing it on to someone who did. I've not heard anything further -- I would expect them to deal with this through their support forum from now on, not through me. Regards, Pete

Correct, the user registration is certainly irrelevant. The PSS cockpits do all now register their access correctly, and that is all over and done with fiarly quickly after you load the aircraft. It is working perfectly here, too. I think it is working well for most folks, and the PSS staff cannot reproduce it either. It is evidently a very context-sensitive bug. Of the two original correspondents here, one fixed it by reinstalling everything (!) and the other, as we've just learned, by disabling some virus and firewall stuff. If upgrading to FS9.1 doesn't help then if you don't want to try a complete reinstall or any other drastic changes, all that can be done is to try to help PSS support reproduce it on one of their systems. If it were within the calls it makes to FSUIPC I could certainly add extra logging to diagnose what was happening, but there is really no way I can do this in someone else's code whilst they have control of the machine. I would have hoped that the little information we have already provided to PSS would help them narrow it down, and maybe they can add diagnostics to their own code, but this is really between them and those with the problem to resolve. Regards, Pete

It definitely is not FSUIPC, there is really no involvement of FSUIPC during these "freeze" periods. This has been proven in the various logs and tests we've run. Furthermore, there is no changes in FSUIPC in the small areas of it that the PSS cockpit uses. Really it is almost completely independent of FSUIPC. If merely changing the FSUIPC version you are using has an effect it will be because there is a problem there which is either due to use of unitialised memory being used as if it is initialised (this is my theory -- which would make it an obscure Dash8 gauge bug), or there's something else in the system which is interacting and in ways which are exctremely time sensitive. Changing almost anything opering in the FS process could have an effect. I would strongly suggest that you update FS to the now-released FS9.1 then try again. It may not fix the problem, but it may make it go back into hiding just because of the small memory usage and timing changes that will achieve. Regards, Pete

I got a quick reply from Enrico -- he fixed it in build 388 of the MCP, available in his "latest versions" section. I've not had time to try it yet. Regards, Pete

I have NAV so it isn't that, but I dumped Sygate long ago as it used to cause me all sorts of grief. I don't know AVG. No, it really won't be anything to do with FSUIPC. that's a red herring. But you may want to post your findings in the PSS forum. Good flying now! Regards, Pete

See if the FS2004 crash you are getting is fixed with the official FS9.1 update just released by Microsoft. See my announcement at the top of this forum. Regards, Pete

They are correct. There's no "C0265". Are you sure that isn't C2065, which would be correct? First, please confirm you are using the current supported versions of FSUIPC (3.40), and, if relevant, WideFS (6.401)? All the PM controls do is change bits in the PM offsets as documented in the PM FSUIPC offsets document on the PM website. Those two controls merely set the documented bits, as shown in that document thus: You can monitor this location (5418) in FSUIPC's monitoring facilities -- see the Logging options, right-hand side. Set 5418 as the offset, type U16, and opt to show it by AdvDisplay. Then you'll see what happens in real time. Note that depending on what builds of PM modules you are using, this may or may not need the MCP module running too (or the Airbus equivalent). I think Enrico was trying to make most of these things work more directly, but I'm not sure which builds do what now. I've just checked here with Boeing PFD build 416 and MCP 387, and with these builds at least the PM side is defintely broken -- the bits are being set correctly by FSUIPC and they are being cleared by something in PM, but they are not being actioned at all. I'm afraid you now need to call upon PM support! Feel free to copy my reply from here. I'll drop a note to Enrico, but a formal report to the support address should be made. Regards, Pete

So you just mean there is more than one function for one or more buttons. As I said, that is what will happen if you assign a button to do one thing in FS and another in FSUIPC. Just make sure you only use one or the other, not both. Do you mean you don't mind throwing away the use of your buttons and using your keyboard instead? That seems drastic! Surely it would be better simply to make sure you assign one function to each button instead of confusing the issue with multiple assignments. The Keys options are not "stronger" at all! I don't know how you read that. It's just the FSUIPC can intercept the keyboard whereas it cannot intercept FS's use of DirectInput to read button pressing. Therefore, when you assign a keypress to a control through FSUIPC it replaces any keypress assignment in FS. It can't do that for Buttons. Regards, Pete

I'm not sure what you really mean by "crossover", but if you want to assign buttons in FSUIPC you should certainly make sure they are not also assigned in FS -- both will be acting on them if you do this. FSUIPC cannot stop FS seeing the buttons. It is not the same with the Keys facility, where FSUIPC intercepts the keyboard and diverts any re-programmed keypresses. Regards, Pete

The yoke and pedals are handled by the controller card inside the throttle quadrant. This operates like a superior game card, if you like. The link between the console and the PC is not a "joystick" or "gameport" link at all but a bi-directional digital link handled according to a PFC devised protocol supported by PFC.DLL. If you download the PFC.DLL package from http://www.schiratti.com/dowson and look at the documentation I provide, all should become clear. I just had a quick look at the PFC website and see that their offerings of PFC driver and FSUIPC are both well out of date. I advise you to get both from the Schiratti site in any case. Regards, Pete

The Flights you sent were almost identical, one being 4,000 feet higher than the other, but both at the same time of day (within 10 seconds). So I advanced one on to dusk/sunset. I notice you have 20 miles visibility set all the way from ground to nearly 50,000 feet. Rather unrealistic of course, which is perhaps why I've never noticed your 'problem'. Also, of course, this stopped FSUIPC from having any affect whatsoever. FSUIPC isn't a factor here. I've tried it on three different cards: nVidia Geforce 4 Ti 4400 Matrox Parhelia 256Mb ATI 9800 XT with slightly different results on each. Maybe some of my anti-aliassing settings or anisotropic whatnots are also different on each. I've really not time to experiment nor do I want to mess my normal settings up, as I quite like them! :wink: I get no flickering on the horizon on any of them. I really don't know why you are getting that. All three do give a sharpening of the horizon line as the contrast between a lightish sky and darkening ground increases. This is most noticeable on the ATI card, where is seems to occur all the way around the horizon, though more noticeable towards the brighter part of the sky (with the setting sun, especially). I also get some odd artefacts in the sky on the ATI -- these look like different shading areas not smoothed out correctly, so maybe I will try changing its settings a bit. On the Parhelia the effect was less, though again more so towards the brighter part of the sky. It certainly seems to be the increasing contrast between ground and sky which I assume is defeating the card's "fogging" effect. The nVidia was certainly the "best" (depending on what you like to see). On that a fuzzy area remained along the horizon line all the way around, just excepting where the sun was setting which breaks though quite nicely. Overall, I would find any of the results acceptable, especially at that sort of altitude. You evidently don't like the effect, and maybe you can lessen it by increasing whatever smoothing facilities the card possesses, because I think that is the only answer. I would guess that the difference here between FS2002 and FS2004 is because of the way the misting/fogging is now handled in DirectX and the video cards --- the more contrast it seems the less effective the fogging. I've not really noticed this before because (a) I don't normally like settings which try to give such reduced visibility at high altitudes and (b) I would have probably regarded the effect as quite attractive and not noticed it was "bending" the visibility constraints at all. Regards, Pete

I presume you are talking about assignments in FS? It is likely that FS has automatically assigned the same functions to the same buttons/knobs, yes, because it simply looks up your device in its "Devices" file and makes the assignments that file tells it to. Go into FS's Options-Controls-Assigments and change them to do what you want. The drop down list of recognised devices will probably show two identical devices as you have such connected. It isn't easy in those circumstances to tell one from the other, you will just have to make assignments and try them to make sure you are dealing with the correct copy of the device. Regards, Pete

Never heard of a USB version. Probably they built a serial-USB adapter into the base. They a;; used to have a 15-pin game port plug on, but the circuitry inside the unit is a bit different depending on whether it is designed for a real game port, or the 15-pin connections on one of their consoles. That's what I said earlier. (I thought you said you didn't know, or at least you implied you didn't know by your questions). Sounds like you've sorted it out now. Regards, Pete

Is there really no information on their website these days? Serial port 9-pin for the Console. The cable comes with it. The pedals and yokes have 15-pin game port type connectors but they will plug into the rear of the console. I think they will also work, but not so well (and without the yoke buttons correctly working) if connected to a game port, but if you wanted game port connections you should have specified that when ordering. If you ordered them with the throttle console they would probably assume you meant to connect them that way. I must admit that I am a little surprised that you ordered all this stuff without any knowledge of it at all. Regards, Pete

You ordered the game port version of the yoke, not the one connecting via the throttle system? If so, then, sorry, that is not handled by any of my software. The PFC driver I prepared for PFC equipment only operates via the COM port. Game port drivers are something separate. PFc make all sorts of things, but all the stuff my software supports connects to a serial (COM) port. You can use USB with a USB to serial adapter. None of that is anything to do with game ports. You can buy a game port version of their yokes, for use without the throttle system, but the latter connects to a serial port and yoke and pedals connect to the throttle system. The latter contains the controller.. You need to find out what you've ordered. PFC is the place to ask questions about PFC equipment. I am not PFC and only know about the serial port stuff, which is all I have. There's a lot of USB equipment around which is basically serial port implementation using a serial port USB driver in the PC. This is fine. Serial protocols run well on USB, and it is easier for manufacturers then to use existing generic drivers. USB drivers are a pain to write and even more so to debug. I won't go near USB. If you want to know more about my software just go to the Schiratti site and download the PFC DLL package, read the User Guide. Regards, Pete