Pete Dowson

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

Your purchase of FSUIPC covers your use of FSUIPC as much and as often as you like. It is sold to you, for your use, not to a specific computer for its use. I am not a fan of the system tying a product to a PC, which is why the Registration ties it to you instead. (But, as Jamie kindly points out, not to your friends! :wink: ). So, just install it and register it on the other PC using the same details as for the first one. It is WideServer which handles the Clients, not FSUIPC directly. And you can't have both WideClient and FS running on the same PC. On a client PC you either have WidevieW and FS running, or you have WideClient and other applications running. You can have WideServer installed in one or both FS installations. The WideClient PCs know which one to send and receive data from by the "ServerName" (or IP address) for TCP/IP, or "ServerNode" for IPX/SPX, which are parameters in the INI file. But if you do want two or more separate WideFS setups running, you should also change the Port numbers in one of them. Choose a number greater than the default -- the one's just under are used by WidevieW I think. Regards, Pete

I see. But if it does this through emulating buttonpressing or keys then those can be transmitted to FS through WideFS as well. But it is of no matter ... Yes, All current registrations apply to all version 3.xxx copies of FSUIPC. All I have at present is an interim version (3.205) with some changes, but no documentation updates. It is on its way to you. Regards, Pete

Ah, I'm not sure how many of the frills work in the demo. You'll need to check with PM. Also, I don't know much about the Airbus versions of these things, but the FCU is the equivalent of the Boeing MCP. So if the demo supports them, most if not all of the FSUIPC-implemented PM controls should work. They only toggle or set bits in offsets used by PM (and documented on the PM website). This sounds like one of the problems in the recent builds. The Mode and Range (and most other INC/DEC commands) each rely on a single bit being set by the requester and cleared by the receiver. Until PM has cleared the bit no further INCs/DECs will be serviced. All this did work fine not so long ago. I think you should report the problem to PM support. I've noted some problems recently and told them, but not this one. Sorry, I've no idea what that means or how it relates to this. If you only have one PC and it is impossible for you to connect your FMC to it, how can you possibly use it? No, there is no demo. You can't use it in any case with only one PC, so it doesn't matter. You are entering a complex world. PM emulates many functions of an advanced aircraft cockpit and once you start trying to achieve any sort of realism with switches and so on you are going to have to deal with complex matters. I have just made and tested a version of FSUIPC which will provide parameter driven PM controls for the following (you will certainly need to refer to PM's "FSUIPC offsets" documentation on the PM site for these -- look them up by the offset given below, the document lists things in that order). * PM MCP kcodes (by Parameter) for the MCP/FCU Throughpass (at offset 04F2). This uses Knnn type Elan Informatique codes. * PM CDU keys (by Parameter) to send keys to the CDU keyboard interface at offset 5428. * PM GC keys (by Parameter) to send keys to the GC keyboard interface at offset 542A. * PM QuickMap keys (by Parameter) to send keys to QuickMap's keyboard interface at offset 542C. * PM Whazzup keys (by Parameter) to send keys to Whazzup's keyboard interface at offset 542E. In each case the parameter entry in FSUIPC's Keys or Buttons page gives the data to be sent. For the MCP/FCU system these are code numbers representing functions, but in all the other cases they are character values in ASCII (eg 65 for 'A', 49 for '1'), with 256 added for Shift, 512 for Control and 1024 for Alt (mixed as needed). There are some special characters too for the CDU: . = 190, / = 191, + = 107, DEL = 46, CLR = 8, Function Key n = 111+n. (These are the same codes as used by FSUIPC and FS and listed in my Advanced Users Guide). Note that you don't need to worry about the business where it says "... other bits must change if you have two same characters ...". FSUIPC deals with that automatically. If you want to try any of this before the release I can send you an interim version -- send me an email to petedowson@btconnect.com. Regards, Pete

PM questions are really better dealt with by posting in the PM Newsgroup, Pm's equivalent of this Support Forum. However: Are you running the PM MCP as well as the GC package? I don't think many of the PM functions work without the MCP. You could try the assignments for the PM GC controls facility, which takes a parameter (see 2999 in the list in the FSUIPC Advanced User's Guide). Also, I've found numerous problems with PM's FSUIPC offset interface in the more recent PM updates, things like the Mode resetting to "APP" when something entirely different is changed. I think Enrico has been trying to improve things and has introduced a few errors in this area. You may want to try a much older version of the GC, just in case. Well, if your CDU is running on a separate PC under WideFS, you could program all the A-Z and 0-9 keys in FSUIPC to send different KeySends, and define these in the appropriate WideClient.ini to send the keystrokes to the CDU, yes. But you'd lose all those keys on your FS PC. It seems far more sensible to have a keyboard on your CDU PC instead. Not sure what that means. Are you saying PM's CDU is not running in a separate PC? It makes quite some difference. If it is running in the FS PC I can see no way to divert keyboard input to it without changing the focus to it, away from FS. If it is running on a separate PC, use the KeySend facility. Ah. That wrecks most of the answers above! (I'll leave them in for other readers, though). Then the problem is one of keyboard focus. That is difficult. PM is not really designed for single PC use at all. What you really need is a facility in FSUIPC, similar to the GC Controls facility, with parameter, to send values to the "CDU Keyboard Interface" offset (see PM's FSUIPC Offsets document on the PM site, offset 5428). I can add that without any problem I think. I'll add it to my list and may fit it into the next version, due at the end of next week (16th April). Maybe I'll send you a test version to try before then. Regards, Pete

The DME stuff is in character string form, it isn't a number at all. it is ready for printing. See the Programmer's Guide. Exactly. It isn't handled in FSInterrogate because FSInterrogate cannot deal with strings. The author was going to add strings but real work got in the way. Try looking at it with FSUIPC's "monitoring" facilities -- on the Logging page. Select the type "Asciiz". FSLOOK is dealing with Gauge variables. If you are writing a Gauge you can use those. FSUIPC doesn't support FS gauges, FS does that. The DME data format dates back well before FSUIPC, to FS95 and probably before. FSUIPC maintains it for compatibility. It isn't a number on those terms, it is a string using ASCII characters and terminated by a zero byte. Please looks at the description of it in the programmer's guide again. It is length 5 including the zero terminator. If you read it into a 5 character string to can convert it into a number by using C library routines like atof() or sscanf(). There will be equivalents in your language. On the other hand if this is simply for display, just display it as is. Regards, Pete

Really? How extraordinary. It's the first I've heard of itI'll check that now! [LATER] Yes, you are quite right. It also applies to the elevator, in fact, so that's all three axes. Interestingly it is only the first change -- i.e. away from zero. Otherwise the effect is certainly equal. For instance 2 presses left are cancelled by 5 presses right, not 8. I think must be by design, but I'm really not sure why. Maybe, as in real aircraft, FS2004 is better modelling the natural return to zero which happens (because of air pressure) when you release the controls, and havong the same large reverse step would make control worse, not better. It is certainly an interesting thing they've done, and there must be a reason for it. No, because it looks like the controls "Rudder Left" and "Rudder Right" (and the other four) are actually implementing this by checking whether the control is centred (zero) initially, as it should be. I've experimented using the Trim controls instead. These are certainly equal both ways even from zero. However, zeroing them doesn't centre the actual control, so they can't be used that way. I really would recommend using the "5" key to centre everything. If you want separate centre keys for each axis you could assign keys in FSUIPC to the "Rudder Set" and similar controls, with a parameter of 0. I think the FS keys are supposed to do that, but not by tapping. When I fly by keyboard (which isn't often, only when stuck without other controls) my fingers rarely leave the number pad. I've not really found any adverse eeffect of your discovery in FS2004. I suppose if you fly by pressing a key then hands off it will matter more, but if you fly with a yoke or joystick you never let it go completely unless under autopilot (or in panic because you've realised you don't know what's going on! :) ). Regards, Pete

Sorry, I really don't think so -- too many hours spent already trying to work that out. Maybe Microsoft will make these things a little more accessible in future versions. Regards, Pete

Done. Pete