Pete Dowson

As I just said in the last message, please review it: "Yesamongst which is one called ""Keysend 1-255 (widefs)". That's the one. It is in the list." Oh dear! The FS2004 controls list, strangely enough, is a list of FS2004 controls. It will not list any of the many extra controls added by FSUIPC. Please PLEASE PLEASE check the FSUIPC User documentation. I shouldn't have to do this, but I am repeating here the section in the User Guide which you apparently miss: I have emboldened the relevant parts. I respectfully suggest you look again. I can understand that this may make it more difficult to understand my English, but I still don't understand how you can miss so much. Sorry to be so critical, but you will understand that it does get rather frustrating saying the same thing over and over. Regards, Pete

Sorry, what's a "spirit's" answer? Please let us stick to FS default weather for now. Are you saying that the ATIS is wrong or that the actual weather simulated is wrong, or something reported somewhere else is wrong, and in the latter two cases where are you reading this? In the FS weather dialogues, in WeatherSet, in a Shift+Z read-out, or where? If you could please be very specific. Make a particular example. Say what you read where and why you think it is wrong, save the flight and send me the files I mentioned. You "correct" them to what you believe is to be correct, from what source? I was not asking how you changed things in FS, but how you knew what was "correct" in the first place. Sorry, but this is going in circles. If you want me to look at this I need very specific details, I cannot understand a lot of what you say. Please, for now, leave FSMeteo and ActiveSky out of it -- FSUIPC is obviously involved there and it gets too complicated. Since FSUIPC has absolutely no influence over FS2004 downloads (I really wish it could!) I need to understand what you are seeing there. When you say "systematically" what does this mean in this context please? Are you saying you cannot even change the visibility in the FS weather dialogues? What happens? Do the figures in the dialogue not change, or only the screen, or both? If the dialogue changes but not the screen, are the figures reverted when you go back to the dialogue? Regards, Pete

The temperature doesn't decrease as you ascend? What does 2-5 degree error mean? Where is the error reported, or how are you judging it to be an error? Please be more explicit. Take FS2004 downloaded weather as the example (since FSUIPC has absolutely no influence on that at all). Tell me what you do and where and how you see an error. Again, how do you judge these to be in error? With FS downloaded weather you get whatever the download gives you. And, as with temperature, FSUIPC is unable to influence the winds downloaded by FS2004 in any way whatsoever. I wish I could find a way, but there's none that I found. How do you make a correction if you cannot judge what the error is? I seem to be missing some vital piece of information here which you are not telling me! Visibility *can* be overridden in FSUIPC, using the three options marked *** in the Visibility page. Do you use those? Perhaps you can explain in more detail what you are doing and why you think it is wrong. Maybe save a flight with what you believe to be "wrong weather", and tell me why you think it is wrong and what it should be. Please be sure to use default aircraft and scenery so I can load it here. If you can also turn on FSUIPC's Weather logging for this, it may help -- ZIP the saved FLT + WX files, plus the FSUIPC.LOG file, plus your FSUIPC.INI file, and send them with your explanation to petedowson@btconnect.com. Regards, Pete

Yes, I don't see why not. Regards, Pete

FSUIPC doesn't (can't) influence FS2004 internal online weather (except for the three visibility options marked ***), so I think you must have something else going on there. There also have been no changes in any of the weather facilities in FSUIPC for many releases now. Perhaps you can be a little more explicit about what you mean by "the temp/winds have error". In itself that means nothing I'm afraid. Do the FS weather dialogues say "error"? What constitutes an error in temp/winds? Regards, Pete

I think the addition of the new anti-ice switches in version 3.22 is incompatible with FS2000. I've sent you another test version (3.227) to try. Regards, Pete

How odd. FSUIPC doesn't touch those things. In fact it doesn't even know you are using them, and I have no other reports of this. I will have to think about this .... there's no code at all in FSUIPC which has anything to do with such matters, so it is difficult even to work out how to get more information. Possibly merely the different module load order or slightly different memory arrangement is showing up a weakness someplace else in FS. If I can think of anything I'll get back to you. I may send test versions of the DLL to try. But at present I'm stuck, sorry. Regards, Pete

Did you try without that checked? Got itit shows that FS is continually crashing and that FSUIPC is trapping this crash and logging it. It appears that FSUIPC cannot actually be doing much at all. It looks like I will have to install FS2000 to see what is going on. Regards, Pete

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