Pete Dowson

WideFS does nothing by itself, it only acts as a channel for your applications, on the client, to talk to FSUIPC and thence FS on the Server. The application can tell FS to close by sending an appropriate control, but if it does that it would do so if run locally, on the FS PC, as well. I don't know Open GC or Free FD but possibly they are doing something FS doesn't like. You could try logging IPC writes (FSUIPC options, Logging page). Look in the FSUIPC.LOG after the closing of FS and see what the last thing written by your application was. Of course there's a possibility that FS closes too quickly for FSUIPC to update the log, in which case this may not help much. If OpenGC and FreeFD are what they sound like, merely separate gauges and so on, then they would mainly only be reading data, not writing it, so it seems unlikely that this is the cause. You'd then need to carry out a process of elimination to determine what is really causing it. certainly sudden closing to desktop with no error message was, and maybe still is, a type of FS crash which was quite common during its pre-release testing, so much so it became known simply as "CTD" ("Crash To Desktop"). I think most of those eventually turned out to be sound or video driver problems. BTW please make sure you are using the latest versions of both FSUIPC and WideFS. Regards, Pete

Sorry, I hate writing manuals as it is. If things aren't clear, just assume that none of the weather facilities are really very useful in FS2004 except the three marked *** on the Visibility page. Ignore the rest and you'll be safe. Regards, Pete

Hmmm. Not sure what's going on there. If this is with FS's own dowloaded weather it sounds like you are moving into areas with either no specific weather (in which case the defaults take over) or just clearer weather. However, you say the winds and visibility stay okay -- this is really the exact opposite of most folks complaints about FS2004's weather, that the winds change unpredictably and suddenly, and the visibility also does so instantaneously (though you should be able to fix the latter with FSUIPC facilities). Sorry, I've never seen the clouds changing incorrectly. Check the weather menu (ALT W W), see if you have weather dynamics set to change things (the slider low on the display). Set that to minimum, see if that helps. Regards, Pete

How odd. I wonder why they do that. Is this is one of their gauges? are you trying to use a mixture of their panel and PM? So far I only ever use one or the other, and only the FS panel for tests (panels don't look so good smeared over 3 screens! ). Is this a patch others should know about? Regards, Pete

I can't really picture what you are talking about, but I think it may simply be the way FS automatically activates the ground spoilers if you arm them on the ground. Try testing them in the air. Setting your "1/4" is probably close the the "arm" detente (see FS's own graphic to see). In the air things should work fine, and you should be able to arm them and have them auto-deploy on touchdown. Do not test your calibration whilst sat on the ground. Certainly both FSMeteo and AS2004 are capable of setting much more complex weather than FS downloads. If your system cannot handle it you may need to change some of the options in the programs themselves, and possibly apply more filters and restrictions in the FSUIPC options as well. You'll need to experiment. Everyone's system is different. This is possible of course, but it is a question for the weather program folks. I really am not in a position to answer. Sorry. One of the factors may be the sharing of the processor between FS and the weather program. You say you get 48 fps without weather programs, which suggests to me you are not using the FS frame rate limiter (Options-Settings-Display-Hardware). If this is the case there might be problems when you run other programs in parallel. Try setting the limiter to, say, 20 or 25 fps. (I have a 3.2G P4 and set mine to 20 fps). I run weather programs on a separate PC, using WideFS. I think this gives much better results. Perhaps the weather programs are doing too much processing, I don't really know. As you have a P4 3.0 I assume it has "Hyper-Threading"? You might like to see if that is working properly. In WinXP you can actually make FS run in one of the two "virtual processors" and any other programs in the other. That may help. Regards, Pete

That's a good idea for a little utilitywhen I have an idle moment, perhaps. Or some little training program for someone learning Visual Basic. Maybe even a decoded section in the INI. But, I'm sorry, I'm really closed down for development for a couple of weeks anyway, with guests and family arriving for the Christmas period already. Regards, Pete

Well, FS2004 certainly doesn't, but I always found FS2002 to be pretty obedient. You could try parsing the text. It is provided in FSUIPC offsets if AdvDisplay is running. The "ShowText" utility packaged with AdvDisplay makes use of this to move the text. I've not really experimented with the range of COM frequencies in FS, sorry. You'd need to try that yourself. FS9 seems to pay scant or no attention whatsoever to runway permissions, at least those set by AFCAD2. I don't know if this is FS9's problem or AFCAD's. Do you have more inforamtion on this? Regards, Pete

The term "minimum weather defaults" is actually meant to include "defaults" as well as "minimum weather" -- it's like the defaults button, but more so. sorry if it is confusing. If you use either, then you need still to re-select any specific facilities you want on. It has been this wat now for three years -- I would have changed it else, but no one has had any problems so I didn't want to confuse matters. The few special FSUIPC hot keys, yes. This is because pressing "defaults" (either) is supposed to set things into a predictable state -- for tests, fault-finding, and the like. It doesn't reset Keys, Buttons or Joysticks however. That would be simply too cruel! :wink: Regards, Pete

I don't really know where you are reading that. Unfortunately, all the FS controls which needs a second key pressed afterwards, like Shift+P for pushback followed sometime by 1 or 2 for turn direction, and Ctrl+E (is it?) for Exit followed by the exit number, seem to need the latter to follow with no intervention by any other keystroke or control. Now, whilst programming these as sequences in FSUIPC is possible (only by editing them in the INI file, as described in the Advanced User's Guide), and this should give you more reliability, it does not guarantee it. Any button action or real key press could intervene (though this is probably unlikely). Worse, however, are those complex add-on panels which continuously send several FS controls, many times per second. It is those which cause the problems with accelerated A/P and bug adjustments. There's almost no chance of getting two normal keystrokes accepted and actioned by FS without one or more of those unwanted controls intervening. For the door controls I had hoped that setting the door number as a parameter to the "toggle exit" control would have been accepted by FS in place of the subsequent keypress, but, alas, it is not programmed that way. Regards, Pete

No, apart from printing the FSUIPC.INI. They are all there of course. Regards, Pete

You use PM and the PMDG panel? I have PMDG 737NG but I don't use the panel, only the panel-less version by you or Steve. If you are using the panel don't you think their A/P coding will interfere? If you were okay before, with the original PMDG 737, what could have changed, and how is the setting overriding PM's existing code to disconnect throttles? I'm not really understanding this. So something is unsetting the "disconnection" made by the PM code? If that happens, the PFC values will be re-applied even if they've not changed. If this re-application isn't permanent it is probably because the PM code is disconnecting it again, but evidently not quickly enough. I haven't got the update for PMDG 737NG, I'm still trying to work outy how to get it (I've asked my contact in PMDG but nothnig has resulted yet), but I'm hard put to imagine what they've changed which could do this. Why are you using PMDG's A/T and A/P with PM? don't you use PM's MCP? But it isn't PM from what you are saying! I don't like making ANY changes without knowing why. Already PFC handles its own A/T controls correctly, and FSUIPC provides PM the means to deal with any throttle inputs. If the PMDG stuff is interacting badly with this it needs to be understood and possibly fixed rather than simply "worked around". Regards, Pete

With the FS autopilot, the Altitude Hold flag is set in Altitude hold, acquire or flight level change mode, whatever -- it makes no distinction. The flag is as documented, at 07D0. If this is set, and the current altimeter altitude in 3324 is not equal to the A/P's altitude setting in 07D4 (beware difference in units) then the V/S value is 07F2 should be non-zero and indicating the appropriate climb or descent. When it goes to zero the set altitude is acquired, or very nearly so. Pete

Why mention FSUIPC 3.135 in this? It is not involved. AdvDisplay is a separate (free) module. AdvDisp doesn't have any hotkeys (at present) so it isn't doing anything with F9, and docked or undocked AdvDisp is doing the same thing, merely sitting there. Probably you have left it with the keyboard focus (blue title bar or whatever? Just click on the Fs window to make sure it has focus. The AdvDisp indow will appear if (a) it is docked to a currently active panel part, or (b) if it is locked, or © is it is neither docked nor locked but is active. It is supposed to be on top of other FS windows, else it would be useless. So, if FSNav is "another FS window", it should be on top of it. None of this has changed for years. As for AdvDisp menu's getting hidden behind its own window, I've never seen that, but all the menu and window handling is standard Windows functions, so it may be a Windows problem. Are you using Windows XP? Is it fully updated? Regards, Pete

Yes, all version 3's have done that -- not necessarily grey, though, usually multiple copies. It's the only way to display the thing on top of the full screen version of FS without constant flicker. It doesn't matter any,they all get erased on exit. Pete

No. To do that it would have test V/S for zero and set something non-zero when it was. There's no point in that, and it just means more work to do continuously in the FS process. Regards, Pete

3.129 is no more. Use 3.135. Old versions aren't supported in any case. Pete

The documentation refers to http://www.schiratti.com/dowson. The announcement listing current versions at the top of this very forum refers to http://www.schiratti.com/dowson, and oddly enough the very same http://www.schiratti.com/dowson has featured all my FS programs now for many years, and hasn't changed its site or name once in all that time! Isn't that good enough? Why would you need to keep searching when almost everything possibly tells you where it is, and, even more, it has always been there? :( :( :( Pete

500 mSec cycle time? Good grief! How are getting it to go that slow? On an average modern PC with FS2002 you should be easily be able to match FS frame rates, though I would suggest keeping it down to around 20-30 per second if possible. The normal Windows timer tick of 55 mSecs (18 fps) is usually a reasonably good start. Sorry, I really don't know how you've managed to make it so slow. Visual Basic doesn't help of course, that's pretty slow in itself, but still. Is it perhaps the serial port side? 9600 baud isn't very fast -- 960 cps. Maybe if you are transferring hundreds of bytes per cycle you will get down to 2 fps quite easily. There are many examples of applications which run as fast as FS -- Project Magenta, for instance provides instrumewntation on one or more client PCs on a Network, with data from FSUIPC being fed via WideFS, and still achieves 20-40 fps without problems. I think so. There may be a limit on size, but many folks here do seem to attach pictures. I've not tried it myself. Regards, Pete

Sorry, I'm not understanding you. FS certainly does something of the sort you mention. Are you wanting to know WHEN it does it? Just reading the autopilot V/S value should tell you, surely? If this is not what you want to know, what is it please? Regards, Pete

Whay IS going on with your PFC equipment? I have a basic throttle quadrant system a Cirrus 2 and a Jetliner Console and they al behave impeccably! It's the other way around, PM disconnects the throttles except in descent mode (I think). Check with Enrico. Also, for use with FS (not PM), if the PFC A/T switch is used, the PFC driver disconnects the throttles and re-establishes values on return. All this has been okay for two and a half years, it isn't as if it is different now for any reasonwhat have you done to your PFC/PM setup to achieve such behaviour??? Regards, Pete

The FSUIPC PTT control is for a local AVC or RW. for WideFS you need to program a pair of KeySends and add KeySend definitions for RWon and RWoff into the appropriate WideClient.ini. This is described in both the WideFS and FSUIPC documentation. Regards, Pete

Correct. There certainly isn't if you use FS2000/FS2002 with FS downloads. the default Global weather it provides is basically - no weather. And if you are really after realistic temperature gradients I don't think you can use FS2000/2002 downloads at all. Try FSMeteo. [global] what about injecting a `representative' temp and wind profile into Global such as prior to departure?? .. so that at least there are some temps available when `outside the triangles'.. ie: FS goes weather braindead? :? Doesn't happen with FS weather downloads. The default global is part of the download. Your only solution is to change over to an external weather program, or move on to FS2004. Regards, Pete

This is not actually a realistic action, and you certainly shouldn't be forced to enter that data. I think the normal practice is to leave a discontinuity after the initial approach fix for the general direction of your approach. You fill in the STAR and arrival runway later, usually on instruction from ATC. In cases of radar vectors to approach, which is more often the case at main airports, you'd only insert the runway when assigned. No way I know. ATC isn't even active at airports out of range, as nothing is happening there until they are in range. FS doesn't really want to be simulating the whole world all the time, only the bits that matter. The best you can do is guess from the forecast weather, which may of course change by the time you get there. Regards, Pete

That's quite understandable, though you should note that the concept of "slots" and the way they are handled is purely an FSUIPC implementation, to suit the "memory-map" image that the IPC interface uses. In reality the information you see in those slots comes from all over the place inside FS, it is gathered for you and formatted as you see it by FSUIPC. To do this involves many calls into different parts of FS, which is why there is a "Traffic Scan per Frame" parameter in the FSUIPC INI -- so the sheer processing doesn't affect performance on lesser systems. If you want faster, smoother updates (for instance, for a graphics display), set that parameter to 100 in order to make FSUIPC scan al the traffic on every frame. Version 3.135 of FSUIPC is being released today, along with a revised edition of the SDK. Regards, Pete

By sheer coincidence there are facilities to help in this in the new version of FSUIPC, 3.135, being released today. The details of how to do this will be in a revised edition of the FSUIPC SDK which should also be released today (I am just putting this together now). WeatherSet2 can demonstrate it in action. I have only achieved this be checking the runways allocated to AI traffic -- the ones as currently displayed by TrafficLook. If there is no AI traffic currently assigned a runway at your chosen airport, then I cannot determine the ones which will be allocated. Furthermore, AI traffic is only generated within a range of about 80-85 nm from your own aircraft, so you cannot get data from further afield. Regards, Pete