Pete Dowson

Sorry, no. It was one of the questions I put to Microsoft during development, but their answer was that, basically, it isn't possible at present. No doubt there must, somethere, be graphic instructions with xyz coordinates, but the graphics side of FS is a complete unkown to me and I wouldn't know where to start I'm afraid. Most of the interest in this short of thing was/is for decent and accurate weather radar. There are some weather radar programs about which appear to do a good job, though presumably they are doing it on a "macro" scale (based on weather reports from the different WX stations) rather than on the micro scale in which you'd be interested. However, you could ask the authors of those -- provided you aren't competing with them (they are commercial) I don't see why they wouldn't help, assuming they did know something. Regards, Pete

Since both GCs are basically reading the same small amount of data from FS, through WideClient, the problem can only be that they do not like competing. Perhaps it is your video card -- many cards (or drivers) do not support OpenGL acceleration on more than one window. I use a Parhelia which certainly does not have that problem. I know Ray Proudfoot tried two GC windows on one nVidia based card and also had stutters. This is really a question for Enrico, the author of PM, but my advice is to display all your instruments in one window, not two, using one copy of GC. If your video driver does not allow you to stretch the one window over two monitors, you either need a newer driver, or maybe you have chosen the wrong mode. Regards, Pete

Nor I, sorry. Have you no access to the PM newsgroup? Pete

Yes, it does, unless one uses Timer to limit its access. Best to use a stretched window with all the gauges you need. Regards, Pete

Please check the WideFS documentation! That parameter defaults ON. You need to add the line I suggested to try switching the joystick scanning off. That's why I suggested it! It defaults on because on all systems I know of it does no harm whatsoever. Ah! I have the GC running three times on one client, and it stutters very badly UNLESS I set UseTimer=On on two of them. They compete for WideClient's attention and this causes havoc. If one is the PFD/ND and the other is EICAS, set UseTimer=On in the EICAS. Really it is MUCH smoother if you only run one copy. Try one stretched window with both PFC and EICAS. I am waiting for a version of the PFD.EXE which provided PFD/ND for both pilot and copilot, plus EICAS, all in one wide window. Also try TCP/IP again (with default WideClient settings) when you've done this. If you posted these things in the PM Newsgroup I'm sure several folks will advise you about all this. Regards, Pete

And you got IPX/SPX working? Phew! It was mainly because I could never get any satisfactory results with IPX/SPX with WinXP that I spent so much time getting TCP/IP operation up to scratch. Now it is much smoother. In that case it must be something else causing the stutters. Check the list of processes running, ask Katy or others in the PM group. Of course, do not disable TCP/IP on an XP network (though Win98 worked fine with only IPX/SPX installed). Best if you ONLY have TCP/IP, though, if possible. I don't know Pic2. I only ever set the address in the place you have, in Pic1. Nor I! :? I am out of ideas. Sorry. BTW, did you try, as I suggested twice now, disabling the joystick scanning in WideClient? You've not answered that one yet. Also, do you have "UseTimer=On" in the PFD.INI of PM? If so, change it to "Off". I don't think that is good unless you need to run more than one copy on the same PC. Regards, Pete

Please let me know what you get from Marc. I've not heard from him in a long time. Perhaps "real" work is taking him away from FSMeteo developments. Regards, Pete

That sounds EXACTLY like the stutters caused by Windows (expecially Windows 98/95/Me) when you have TCP/IP installed on the network, but have not assigned fixed IP addresses for each PC. (What Windows version(s) are you using?). Other possibilities for regular stutters like that are memory managers/tweakers and anti-virus activities. I am pretty sure that you have some process, nothing to do with FS or WideFs, causing this. It may not be one closed automatically or easily with EndItAll. Check also with Katy Pluta on the FS2004 forum, or in the PM Newsgroup. BTW you responded to (quotes) and earlier draft reply from me, which I sent unintentionally -- I edited it afterwards. You might want to reread it, just in case. Regards, Pete

It does sound like you do have something wrong with the network then. Have you removed/uninstalled IPX/SPX throughout? I don't think it's good to have more than one protocol enabled. Also, for TCP/IP you should ensure that you define fixed IP addresses for each of your PCs -- don't let Windows assign them automatically. There's a lot of expertise on this stuff in the PM newsgroup. You may want to talk to the folks there about it, see what suggestions they come up with. Whenever I get network problems it's a matter of trial and error changing this, that, or the other, till it works nice. Then don't touch it ever again. :wink: Leave the performance-related WideFS parameters to default though. You can get into a real mess changing those. It took several beta testers and I several months of fiddling about with them until we arrived at good defaults, back when I first changed over to TCP/IP. BTW, did you first try cutting out the joystick scanning as I suggested? That would have been the only difference from 6.101 to 6.22. Regards, Pete

Only if the USB connection at the PC looks like a "COM" port (check the System-Device Manager). GPSout cannot handle a USB connection which looks like a USB connection -- in fact I don't know of any definition of a GPS protocol for use on USB unless it is emulating an RS232 connection. Regards, Pete

Thanks for the information. I can possibly understand the second, assuming you are using Windows XP or a mixture of XP and 98, but the first one has me rather baffled, as the first thing WideClient does with the PC name is ask Windows to translate it into an IP address. If it cannot do this, WideClient wouldn't get as far as trying to connect. (WideClient does actually log the result). Hmmm. Puzzled ... Regards, Pete

Just "UseTCPIP=Yes" (it will default to this in any case if you delete the one saying "No"), and, in the WideClient.ini files, "ServerName=". Let everything else default. Pete

Such a regular pause sounds like the work of either an anti-virus program, or a memory optimiser, or, possibly, the TCP/IP protocol being installed on the Network (even if not used by WideFS) and IP addresses not being fixed on each PC. Since as long ago as version 5.50 WideFs has been tuned to work smoothest (not necessarily fastest) with TCP/IP. This is because IPX/SPX is problematic with Windows XP, which most folk are moving to (quite sensible in my opinion). Smoother operation is preferable to fast but jerky. Anyway, try leaving the parameters to default, I think they'll work better that way even with IPX/SPX. I assure you there is absolutely no difference in the handling of the Network between versions 6.101 and 6.22. Going back to 6.101 will not help at all, and I certainly cannot supply it or support it. The only changes between the two were the addition of joystick scanning and a speed up on initial loading. The change in version numbers was more to do with Beta test trials and matching changes in FSUIPC. If you like, you can try cutting out the joystick scanning -- maybe you have some strange USB or other joystick driver on the client which causes delays when queried by WideClient. To switch it off merely set "ButtonScanInterval=0" in the [Config] section of WideClient's INI file. Regards, Pete

The timing will depend upon the closeness of different weather stations. It seems to be a bug in FS2004 -- the wind actually reverses (180 degrees) in certain circumstances, related, it seems to whether the wind changes upwards are clockwise (okay) or anti-clockwise( problem!). The same occurs, reproducibly, even with FS's own weather downloads. Flying in areas with few nearby weather stations should reduce the problem. The only other way to get over the FS bug, will depend upon actions taken in the Weather programs to ensure clockwise winds only, and possibly to do some smoothing of their own between nearby stations. I think the authors of both ActiveSky and FSMeteo are working on this, but I have no idea how it is progressing. Sorry. As it says, that option along with all the other smoothing options (except visibility) only applies to Global weather. Unfortunately global weather doesn't actually work (it doesn't STAY global!) in FS2004, and the newer weather programs set local weather stations, and on the whole this works a lot better. In FS2002, and before, only Global weather was being used by any of the weather programs. it was possible to control this 100%. Not so in FS2004. Well, the wind transitions facility in FSUIPC was added to deal with a bug in both FS2000 & FS2002 whereby the wind could reverse when flying between or near the altitude at which one wind layer definition ended and another began. The FSUIPC transitions took care of that. Certainly, that bug is fixed in FS2004, so that reason for wind transitioning is no longer valid. The other reason it isn't implemented is that it isn't possible using local weather, and global weather doesn't stay global in FS2004. BTW there has been lots of questions and discussions about this over the last 8 months and all the resulting threads are still here. It may be informative for you to browse through some of them. Regards, Pete

I don't know anyone who has written a GPS program for FS9 which runs on a PDA, let alone via a USB connection. Sorry. You certainly can't separate bits of FS itself onto other PCs, let alone PDAs. Regards, Pete

Sorry, no. What version of FSUIPC is this with? Tell you whatI'm emailing you my current test version (3.207). Please try it in that. I'll explain to you how to get more information in the FSUIPC.LOG file also. Regards, Pete

You posted this twice in two separate threads. Please check my reply in the other one. Thanks! Pete

No, all keypresses are equal as far as FSUIPC is concerned. It simple uses the "SendInput" API to send whatever you tell it. Maybe it is to do with how long you keep it pressed, or maybe it's to do with the "hold" as opposed to "pulse" methods in FSUIPC -- I've found a bug in that option selection which I've fixed here ready for the next version (end of the week). But for both "W" and the ATC control there are FS controls to do the job, which bypasses all that keyboard and assignments stuff, and which are much more reliable. I'd advise ALWAYS using a control, not a keypress, wherever possible. It's much more efficient too! After all, using a Keypress you are getting FS to look up its assignments table, and then sending itself the same FS control you could have chosen in FSUIPC in the first place! See? Regards, Pete

There's no real "order" in sections in an INI file handled by Windows profile APIs. To help clarify this new option, I am displaying the actual (possibly abbreviated) aircraft name in the Options title bar, when you have "aircraft specific" selected. This could be different for Keys and Buttons, so I have to maintain two current names. I don't "create" sections any place, that's done by Windows. If they are NEW sections, yes, it will place them at the end. But if there's already an applicable section for the (possibly shortened) aircraft name, no new section will be created -- that is the active section, the one you are editing. Regards, Pete

You do not need a credit card. There are many other ways to pay. Please read the User Guide, there is a whole page listing different ways to pay! Regards, Pete

Okay. I've added the facility to match Aircraft Names to the Buttons or Keys section with the longest match. It does not operate this way by default. To use this feature you have to set the [General] parameter "ShortAircraftNameOk" to "Yes", by editing the INI file before loading FS. You have to edit the INI file in any case to set the shortened aircraft names. I'm logging the aircraft names too, now, when they change, to make this easier to sort out, though you can always read the names in the Joysticks tab of FSUIPC (the page with the Flaps control). The "Aircraft Specific" selection in the Buttons and Keys dialogues will, of course, create a section for a new name using the full name, no abbreviations. You can't go backwards on-line. If the current Buttons or Keys section is being used because of a shortened match, that's the way it stays in the dialogues. Again, to go back to a unique or longer name you would have to edit the INI file to create this. It is because of the confusion this could cause for beginners that the facility is defaulted off. The performance worries are gone because I found a Windows API which reads all of the Section names into memory, and an in-memory search is fast. I can send you a pre-release test version to try if you like. Send me an email if so (petedowson@btconnect.com). But I should be making a proper new release (as 3.21) by the end of next week, hopefully. Regards, Pete

That's all very well, but that has three drawbacks: 1. It assumes that all variations on a specific aircraft will have the same leading characters, and that no others will become included by this assumption. 2. It still means the INI file has to be edited, because, at present, to make the feature user friendly in the Option Dialogues all you have to do is specify that you want these Buttons/Keys to be aircraft specific. FSUIPC creates the section itself using the current aircraft name. I don't want to lose this nice easy facility. 3. The biggest pain is that in order to determine whether there IS a specific section for the current aircraft, FSUIPC would have to ask Windows to read all possible entries (a lot) in the section with the whole name, then if that secured no results, the same name but one character shorter, and so on, only giving up after, what, one character? This could slow things down quite noticeably when loading an aircraft. The last point arises because, like FS itself, FSUIPC uses the Windows private profile API to handle the INI file. All my programs do, it is too convenient a facility to give up! To get around it efficiently (timewise) I'd have to add another section, [AircraftNames] in which you'd need to catalogue all the names which have sections, like 1=, 2= and so on. Then I search that first and accept the first partial match. If you want a longer match you'd need to put that first in the list (I wouldn't want to have to search the whole list every time). What is wrong with simply sorting your programming out for one instance and making copies in the INI file for each aircraft you want to apply it to? I think that might be a lot easier to understand and it would certainly save a lot of extra programming for what appears to be no great benefit. I can certainly do something like what you suggest, as an option. If I take the simplistic (slow) method, it is easy enough. But I don't see much advantage in reality and potentially some disadvantages. I may add it but default it off. Regards, Pete

You'll have to send me copies of both Key notification emails you received and tell me which one you want to change -- presumably the FSUIPC one. Then I can make you a new Key. You will then need to delete your FSUIPC.KEY file (in the FS Modules folder) and re-register both of them. Send to petedowson@btconnect.com. Regards, Pete

Yes, because all FSUIPC knows is the aircraft name, the one given in the CFG file. How is it supposed to know it is just a re-paint? My advice is to set it up for one plane then, outside of FS, edit the FSUIPC.INI file and make the copies of the [buttons.] and [Keys.] sections for each paint, changing the aircraft name appropriately. Thanks for the tip! Very neat! Regards, Pete

Thanks. It looks like the VB programmer, who converted this from my own C source file (IPCuser.c, also in the SDK) made an error. I wonder if this carried over into any of the other language versions? In the C version the sequence is actually: As you can see, it is only the two Version Number fields that need clearing after the "already open" check. In C the other variables are local to the procedure in any case, and not accessible outside. I'll fix the VB source (carefully, as I am not familiar with VB :wink: ) for the next update. Thanks! Pete