Pete Dowson

No, not at all. You have discovered an interesting side effect of some safety measures I included, to prevent run-away repetition. I was puzzled too, at first, so I tried your settings with assorted variations. The problems arise because of these lines: 6=R2,6,C65771,0 7=R2,7,C65769,0 8=R2,8,C65777,0 9=R2,9,C65775,0 Here you are defining the very same buttons you make conditional elsewhere to also unconditionally operate prop pitch inc/dec and mixture inc/dec, repetitively. It is a little odd, to say the least, to have your Gear up/down control also increment or decrement the prop pitch, and even more odd for radio stack or GPS viewing to do similarly. But it isn't that which is the problem. It is the "R", the Repeat action. The anti-runaway code prevents another control from the same "R" button press being sent to FS within so many milliseconds of the previous one -- the actual timing is controlled by the repeat counter parameter, I forget its name now. This is why is didn't affect the key press values, only the controls. Really, the correct way to program those additional actions on those same buttons is to make them conditional on neither button 0 or 1 being also pressed. i.e 6=CR(-2,0)(-2,1)2,6,C65771,0 7=CR(-2,0)(-2,1)2,7,C65769,0 8=CR(-2,0)(-2,1)2,8,C65777,0 9=CR(-2,0)(-2,1)2,9,C65775,0 [Note correction here -- in my original posting I omitted the 'C's] Of course, theoretically FSUIPC shouldn't stop a different control being sent even though a repetitive one is instigated. I'll have to think about that though. I don't really want to remove the safety code I inserted, but it looks like it may have to become somewhat more complex. Hmmm. Regards, Pete

Ahall you mean is that it clears the button selection. So what you see is simply exactly the same as you see when you first go to that page, before pressing a button. Until you press a button you cannot program it, and changing between global and aircraft specific modes effectively restarts the process. That's why it says to do that selection first in the Doc. By the way, the options are to program FS controls (on the right) or key presses (or the left). The PM controls checkbox is just to include the PM controls in the FS controls drop-down list or not. Regards, Pete

Well that most certainly should not be neceassary. sort of defeats the point of the aircraft specific facilities I added. Thanks! Actually both eyes have been "done" now. I had some trouble with the first one (operated on 8 weeks ago) -- a swelling at the back prevented it focussing with any lenses at all. I've been on medication for that for nearly two weeks, with another three weeks at least to go, and at least I can focus now with both eyes at the same time, and even at the same distance, with an appropriate mixture of lenses. I've been buying cheap pairs of reading glasses and playing around swapping lenses about and have arrived at workable solutions -- one for PC work, another for reading. It isn't worth getting proper prescription glasses yet because things will change -- hopefully for the better! Regards, Pete

First, please make sure you are using the latest FSUIPC (3.30). There have been a few changes in this area in the last few months. Second, the only reason I ever prevent access to button programming for a particular button AND context is that it is subject to something more complex -- like conditionals or multiple actions -- which can only be done by editing the INI file. If this is the case you should see a message to that effect, I think (sorry, but it seems a long time since I did that bit). If it is indeed the case then you will have to continue to edit the INI file for such buttons, or else delete the entries before loading FS. If you want to re-program them completely for a particular aircraft, find and delete the entire Buttons. section. By all means paste in the Buttons section(s) of your INI file here if you are still puzzled. Regards, Pete

Yes, because when you manually set weather it is well nigh impossible to set all the weather stations in the world. The closest you can get is to set so-called global weather, but I think that also only sets stations within a certain range. So they change. They become localised and change just as any other local weather does. I think all this is part of the new rather too clever weather simulation we have in FS2004. It is very different from the unrealistic one in previous versions. And I do quite like it now I am over the shock. :wink: Yes, of course. I emhasised that there because from using previous versions folks were used to being able to set such-and-such a weather and have it stay that way. FS2004's weather is not really like that. I still don't believe clouds only disappear. They also appear too. But your best bet, as I advised, is certainly to download real weather for the whole world, so that all stations are populated, or to use one of the weather programs. Some of them have evolved to deal with FS2004's weather very well -- I have heard great things about the next version of AS2004. What is the "right place" for a cloud? Surely they are moving? Or are you ensuring there are no winds at any level? I'm pretty sure it was more than 3, maybe more than 5, but I'm not so sure about that. To be honest I'd not even noticed that the 'limit' had changed at all. Maybe I have been lucky. Using external weather programs and with "Extend METAR max vis" enabled in FSUIPC, the "10SM" which in US METARs simply means "10 miles or more" is almost always extended beyond the 10 miles. In Europe, where the value is "9999" meaning "10 km or more" it is a little more likely that this will give me 6.2-10 miles sometimes, but as I say I've not noted it as a problem before. Maybe I should look out for it on the next chance I get to fly (not so often at present). It cannot hurt. It will help them to prioritize things. However, as I pointed out, it isn't this 'limit' which is so much a problem as the imposition of the same visibility in all directions, up and down included. If that is an inherent function of video card design or DirectX then they, the FS team, may be rather limited. I'm not even sure that the apparent increase in the 'limit' from 5 or 6 to 10 miles was of their doing, it may have been a side effect of changes in DirectX. This is a graphics and DirectX question. I am sorry to say that it is not my area of expertise in any way whatsoever. Sorry. Maybe you will find the answers in the reference works for DirectX 9? Regards, Pete

The edge of the stratus layer marking the top of the low visibility layer? Well, high enough so that the horizon is further away than the cloud drawing distance set in Options-Settings-Display-Weather, of course. If you are using FSUIPC's graduated visibility set so that you have, say, an upper visibility limit of 60 miles at altitude 25000' and the cloud drawing distance is 60 miles or less, then you should never see the edge. This is what I meant by that facility helping to partially fix, or rather hide, the problem. I don't think it can actually 'go' until Microsoft alter the code. It's just the way FS works. If you are never seeing it then one of these things must be true: 1. Your visibility layer is not set with a low enough visibility to generate the stratus on top (try 10 miles or less) 2. The top of the visibility layer is above you (check the Weather dialogues) 3. You have some cloud texture set which effectively sets that particular cloud type at that sort of altitude transparent, thus effectively defeating the facility in the first place. Maybe your original effect was bad rendering of textures in any case, hence fixed by the driver update. But in that case I fail to see how they were related to visibility limits. Regards, Pete

Does Goflight provide a PM driver for their MCP? I didn't think they did. I thought that was one of the main uses of FSUIPC's GoFlight support -- that and PMDG MCP. Of course you'd presunably have to remove the GoFlight MCP DLL from the FS Modules folder, if there is one. You won't get the displays operated from FSUIPC though. I am at a bit of a disadvantage here, not having a GF-MCP. No, he shouldn't, not on GF-MCP versus PM. The best place is the Project Magenta newsgroup. I'm sure there will be others who've been through all this there. Regards, Pete

Ah, in that case it either wasn't the added top-of-layer stratus, or it was but the new drivers did a better job of smoothing them or making them suitably translucent. Nevertheless, if it is related to the visibility layer, which it seems it is by your reference to it only happening when setting limits, I would expect you still to be able to see the edge when at sufficient altitude. Regards, Pete

You'd get the same without FSUIPC if you set a lower than a certain visibility in FS's weather. What happens is that Microsoft, in their wisdom, decided that when viewed from above the visibility layer, fog and mist layers below sohuld not looks completely transparent -- which they used to be in all previous versions of FS. this was after complaints about this from users ("why, when I climb out of thick fog and things clear, can I see the ground clearly below me?"). Their fix to this was to automatically add a thin layer of stratus cloud (unlisted in the clouds area) at the top of the visibility layer -- thicker for lower visibility, thinner for higher visibility. The problem is that this cloud layer obeys the rules you set for other clouds (in Options-Display-weather), and there is a limit to how far out those clouds are drawn, the same as for "real" clouds. One answer which partially works is to use FSUIPC's graduated visibility facility. The only other way is to go into the FS weather menus and set the top of the visibility layer well above you. Unfortunately that would give you a fixed limit all the way up to that level. Regards, Pete

FSUIPC looks in the Registry for the correct path. When the GoFlight installer is run it adds that Registry entry -- pointing to GFConfig.exe, which is where it also stores GFDev.dll. The Registry entry in which the path is found is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CurrentVersion\App Paths\GFConfig.exe. Maybe he installed things manually, perhaps by copying them over, or has re-installed Windows since then and forgot to re-install the GF software. Any of those would lose the vital Registry link. There's no other way FSUIPC can reliably find the DLL, though I suppose it is possible that Windows would find it for me if it were placed in the Windows\System32 directory. Not sure. Regards, Pete

"Rounds"? What are they? How are your clouds 'disappearing? Do you mean the dynamic weather? You can reduce that to almost zero by setting the slider all the way to the left. However, from what I've seen, sometimes clouds develop rather than 'disappear'. Possibly you are selecting one of the themes? I think they have dynamics built in. If you are setting your own weather then possibly you are only setting your local station(s). If there is a wind at the cloud level, they will move with it. If there are no clouds following, the sky will clear. If this is the problem then you are better off downloading the real weather, or using one of the weather programs such as ActiveSky or FS_Meteo. I'm not sure that problem was ever any different, though I don't think the limit is 10 miles? In FS2002 it was about 4 or 5 miles at which that 'cut-off' happened. Maybe the limit value has changed, but I've not particularly noticed it. Best if you use graduated visibility so you can climb out of it. The real problem with the way visibility is implemented (and this probably has as much to do with the way video cards work as anything) is that the visibility limits apply in all directions -- i.e. up and down as well as horizontally, whereas really it should be the horizontal limit and it should taper off quite quickly with viewing angle. I don't know if that's possible with video card 'fogging', but you should send your suggestions NOW (in time for the next version of FS) to Tell_FS@microsoft.com. Regards, Pete

Most likely reason is that the GF driver (GFDev.dll) is not installed. He needs to go to the GoFlight website and download and install the latest package -- it now automatically installs that DLL as well. To be honest I have no idea what might not work in Win95. I know that nothing works in WinNT, but I haven't had Win95 for many years and I know no one still using it. I would have thought that even FS would have difficulties in Win95. The reason the key press programming is explicitly not supported is that the "SendInput" API which it uses wasn't added to Windows until Win98. KeySend is a method of relating events in the FS PC to keypresses in the client. The client does not use "SendInput" -- WideClient pre-dates that facility in Windows. FSUIPC doesn't recognise any GF stuff. All it does is register a call back function with GFDev.DLL. After that it just gets calls when things happen. The actual units are identified by GFDev. So the only way it won't work is if it cannot find GFDev or if the version of GFDev it does find is not working. The solution to either is to install the latest GF software. Regards, Pete

Why are you attributing these problems to FSUIPC? They are nothing to do with FSUIPC and I'm afraid there is probably nothing I can do which will help. I assume that you are not trying to use any other FS control between pressing the Shift P or Shift E and the number? Folks are always tempted to press Shift P to start the pushback, then select a different view so they can see when to tell it to turn by pressing the 1 or 2. Unfortunately, the way FS is written, any intervening control will take FS out of the correct mode and the numeric will not do its job! In fact, those are symptoms of aircraft panels which are sending too many controls, for some reason best known to their authors. Several of the more advanced complicated ones do this, and it is those, too, which need the "accelerated controls" fix in FSUIPC, for the same reason. What happens in those cases is that the controls sent by the panel intervene between the Shift P or Shift E and the following number. If your problem is due to the panel (check by trying one of the default FS panels -- none of them do such things) then you could try enabling that accelerated controls fix option in FSUIPC (on the Technical page). It may help, but I doubt it, as it cannot actually stop the controls, only disable a timer which makes them accelerate. Regards, Pete

Yes, me too. But I've seen it both ways. Maybe it depends how it failed during the shutdown. Regards, Pete

FS4? That's pretty old now -- I did do some software for that, about 15-16 years ago? I assume you really mean FS2004. :wink: I assume you must mean WideServer: WideClient runs in your Networked client PCs. Oooh, ouch! How did they get on your machine, do you know? You paid for both FSUIPC and WideFS? It sounds like something you installed or received from someone included an FSUIPC.KEY file!! Ouch. Big ouch! Please send them to petedowson@btconnect.com. Attach the KEY file if you still have it, please. You don't recall how they may have got into your PC do you? By the way, strictly speaking this isn't "hacking", as your subject line indicates, but outright piracy -- allowing free copies to be made by publication of copying of the user details and registration Key. It is one of the disadvantages of not using a hardware-related Key as many products do (including Windows XP of course). For a one-man band like me (despite having simMarket folks handling the initial registration), the numerous re-registrations as folks change hardware, need second copies, et cetera, would just be overwhelming -- hence the simpler system. Thank you. I look forward to seeing the details soon. Regards, Pete

Just use FS to assign that axis as the Mixture (Options-Controls-Assignments). When you've done that, go to FSUIPC options, find the Joystick page containing the Reverser, click the "Set" button for the reverser and calibrate it by following the steps in the documentation. What is so hard about that? What is it about that you don't understand? Why didn't you understand that from the documentation? (Sorry about all the questions, but I do need to know these things to improve documents so I don't have to answer such questions here forever :wink: ). Ah, in which country is this? Is seems rather a localised term. Regards, Pete

I should hope so! It has since it was implemented back in FS2000 days. :D Oh, also, despite the documentation having stood the way it is since then too, I have taken your advice and changed it, subtly, to try to avoid the confusion you found yourself in. Maybe this will make up a little for my continued omission of a ToC. :wink: Section 5 will now read: Good flying! Pete

Right. That depends. It has been recently discovered that it loads DLLs if they are placed in the main FS folder too, so make sure you haven't one there. Even renamed -- if it ends in .DLL it can still be loaded. There may be other places where it can be loaded, but I don't think so. However, you do say "periodically", and it won't be periodic if the DLL is loadable -- it would be 100%. So it sounds more likely that a previously loaded copy of FS is still actually running -- in other words, when you closed it down it actually crashed during the close down. I have seen this several times. I believe Microsoft are looking at it. To check if this is the cause, each time after closing FS, do a Ctrl-Alt-Del to bring up the Process list and see if FS9.EXE is still listed. If so, that is the reason. Force close the process before loading FS again. Regards, Pete

Me, yell? :shock: That's wrong. You have to set the Idle range -- you will see on the screen in front of you, in the Idle (central) position TWO numbers, not one. You cannot have just an idle "spot" -- if you did how would you always be able to locate it? You have to have a range of movement where all is idle. So you set Full Reverse, then the TWO idle spots, defining the range, then the full forward. Here's where I get, justifiably I think, to do the yelling :D . See this part of the documentation. I've emboldened the bits you ignored: Skipping one of the 'Set' actions needed meant you got a default value for one end of the idle range -- hence your big idle range. Couldn't you see this from the values shown after you'd set the others? You quote your IN and OUT values, but the important ones are the 4 calibration values under the Set buttons. It is those which you effectively chose and those which control the show. Now maybe you skipped this whole section because you didn't regard the idle as a "centre", but, please think again. It IS between the full reverse and the full forward. See the italicised bit above. And you must surely have realised that you needed more than a single point in the travel which represented idle? Okay. Shouting mode off :wink: ... Yes, but documentation is the biggest pain for us programmers, and such organisation makes it a type of hell on Earth. Sorry. :( Regards, Pete

You might find you can reassign them via FS controls "Select 1""Select 4". I've never tried. Another way is to use the FSUIPC offset setting facility. The engine selection is via a byte at FSUIPC offset 0888. Bit 0 (value 1) is for Engine 1, bit 1 (value 2) is for Engine 2, bit 2 (value 4) is for Engine 3, and bit 3 (value 8) is for Engine 4. The FS hot key for all engines merely sets these bits. So you could program any keys to select engines individually or in concert. In that case it is far easier and safer merely to reallocate RC's keys. Mine are CTRL+SHIFT+1etc. I changed them from the defaults many years ago! After all, the FS number keys are also used for Pushback direct setting (1 or 2 after Shift P) and for dorr selection if you have more than one to open/close. Regards, Pete

Please find the "Caps Lock" key on your keyboard and press it to turn off the all-Caps look. It is not only difficult to read, but it also comes over as shouting. Anyway, you are actually in the wrong forum for such a question. I certainly don't know anything about FS's default ATC (I'm a long-standing Radar Contact user). Try the FS2004 Forum. That's the most likely place for general questions on FS2004. But do please remember, don't send your messages in all capitals! :wink: Regards, Pete

Yesthank you! Regards, Pete

I haven't found one yet. Those were things someone found in FS98 and which were still more or less in place in FS2000, but I have no idea what happened to them. Sorry. They do all have "NO" clearly annotated in the FS2002 column, and in one case the FS2004 column also, in the Programmer's Guide. Now that you have determined that they certainly still don't apply in FS2004 I will mark them so. Thanks. Regards, Pete

Of course you can get help here. I'll be delighted to help. But you do have to be more specific. Just asking "how do I do ..." when it is explained already in documentation that I spent weeks preparing doesn't help, because all I can then do is reproduce the relevant parts of the documentation, which is obviously silly. Surely you must understand that if I have tried my utmost to explain it as best I can in the documentation, I am not likely to be able to do better here in different or fewer words. Please, therefore, do as I say. Go back to the document, read the parts about joystick calibration. Just try calibrating the throttle first -- if you come across a step there which you don't understand, come back and ask about that particular part. When you've calibrated succssfully, the rest is as easy as pie. Please don't feel you are being re-buffed. It is just that you sound like you aren't even bothering to look at the documentation, which is very upsetting considering the amount of time I spent on it! If you are looking at it, prove it by explaining what parts you don't understand. If it is just that you don't understand English at all, then please say so. I am sure we can find someone here who will help translate the relevant parts. Regards, Pete

Not in that fashion through FSUIPC. You would need to use a database and look it up -- maybe one derived from scanning the Navaid content of BGLs, or maybe from a separate source. If you are within reception range (distance and altitude) of an NDB then you could do it by setting the frequency in the ADF radio and reading the bearing at offset 0C6A. The flag in offset 3300 will tell you when reception is ok -- you have to allow a second or two after tuning. If you want to avoid mucking up the user's ADF settings, you could try using ADF2, which FS2004 does support -- the bearing is then in 02D8. I think to make ADF2 operational you would have to alter the AIRCRAFT.CFG file though -- there's a Radios section and you can add a line for ADF2 there. You don't need a gauge for it for what you need. Regards, Pete