Pete Dowson

So why can't you tell me what it is you don't understand? Not "KeySend= ...". You need to give it the number from the parameter in the FS PC, i.e. KeySend1= ... But where's the confusion? You say there is confusion, but you do not say where. What is it that you are confused about? Unless you tell me, how can I help? Yesamongst which is one called ""Keysend 1-255 (widefs)". That's the one. It is in the list. What is this "point" you are trying to make, please? You say "the point is" but then merely explain what you need to do, so you know. Please explain. Erwhat do you mean "override this option"? There's no "option" to be overridden! Can you explain what you mean please. WideClient sends all button presses to WideServer which sends them to FSUIPC. FSUIPC is programmed to interpret the buttons in whatever way you want. In this case you want it to send it BACK to the Client. This is done using the KeySend control, of which you can have up to 255 different ones, with parameters 1 to 255. In the Client, when it sees KeySend 1 it finds you have programmed it to send a V to a program you have asked it to load, so it does. That's it. Sorry, I don't understand. What do you mean by "validate"? Did you include the ActionKeys=Yes parameter in the client INI file? Did you put both parameters in the [user] section? Are you sure that the program you are using in the Client does read the keyboard using normal Windows keyboard messages? If it does its own Keyboard scan, then there is no way it will ever work this way, it will only work with a real keyboard. Test that your KeySend is working by temporarily making the program you are running Notepad.exe or something else which will show the character 'V'. Pete

That is very strange, as there have been no changes made which could affect that. The only thing FSUIPC may do with the autopilot is apply an altitude correction and V/S sign correction to ensure that the altitude hold works correctly. This is described in the User Guide in the technical section. Do you have that option (labelled "Enable A/T altitude fix" in the Technical page) on or off? Could you enable "extras" logging, please, and provide a Log for a short session including the condition you describe? Also, just in case it is something which has changed again in my developing versions, please try the interim test version I am emailing to you. Regards, Pete

I should think that WidevieW requires the registration of FSUIPC in all PCs it is using. but that's easy enough for you to do. FSUIPC registration is by and for the user, the owner, it is not specific to a PC. Provided all those PCs are yours, for your use, then you can register FSUIPC with the same details on each one. Regards, Pete

Please do. I already have, and I think it must be on the list, but more voices asking for the same thing will help. Regards, Pete

Sorry, I cannot make sense of what you say. Can you be more explicit please? There are no reported errors with 3.22 and it is in use on very many systems, so please double check you have things right. Regards, Pete

They are limits, separate from the graduated visibility option which gradually extends visibility as you climb. Really, restricting visibility in FS2004 doesn't have the dramatic effect on frame rates that it used to have in both FS2000 and FS2002, so if I were you I'd either leave those disabled or set realistic values for the sorts of areas in the world you typically fly. In the UK for example an upper limit of 30 miles is quite normal, especially in Summer. If you fly with VFR type (photorealistic) scenery textures then you'll probably find they look a *lot* better with a 20-40 mile visibility limit. This is actually recommended for the VFR UK sceneries, for example. Regards, Pete

Try WideClient 6.222, attached. You'll need to change "AllowShutdown=App" to "AllowShutdown=AppOnly". This will close down only those programs for which there was a "RunReady" and "CloseReady" entry. WideClient will stay running and reload those programs if FS starts up again. Of course, as before, this is dependent upon using the WideFS way of shutting FS down . Personally I don't see this facility as being of much real purpose, but as it was easy I have added it. I probably won't make a special new release for it, though. Regards, Pete WideClient6222.zip

Realistic? What does that mean in this context? In a real aircraft you do not suddenly make it non-existent, as you do by closing down the FS program! No! Realism is when the Glass Cockpits go blank when you turn off the avionics or all power sources, to get a "dark cockpit". That you most certainly can do -- check the PM options (in PFD.INI). But whether programs in a PC are running or not running is absolutely nothing to do with aircraft realism. How can it be? Sorry, you cannot do what you are wanting to do, at least not with simple parameters. You could do it if you write a program to do it. [LATER] I've had a quick look at the code in WideClient and I may be able to add such a facility fairly quickly. If so, it will only operate on the "RunReady" programs with "Closeready" settings too, as obviously the others are started with WideClient even if FS isn't running at the time. Check in later. Regards, Pete

That's no use because the "V" will be sent to FS. How can FSUIPC know you want it sent to another PC? The key presses are LOCAL to the PC in which they are generated. You do NOT program any keystroke in the FS PC. You do NOT edit WideServer.ini. There is no need. Just assign the button to a KeySend control (its in the FSUIPC drop-down control list), and assign it a unique parameter, e.g. "1". Then any Client PC which has KeySend code 1 defined will see this and generate whatever keystroke you assign to it IN THE CLIENT PC. Please look up "KeySend" in the WideFS documentation, as I advised in my last message. There are even examples! Sorry, I do not understand this paragraph at all. You seem to be deliberately mixing things up even though they are explained separately. You can deal with KeySends completely in WideServer.INI and WideClient.INI, but to make it easier I allowed the KeySend to be programmed in FSUIPC, and in any case only FSUIPC (not WideServer) sees GoFlight buttons (or any Client buttons). Can you please read about KeySend in FSUIPC's User Guide and also in the WideFS document? It is all explained there in greater length than I can here. I don't see any point in reproducing the documentation here. The 2101,0 is the button number seen in FSUIPC, it is COMPLETELY AND UTTERLY IRRELEVANT TO THE CLIENT!!! You make FSUIPC interpret the button as a KeySend control. It is the Keysend control you program in the Client!! Oh dear! This proves that you haven't bothered to read the WideFS documentation. Please look at the section on KeySend where it tells you where to find the codes. All my documents and programs for FS are available on http://www.schiratti.com/dowson, though you will nowadays also find all the key codes listed in the FSUIPC Advanced User's Guide. :( :( :( :( Why Oh Why not read what I've written? How can it all be so mis-interpreted? Please explain why you keep taking so many wrong paths? Read the documentation then tell me why it is so bad, so I may improve it. Pete

Yes, of course. It involves the use of the KeySend control. You will have to read the WideFS documentation, to learn how to make WideClient send keypresses to your program. This is easier if the program was loaded by WideClient for you, as it then knows the process and can direct keypresses to it. The KeySend command is in FSUIPC's drop-down control list. You can assign it to any button. The parameter for it, assigned there, relates it to the KeySend number in the WideClient.ini, thus relating it to the specific keypress for the specific program. Can you explain exactly what you don't understand, because I spend many more hours writing the documents than I would be able to answer questions here, so really there should be much more help there? Just saying you don't understand doesn't help me really, you see. Regards, Pete

For WideClient to close when FS closes you should close FS by using the shutdown facility in WideServer. You can do it by hotkey -- it is documented in WideFS.doc, which you will find in the WideFS ZIP. If you mean that WideClient should stay running but the application should close, then, certainly, applications can be programmed that way. But I really see no reason for any such action being needed or desired. What is the problem you are trying to resolve? The facilities offered have been perfectly adequate for many years. What sort of setup are you attempting to produce? I don't understand. If you mean Wideclient should come and go, there is absolutely no way for WideClient to start up on a client PC just because FS starts up on the server. Since it isn't running, how can it know to do this? You'd have to run anpother program to talk to WideServer which then ran WideClient, which is futile. There is no reason why WideClient cannot be running in your client PC from the time it starts up, provided you always switch on the Server first so that it exists when WideClient runs. To start WideClient automatically, simply put a shortcut to it in your Windows startup folder. Regards, Pete

No older versions are supported. Sorry, but I've never heard of Defarea. Why not? If you paid for a user registration for FSUIPC you can use it in any version of FS you like, on any PC you like. the registration is for you, not for FS or for the PC. Regards, Pete

In FS2002 leave it to the defaults. In FS2004 just enable the *** marked ones. Those will apply for any source of weather. I don't think there's many frames to be gleaned in FS2004 compared to FS2002. Anything else is a matter of personal taste really. Just experiment and select what you find suitable -- just bear in mind that many of the facilities don't do much in FS2004 in any case. Regards, Pete

In WideClient.ini. The others are in the Server and cannot possibly run programs in your client PCs. Please have a look at the document called "WideFS.doc". It should be in your WideFS.zip file. It describes all this stuff. In fact you will find documentation for all of the WideServer and WideClient parameters in the INI files in there. Please, please look at the documentation I supply. Don't you see the "RunReady" and even "DelayReady" parameters? Regards, Pete

According to Microsoft is is categorically not possible. The code that makes the indices it uses only runs during initialisation. Believe me, the FS staff don't like it this way either because of the constant need to restart FS when developing scenery, but apparently it was the only "safe" way (presumably in the time available) to ensure stability. You can force a scenery *reload* (there's an FS control for that). Whether that will get minor changes visible or not I don't know. But it certainly won't remove or include whole files. Regards, Pete

You can get almost whatever you like. As I said, go get the FSUIPC SDK. Inside there's a Programmer's Guide which lists a vast range of data you can read. Pete

Since FSUIPC cannot tell any difference between one knob and another, all this must be differences in the way the keys are implemented in the aircraft panel code -- unless, that is, there are hardware problems. To eliminate the latter, just try programming the altitude and speed on two other knobs. As far as FSUIPC programming is concerned, the knob looks like a set of 4 buttons. When you program each of those to send a keystroke, that is exactly what FSUIPC does. It has no idea what the knob is for, nor what the keystroke does. So differences in function, between altitude, speed or whatever, are completely irrelevant to it. Jumping and missing is a function of the way keyboard queues work I'm afraid. A bit like jams on busy roads. Direct controls, as available for the FS default MCP, are far better and not liable to such problems. All third party panels designed for use only by mouse and keyboard (only) have been prone to this for many years. It is hoped that in future panel designers would realise that folks want to be able to use external hardware and will cater for it (like, for instance Project Magenta). I do know that PMDG have produced or are producing an SDK to allow this to be done properly, and all I think you can do is press GoFlight to go for this and implement PMDG aircraft support into their drivers. That sounds either like a hardware problem or a problem with the GFDev.DLL. Please report the details to Goflight support. Well, the only problem I've fixed is one where FSUIPC would scan the buttons too often and send too many controls or keypresses to FS. Now it is regulated. Possibly, in view of your queueing problems, it isn't regulated enough -- you can adjust the rate by adding "ButtonRepeat=n" to the main [buttons] section, where n is 1-100 for that number of 'repeats' per second. The default is 20, and I doubt if much faster would be wise, but you could experiment in both directions. If you set it to 0 then the regulator will be disabled and it will be as before. I'm afraid I don't think FSUIPC can be held responsible for any of the other irregularities. Some look like the typical bad results of relying on keyboard inputs to alter things at any speed. The cross-interference and Windows hangs, and weird wrong direction changes, sound more likely due to the panel software itself. Maybe you can try programming them for FS's normal A/P, though I know it isn't necessary as GF does that in any case. Try programming using FS Controls first, just to see how smooth and good that is (especially if you use the new "Fast" variants I've added too), then try the same with FS's normal keyboard shortcuts. See the difference? Like chalk and cheese. But, still, though there be jumps and stalls, there should be no odd reversals nor cross-interference. Regards, Pete

Download the FSUIPC SDK from http://www.schiratti.com/dowson. All the information you need is there. I don't think you'd want to use AI data -- accelerations are what you should be replicating as it is only these with are felt. You'll need to convert 6 axis changes (accelerations are available in all six degrees of freedom (longitudinal, lateral, vertical, pitch, roll, yaw) into something meaningful in your two axes. That's another matter. Certainly you can do it with EPIC hardware, but there are certainly others. Enquiries in one of the cockpit building forums may elicit other suggestions. Regards, Pete

Hmmm. Very strange then. I don't know how any USB device can intterfere with another, non-USB device. I am emailing you my latest interim version of FSUIPC, still under development, as 3.224. Please try this just in case it is related to the over-speed operation of "repeat", which I have now fixed. Let me know. [LATER] I just thoughtthe GF MCP also has its own DLL in the FS Modules folder, doesn't it? Can you try the FSUIPC programming method with that DLL removed? Maybe there is some conflict. Regards, Pete

Glad you resolved it. Not sure what happens when using keys to fly -- FSUIPC doesn't get a look in with those at all! Regards, Pete

Please state what you mean by "FSUIPC (latest version)". I always need actual version numbers. The "latest version" just means the latest one that the user has seen and downloaded -- in some cases this has proven to be many weeks old! Can you also explain what a GoFlight FMC actually is, please? As far as I'm aware there is no such beast, and FSUIPC will not recognise buttons on it in any case. The GoFlight devices FSUIPC currently recognises are: GF-45, GF-P8, GF-T8, GF-LGT, GF-166, GF-MCP, GF-RP48, GF-46 and GF-TQ6. FSUIPC accesses these devices through the Go-Flight module GFDEV.DLL, which handles the USB connections as far as I know. If your keyboard is USB connected too, then possibly you have a corrupted version of that DLL? When you program your GF devices with GF's software do you have similar problems? (They don't use GFdev.dll). The only other thing I can think of is that you are trying to program a rotary knob on a GF device to produce keystrokes, and your have enabled the "Repeat whilst held" option in FSUIPC. Do NOT do this with rotaries -- half of the time, when you turn a rotary, it will be left with the "button" it is emulating looking "pressed" -- FSUIPC will then generate a continuous stream of results, and this may flood the keyboard input buffer. The same would apply to latching switches (toggles) -- you never want to program the "repeat" action on any switches which can stay "pressed" or the equivalent. In version 3.22 of FSUIPC this repeat option is actually too fast -- I am working on a revision now which will regulate the repeat rate to a default of 20 per second, but adjustable in the INI file. However, even then you would not use "repeat whilst pressed" on anything but normal press buttons or spring-centred toggles. I'll add some notes to the documentation about this too. Regards, Pete

How strange. There's not enough significant difference between 3.202 and 3.22 to have any affect on this -- in fact there are no changes at all in anything that early. FSUIPC doesn't even start to do anything important until FS is fully loaded and ready to fly, and even then the changes are pretty much all related to facilities which only activate when used. One of the things it does do straight off, however, is read the INI file. I'm wondering if there is something in that which is causing a problem. To determine this, could you move the FSUIPC.INI file out of the FS modules folder, keep it someplace safe for now, then try 3.22 again -- it means it will revert to default settings, but that shouldn't be a problem temporarily. If this works, please Zip you original INI file and send it to me at petedowson@btconnect.com so I can check it out here. If it doesn't work, then I can only think there is some other third party Gauge or DLL (or external program?) which is connecting to FSUIPC and for some reason doesn't like something it is seeing in 3.22. Are you loading FS with the default aircraft set to a third party one which may have FSUIPC-using gauges? Are there any other third party DLLs installed apart from FSUIPC? Do you have any external programs waiting to use FSUIPC as soon as it is loaded? Regards, Pete

I wish you'd just call me 'Pete', much less formal. :D This must be with FS2002 and version 2.xx of FSUIPC? Because since version 3 those facilities, still improving, are only available to registered users. You are on the 'good' side of 60 still? I'm coming up for 61 soon. :( Thank you very much! Please also be sure to download the latest version, 3.22, from http://www.schiratti.com/dowson. And check the site once a month or so -- or review the Release notices at the top of this Forum now and then. I always post details of each version's changes there as well as in the History document inside the Zip. Regards, Pete

Yes, but to do this you'll need to edit the FSUIPC.INI file. First program it for one 'S' when pressed, and another when released. Then close FS and open FSUIPC.INI for editing (Notepad will do). Look for the [buttons] section and find the two lines encoding your requests -- you may need to refer to the Advanced User's guide for FSUIPC to interpret the list if you've got a load. Just make two more copies of the press line, add them to the end (renumbering the sequence numbers on the left of the '=' to follow the sequence), and you're done. You won't be able to edit these in FSUIPC's options after this -- the dialogue isn't suited to any complex assignments. An alternative, if you'd like a smaller chase view superimposed on your normal view, is to assign a button to the "Chase view toggle" FS control. Regards, Pete

You have up and down winds? I'm pretty sure FS doesn't simulate vertical air movements at all at present -- the updrafts provided for gliders are fiddled a different way. If you are using FS's own weather downloads then FSUIPC has absolutely nothing to do with it. I've no way of getting between the weather inputs and the simulation, excepting in the case of the visibility. You can also clear all weather in FS, but it means several actions in several pages. Why would anyone think it as being down to FSUIPC in any case if they are not using it to allow external programs provide the weather? That's a bit annoying as well as baffling. As far as Microsoft are concerned, they fix things in each successive release. Hopefully this will be fixed in FS2006, but you need to report it via the normal MS channels in any case. They don't tend to bring out any interim patches unless things are really bad (like the program can't be used because it crashes or something). The wind shift problems I know about in FS2004 are the same for any aircraft, because they are not related to aircraft at all in the first place. Just because your more sensitively set aircraft crash and burn whilst others recover doesn't make it an aircraft phenomenon. I can reproduce 180 degree windshifts using downloaded FS weather with no FSUIPC installed and with default aircraft. They are especially likely in parts of the world where there are a lot of close weather stations, like Chicago for example. This subject has been under almost continuous discussion since FS2004 came out -- you'd possible learn a lot about it by searching or browsing. Experiments by top weather program authors seem to point to problems with FS2004 wrongly interpolating wind direction changes when there are anti-clockwise changes as you ascend. Whether this explains all the problems or not I don't know, but it has certainly been shown that keeping all changes clockwise helps. I believe that the very latest versions of programs like Active Sky and FS Meteo may have cracked it, or at least very nearly so. But please don't take my word for it, go do a little more research and see what folks are saying. Regards, Pete