Pete Dowson

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

There is only one version. I don't know if PFC supply one on disk or simply advise you to get it from their website. Either way you'll usually find the one on the Schiratti site to be more up to date. The current version is 3.40. Updates to the PFC.DLL will also normally appear quicker on that site. Regards, Pete

If FS2004 causes WinXP to crash and re-booot, it is something to do with a driver somewhere. no ordinary software can do that. It is probably either the video driver or the sound driver that is crashing. Sorry, i'm not an Airbus pilot. What does "+" "+" to flex mean? I don't know -- is there some sound that would occur then? Perhaps you should ask PSS support? Okay, so it loads a default flight not one you saved? Then you create a new flight rather than load an existing one? Regards, Pete

I now have all the PSS aircraft and I cannot make any of them fail. I really don't think it can be anything to do with FSUIPC -- changing versions merely changes memory arrangements a little. It does sound like there's something wrong in your FS installation somewhere. One common case of odd crashes is corrputed WX files, loaded with your Flights. The other possibility is sound -- wouldn't the cockpit voicing start saying something then? Maybe there's a bad sound file or problem with the sound driver. Try, temporarily at least, removing your FS9.CFG file so that FS makes a new one and boots with defaults. Then create an entirely new flight with the aircraft and try that. Wait a mo', are you flying FS2002, not FS2004? This is with an FS2004 version of the aircraft? What's WXP? Regards, Pete

But surely it depends on the weatherdifferent surface visibilities, cloud cover, etc? That's why I suggested using your FLT + WX files, to make sure I am looking at the same thing. There are too many variables otherwise. I just looked at the FSUIPC.INI file paramters you are using. These are the Visibility settings: You have something wrong there, which will probably make things not work right in any case. Your "Minimum Visibility" is set to 80 miles (8000), which is actually more than all your upper limits!!! Why tell FSUIPC to never let your visibility get below 80 miles? Strange. The default is 0, allowing thick fog when the weather says there should be. Without checking the code in FSUIPC, I'm not sure what this odd setting will do in practice, but it is certainly quite likely to ruin any attempts by FSUIPC to give you what you want! I'd also recommend setting the lower graduation altitude to 0 (in the Visibility Options) so that there's no gap between FS's visibility layer and the start of graduation. This is mentioned in the documentation. 33,000 feet is above the graduated visibility range in any case. Did you really mean that? From 20,000 feet, using an nVidia card, I get no flickering horizon, and in fact I only get a sharp horizon if the visibility value allows that. (There aren't any mountains in the UK which give a markedly bumpy horizon from high altitude in any case -- this is partly why I think the specifdic scenery is important if you want to compare things). As visibility is reduced, the horizon "fuzzes" -- the surface is still dark compared to the sky, of course. It looks quite good. I do have a Radeon 9800 in another PC, but it isn't switched on at present, it's in another room. I can try it later, but first please sort out your FSUIPC visibility options and see what you get. I still maintain that using the same FLT+WX files is still the only proper way to compare things. Regards, Pete

I've not seen any differences like that. Is this anywhere or just in certain locations? With default scenery? What is your weather source. If you can reproduce it with default FS scenery (and aircraft), save two Flights, at the two times with the same view, then Zip up the pair of FLT + WX files and send them to me at petedowson@btconnect.com. I will see if they look wrong on my systems, so we can perhaps deduce whether it is a video effect or something else. Mot sure what you mean by that. do you mean there is some "mist" but it is somehow flickering, or is it some part of the scenery sometimes re-drawing? The latter is often due to video card or driver problems I think. Regards, Pete

That's fine, as long as you understand that it isn't supported any more. No, because registration wasn't introduced into FSUIPC until version 3.00. Maybe the gauge is written only for FSUIPC 3 or later? I really don't know, you'll have to ask the author. No, that cannot be. The gauge's attempts to register will do no harm in versions of FSUIPC before 3.00, they'll simply be ignored. The gauge won't know or care either way. Regards, Pete

I didn't say the 96 couldn't. I don't know anything about it. All I said was that just because it provides NMEA 0183 support for output to a PC (as they all do I think) doesn't mean it accepts it as input from a PC. I'm not sure, but I think the other two you mention don't even use NMEA 0183 format for input in any case? Aren't they the ones with "Aviation 400" protocol supported, which I added to GPSout specifically? Please see, for example, this thread: http://forums.simflight.com/viewtopic.php?t=16610 Really, you need to refer to the documentation you should have got with your GPS. If it is possible for it to be set into a "slave" or "simulation" mode, bypassing its own receivers, then it should tell you somewhere in the manual how to do it and what protocol it uses. I'm afraid I only know about the units I have, neither of which will do this at all. Regards, Pete

No. It means little. Almost all GPS's, and certainly all Garmin ones I know of, support NMEA 0183 for output, in the same way as my GPSout does. Don't forget that the whole principle of the GPSout module is to make the entire PC + FS + GPSout system look like a GPS which is outputting standard NMEA 0183 data, for input into something else which understands it, as an input. It is quite unlikely that any ordinary GPS will act as a slave moving map or something like that for another GPS. I have two Garmin GPS devices, both outputting similar NMEA 0183 sentences to those provided by GPSout. Neither accept NMEA 0183 positioning from outside. They have their own aerials and position detection systems, and the only input they accept which can override that is some external aerial/beacon input which is certainly not NMEA 0183 at all. Regards, Pete