Pete Dowson

That's the main entry point provided by the basic library code needed with any Windows program. Sounds like you've excluded all the standard libraries. WinMain is the entry point in your code which it calls, for a Windows (as opposed to DOS) type program. There's a Windows API called "Sleep(milliseconds)". But your whole program reads like a DOS program. A Windows program should surely at least have a message loop to process messages, and a Window (even if hidden/invisible) in which to process them. Then it would be much more user friendly to use SetTimer to generate a wake-up call every 500 mSecs., allowing the program to process messages (like WM_CLOSE) as well, and generally be responsive. If you do it the way you've done it you could instead rename WinMain as main and compile it as a DOS program. (A "Win32 Console" program is probably the more proper name -- whatever, it would run in a DOS window). Regards, Pete

All WideFS provides is simply a Network copy of the FSUIPC interface. The FSUIPC interface is used by programs to extract information FROM Fs and input information TO FS. That includes all the weather data which ActiveSky downloads and processes, but it does not include actual graphics, aircraft, cockpit panels, scenery, or anything that has to be installed INTO FS. In particular, cloud textures go into FS's textures folders and are only picked up by the weather system in FS based on codes (for cloud type, height, and so on) in the weather data, which can be sent via WideFS as it is part of the FSUIPC interface used by ActiveSky. To put it another way, if you don't know what you want WideFS for, I don't think you want WideFS. Please do not pay for it just because it looks interesting. It is a solution to specific requirements. If you have those requirements you will know you need it. If it is still not clear, tell me what you want to achieve and I will tell you if WideFS can help or not. Okay? Regards, Pete

All the options which can be applied can be applied at the same time. Yes. Regards, Pete

I really cannot explain it any clearer than I have in the manual, else I would have done so there. Sorry. I can answer specific questions but otherwise I'd only be repeating what is there. It has rarely confused any one else. What specifically is the problem? As for "best" that is completely a matter of personal taste. For the values themselves my own taste is reflected in the defaults, that's why they are defaulted. All you need to do is enable them. I D/L FS2004 WX for my flights with no other programs. Just enable the smoothing and graduation and leave the values as they are -- unless you fly light GA aircraft in which case you may wish to lower the upper graduation altitude to something a little below your normal cruise level. The visibility limits were mainly designed to give higher frame rates in FS2000/FS2002 in cloudy conditions, without losing realism. In FS2004 reduced visibility doesn't seem to have any real beneficial impact on performance, so whether you want to set any is completely your choice. Regards Pete

I guessed your name was Italian :wink: . My wife comes from Bristol -- I went to University there. Nice city. I am from London (well, close) originally. Actually Eastcote, Middlesex. Regards, Pete

Yes, it is easy enough. I'm looking to release 3.48 early next week. But I'm not sure you will actually get better results because I thought you still saw this phenomenon using FS's own weather downloads too? FSUIPC doesn't change those with this option. Maybe you just had bad luck with FS/Jeppesen weather? If so you may see things better with FSMetar. As it says on the left somewhere, I'm near Stoke-on-Trent, also UK. In fact I'm about 15nm almost due south of EGCC. Regards, Pete

I assume that it is Squawkbox supplying the weather? Have you set any weather options in FSUIPC? Check the visibility page in FSUIPC options. Have you set a high minimum visibility there? The other, and more likely, possibility is a problem with your FSUIPC user key (or your WideFS key if you are using one). To check this, please try again with it registered, then close FS. Zip up the files "FSUIPC.LOG" and "FSUIPC.KEY" (both from the FS Modules folder) and send the Zip to me at petedowson@btconnect.com. I will check the keys here. So far all instances like this have been due to bad keys, so that is the best check I can do. Regards, Pete

No, I've never noticed it at all using FSMeteo or ActiveSky. I assume they set their own visibility values. Also, none of this explains why you also see it with FS's own weather downloads, as FSUIPC cannot and does not then operate that feature. Maybe, but there are rather too many as it is. Personally Ii don't see a problem in assuming more than 10.4 miles for 9999 metres. I doubt that anyone will notice -- and you wouldn't really expect to see grey murk when the visibility is quoted as 9999 (or even "at least 6.2 miles", which is what it means), would you? Regards, Pete

It is more likely to be a problem with your user key. Remove your FSUIPC.KEY file from the FS Modules folder and try again. If that works it sounds like you have registered FSUIPC or WideFS with an illegally generated key. If you believe it to be genuine, zip up the KEY file and send it to me at petedowson@btconnect.com. Otherwise simply stop using it. Regards, Pete

Try AdvDisplay 2.133, being sent at present. Regards, Pete

Version 1.10 of GFdisplay, on its way to you and the usual websites now, supports options for delayed indicator 'off' actions and the extra timed flashing options I mentioned. Please see the recent Changes notice near the top of this Forum. Regards, Pete

That's rather strange. Doesn't it give any clues as to why, an error message or something? I don't know. Basically it closes the server port and re-opens it so forcing everything to re-connect, so it is more of a restart than just the client trying to reconnect. But whether this will reset whatever is stuck on your Network I couldn't say. You'd have to try it. What normally clears it? For instance, if you close down FS and restart it, effecting restarting WideServer the log way, and that clears it, then restarting WideServer in situ using the hotkey may well really do the same. But it will depend on the cause. The fact that it happens does indicate something rather dodgy going on in the server PC. For instance, if it's due to a memory leak in FS or an accessory which is gradually using up real memory space until the buffering on the network is affected, then restarting WideServer without FS and the add-ons may not clear the cause. There are some known FS memory leaks -- one, I understand, can happen just by placing certain scenery types (autogen?) in the wrong folder (Addon scenery folder?). I'm not sure of the details, I just recall reading these things. Maybe, after trying the WideServer restart, if that doesn't help, or only helps for a short time (i.e. re-using the little space freed by closing the server port), you should ask around, for instance in the FS2004 forum, and see if you can discover other possible causes. Regards, Pete

Probably writing the velocities and even maybe accelerations to all or some of the offsets 3060 - 30B8 and 3178 - 31D0. These are all "writable" but have temporary effect, or at some have an effect and others may not. I know, for instance, the the aircraft carrier operations programs uses these for tailhook decelerations and, more importantly, catapult launchings. But I'm afraid I don't know which, if not all, would need to be written and which are totally ineffective, if any. If you went down that path you'd need to experiment. Regards, Pete

No. Just that is FSmetar is frequently setting the visibility to 6.2SM (9999 metres), and FSUIPC is randomly extending that each time, then sometimes it will be set less than FS's threshold of 10.4 or whatever and sometimes more. Please review the detailed explanations I've already given. I really don't think I can explain it any clearer. Sorry. Hmmm. Not sure what I should be looking for. Is that the weather DLL you are using? Is it for FS9.0 or FS9.1? Try restoring the original. Regards, Pete

I think the "View1 mode set" control should work. The parameters go like this (I think): 1 = cockpit 2 = virtual cockpit 3 = tower 4 = spot Regards, Pete

I'll see if I can find a way to do it. Regards, Pete

Sounds like the normal jerkiness on finals when approaching a densely designed airport, one with a lot of buildings or AI traffic or autogen scenery. It may be exaggerating the sort of slow-down you'd normally see because your process is being starved of sufficient time to do the updates at the intervals you need. What are the relative frame rates in FS, between your smooth results and these? That should give you an indication of what is going on. If you are running on a P4 with hyperthreading, check the Windows task manager -- see if you are using one "virtual processor" whilst FS is using the other. that should make things run smoother. If you are not using a P4 3.0 Gz or better, think about upgrading. Reduce your autogen density -- the autogen scenery has a greater and greater effect on performance as you near the ground. Once you land it is less because the views are then effectively two dimensional. See if reducing other density adjustments help -- scenery density and AI density. Regards, Pete

I don't know. There are several values displayed. What are they? When you press the Set above each column, that merely records the incoming reading at the time. You will have 4 of those. What are they? Then, on the left there are two values shown -- the input value (the ones recorded for the 4 positions), and the resulting output values after calibration. When you pull back below the lowest of the centre values, the output value will go negative -- that gives you the reverse thrust. When the input value reaches the lowest value, the "full reverse" value in the left column, the output will be at maximum reverse thrust. Nominally this is -4096, but that will then be rescaled according to the maximum reverse thrust available on the specific aircraft. Most offer less than this (25% of full forward), but some may offer slightly more. Don't forget that reverse will not engage unless there is no forward thrust at all -- check that you don't have any other throttle inputs operating. Also, of course, reverse thrust is not available on all aircraft. For the CH throttle quadrant I think you will find a lot of advice specific to that device on Bob "Sticky" Church's website. http://www.ch-hangar.com Regards, Pete

Good. The other key was a fake then. Thanks for letting me know. Regards, Pete

No. I'm not sure why you would want that. Reverse thrust levers pull back to increase thrust. No. Isn't that the same thing? The CH quadrant has a detente position for idle. You'd normally want to program reverse thrust below that, pulling back. You can, alternatively, employ a separate reverser axis -- either one for all engines, or up to 4 separate ones (using the current interim release 3.475 available above). In both cases you can, if you wish, reverse that axis, though it still seems to me an odd thing to do. Also in both cases you have to reduce the normal throttles to idle before reversers can be engaged. It isn't that you "can" assign reverser(s) to mixture control(s), they are already assumed assigned that way in FSUIPC. That can be changed by editing the FSUIPC.INI file, but the default is to assume mixture control inputs. Whether those mixture controls are actually assigned on your quadrant is another matter -- you do that via FS's Assignments, not FSUIPC. The reverser action is not programmed unless you actually calibrate the reverser (or reversers) in FSUIPC. Then they will operate, optionally on Jets only (there's a checkbox for that), but only when the forward throttles are brought back to idle first, as in real aircraft. It is best to calibrate the main throttles with a good reliable idle zone so that this can be assured. There is also a parameter in the INI file which allows you to set a higher value than 0 for the "idle" acceptable for reverse engagement -- but FS usually needs a true zero idle. When it is a separate axis you can choose to reverse it if you wish, just like all other axes calibrated through FSUIPC. Regards, Pete

It cannot make any difference for FS9's weather. I really don't know why you are seeing sudden visibility changes there. With FSMetar it reall depends what it is setting. If is doesn't determine its own variations in visibility when faces with a "9999" or "10SM" visibility report in a METAR (both of which merely indicate "above ...", with 9999= metres, or about 6.2SM, and 10SM obviously 10SM), then what might be happening is that, each time it sends new weather with "9999" or "10SM", FSUIPC is operating its "extend METAR max" option and generating a new visibility value greater than the 9999 or 10SM. In the case of 10SM, the likelihood of alternate random values being above and below the FS threshold of 10.4 (or whatever) is very small. However, when in Europe with 6.2 SM as the "max" there is obviously more scope for it to drop below FS's threshold. Maybe I should change the option so that it always treats both 10SM and 9999 as "greater than 10.4" in future, on FS2004 at least. If it is this option which is causing the problem then that would fix it. But try it. Turn it off and see if you still get the problem with FSMetar. If, as you say, you get it with FS's own weather, then it does seem unlikely that the option has anything to do with it. I don't know about that. Any details? You can do that easily in FSUIPC's joysticks section. Check the step-by-step instructions in the User Guide. You can also select a response curve which gives you more control near the centre (i.e. less sensitivity) whilst increasing sensitivity towards the extremes so you can still reach full deflection. Regards Pete

Okay. That's probably the correct legal way to do it in any case. I don't think these keys are intended to be transferable -- you'd need to check SimMarket's conditions to be sure. Regards, Pete

Because that's a better way to trap the pirates and thieves. Pete

Sounds fishy to me. But I can't tell unless you send me the file. Pete

Okay. That usually is an indication that something is wrong with your registration key. Can you zip up the FSUIPC.KEY file and send it to me at petedowson@btconnect.com and I'll check it. If you include the details you received from SimMarket when they notified it to you it will make it quicker for me to work it out. It is still sounding like a bad user key for FSUIPC. You did get it from SimMarket, didn't you? If not, where please? Regards, Pete