Pete Dowson

Nah, don't take it like that! The only stupid thing is not asking the question and suffering quietly instead! :lol: I don't mind, honest. I'm getting really relaxed over all this stuff these days. :) Regards, Pete

Well, it's been a long time since I was asked this old question! :( As it says in the FSUIPC User Guide: It works fine if you allow it to, honest. :) Regards, Pete

Yes, I think it is supposed to be. It doesn't appear to depend on the actual surface visibility, which is not good. It does change a bit when the cloud textures are replaced, but whether for the better or worse I can't really say. I ignore it by flying the aircraft and looking where I'm going, not where I've been! :) That's correct for FSUIPC because it should be smoothing the change between the 2 nm and the 20 nm. Try setting the rate of change of the smoothing to be a lot slower. You need to adjust things till you are happy. Try setting a lower maximum too. With the FS upper fog altitude being so low (2000 feet), lower limits suit things better, at least in Europe. In some parts of the world this wouldn't be so good. But on the transparency issue, you are right. Not only with fog, but clouds generally, Folks complain that even with lots of cloud you can see through them when above. And overcasts aren't! I actually get annoyed by seeing runways (only) as black bars straight through poor visibility and clouds, but I'm not sure whether this is only for my add-on airports or defaults. Maybe the add-ons (UK2000) are not defined in a way which allows them to disappear behind clouds. I've not seen any one else mention this phenomenon. FS2000 was, in my opinion, the best version so far for good visibility effects. The clouds weren't as good as in FS2004, but the visibility issues were all sorted. FS2002 was a complete disaster in that area, and FS2004 has recovered somewhat -- looking quite good sometimes -- but there's still some way to go. Regards, Pete

This is really a question for the Squawkbox folks, but it may simply be the differences in Multiplayer Protocol. The WideFS connection will probably look to SB like an FS98 installation (I don't think version 2 SB reads the FS version), so it will assume the wrong protocols. I think there will be parameters to sort this out in its INI or CFG file. For FS2004 you'll still need the relay program to convert to FS2002 protocol for SB2. Regards, Pete

It has always been there. It wouldn't be in "winds" in any case. It should really be in "Pressure" but as it would be the only option there it wasn't worth making a new page. It only affects the values being supplied TO FS, not what FS does with it thereafter. Regards, Pete

Well, yes, sort of -- but the "thin cloud" is supposed to look like the mist/fog covering the ground. Many folks don't like the effect at all, so I'm surprised you appear to not even see it. Replacement cloud textures may affect it. The graduating visibility that FSUIPC can apply should keep you in a diminishing fog in any case as you ascend. Perhaps you have one of the altitudes set wrong for that? Set the lower altitude to 0 to have it starting at the top of the FS layer. Pete

Sorry, you evidently have an error, but I cannot diagnose it from here. The values are used in very many programs with no trouble at all, including for instance my own TrafficLook which uses them to calculate distance and bearing to the AI traffic it lists. Similarly, Project Magenta, Squawkbox, and all the weather programs to name but a few. If you post a code snippet here I am sure someone can spot your error -- I am okay with C or C++ but other visitors know Visual Basic and some even Delphi, possibly. Regards, Pete

I don't know what weather you are using. The default FS2004 visibility layer isn't very deep, and when you fly above it you normally will get the default "unlimited" value. In FS2004 they did add a sort of thin cloud graphic to the top of the visibility layer, but I think that can look odd too. Some of the replacement cloud textures available change that or even may remove it. But is should fix the sudden changes. It certainly does here. Turn on the FSUIPC graduated visibility option. Use that in conjunction with the FSUIPC visibility maxima and the smoothing. It does nothing at all unless you are getting weather inserted from an external weather program, or you are forcing Global weather only at intervals in FS and have the FSUIPC technical option enabled to make FSUIPC fiddle with FS global weather. In those cases it overwrites the upper altitude set for the surface visibility layer with the value you put there. You might do that to set a higher value than the one being set by the weather program. I can't see why you'd ever want it lower, but you might if a weather program set fog up to 30000 feet! :) Your best bet is to enable all three options marked *** on the FSUIPC visibility page. Regards, Pete

Oh, thank you very much. :oops: Pete

Er, why does exiting FS hit your system? I think the exit control is pre-programmed in FS as CTRL+C anyway, isn't it? I always use ALT F X and that closes FS instantly also -- unless you have the option for it to ask for confirmation first. If that's all that is worrying you just disable it. Regards, Pete

I don't use C++ or MFC, Only pure C plus a smattering Assembly Code where I need real tight code or want to do something even C doesn't let me. I think JD might be better off moving to something like Delphi. That is pretty powerful. In my opinion VB is the worst choice, but .. it is only my opinion! :lol: Pete

It would vary a lot if I didn't limit it to 20 fps. I have everything up full, and I am running the display over three screens at 2400 x 600. This is on a 3.2 G P4. This is also with no FS panel at all. If I add a panel it gets slower. It is a lot slower in any case at night, and in dense add-on airport scenery. The Parhelia is a slow card, it cannot anywhere near match the current fast ATI and nVidia cards. For me it is worth it for the superb widescreen outside view, but I wouldn't use a Parhelia with a Panel. As it is, my frame rates don't drop below 10 at all, and generally are hitting the limiter at 20 (usually 19.9), and it is smoother that way. I prefer a slow constant rate to an occasionally fast but jerky one. Regards, Pete

You should still be able to get the ones that are windows. They will be child windows of FS98MAIN, so you need to look for that and go down a level. I don't know if al individual gauges are FS windows though. Pete

Sorry, what's "force end"? Pete

I don't agree. You cannot map via the offset you quoted, that's for sure, so it must be wrong. The stuff you quoted applies to SB3 -- is that now released? Certainly SB3 has got a range of offsets allocated in FSUIPC, and that is what Joel is no doubt referring to. I see no reason why you shouldn't do what you want to do with SB3, provided you get the correct offsets from Joel. Regards, Pete

I don't fully understand the part "squawk Standby/Mode C/Ident". On a real transponder there are usually off, standby, on, alt and test modes -- your "mode C" is the ALT mode. The ident is usually a separate button. But I don't think these are implemented in Flight Sim. So I assume this is some input to Squawkbox specifically? Erwhich CFG file? Squawkbox? FSUIPC only has an INI file, but you program buttons and keypresses in the on-line dialogues. I wouldn't do it by editing the INI file. If the offset 0x8060 which you refer to is an FSUIPC offset, then I'm afraid nothing other than FSUIPC can use that -- it is within a write-only are used as part of module registration. Please see the FSUIPC Programmers Guide for more details about FSUIPC offsets. So you do really mean that you are trying to edit the FSUIPC INI file (there is no CFGg file)? Why? Why not just use the facilities provided in the options, as fully described in the documentation? There's no reason to edit this stuff in the INI directly unless you want to add conditional programming or multiple sequences. Please try looking at the main User Guide and going the simple way first. Even so, you cannot use offset 0x8060. It has certainly never been allocated to any other application. Regards, Pete

Really? I don't know how it is doing that. If each of the gauges were separate Windows, then I suppose you could simply find their handles and flip the visibility bit. With some functions you can set it Failed or Operational. Whether this merely stops them working or also covers them up, I don't know. Check the FSUIPC offsets 0B64 - 0B73 and 3BD6. Undocked panels and gauges will be individual Windows, so you should be able to get their Window handles (hwnd) using normal Windows API functions. They'll all probably be class "FS98CHILD" or something like that, so you'll need to check the titles to get the right ones. Try using the Spyxx program in the Windows compiler packages to check the Windows directly first, so you can figure out what to do. Regards, Pete

Yes, it looks to be freeware. But more importantly it is not Eric Marciano's aircraft but it is supplied with Eric's panel. That is probably why Eric is not willing or bothered to issue the Keys I gave him -- he presumably assumes it is then the responsibility of the author who "borrowed" his work and put it in their own. As described, and illustrated, in the FSUIPC user guide. Enter the complete gauge name, i.e. F16.gau, and the Key which is DSVT JE5S 6DUO Regards, Pete

With everything else EXACTLY the same? i.e. same flight, same aircraft, no add-ons, nothing? If it crashes with FSUIPC just sitting there doing nothing in exactly the same circumstances as when it doesn't crash without FSUIPC installed, then it has to be some timing glitch causing a problem, probably with rth video driver, or still possibly a corrupt weather file (FSUIPC will be reading weather data from FS still, in case anything wants it, so WEATHER.DLL will still be accessing data it may not otherwise do without FSUIPC running). You have a PArhelia? So do I! I have been using version 1.05.01.008, dated last November, since then without any problems. I know some of the Parhelia drivers have problems. I'm not sure whether mine is Beta or not. Where do you get Betas? I just followed a link someone gave me. Regards, Pete

I don't see what happened? You omitted something? When you save a Flight (see Flights menu in FS), FS saves two files on your disk, one with a file type of FLT (for "FLighT") and the other with a file type of WX (for weather data). If you ever saved a flight you are probably using files you saved, which may be corrupt. This is why I suggested trying one of the default Flights which came with FS. Yes, it must be, but it sounds indicative of something not quite right on your FS installation. I believe you when you say you haven't set anything in FSUIPC options, but in that case before you load FS next time, delete the FSUIPC.INI file from the FS Modules folder. This is certain to reset it to its defaults, and as you hadn't changed anything you won't lose anything. Regards, Pete

Ah, that's better. You should have got that the first time. Yes, the Log shows that the F16 Gauge is not accredited and is not providing the key. That's odd because I did supply a Key for this, to the author Eric Marciano. Or is this a different aircraft? Can you confirm that it is freeware and by Eric? If so I can give the the Key I gave him. If not, then your only alternative is to register FSUIPC as a paid-up user. Regards, Pete

HmmmI use all the Project Magenta stuff here, plus weather programs, radar contact, all sorts of things. Something's not right somewhere in yuor system. What happens, for instance, if you don't install WideFS, or don't run the Project Magenta stuff? Are you using different FLT+WX files when using PM, or a different aircraft. Something is different. A corrupted WX file can crasg WEATHER.DLL too. FS will either complain and fail to load, or it will load and crash. It's one of the essential parts of FS, not an option. I'm afraid it's going to be a process of trying different changes, one at a time, till we isolate the cause. It might be quicker to start afresh with a new FS installation. Do you have a lot added to it? If you have enough space on the disk you could try renaming the FS folder and installing a second parallel copy, then adding stuff a bit at a time. Trouble is, if it is a corrupt WX or FLT file, they'll still be there, so first off try, in your current installation, selecting one of the default Flights provided by FS and make that your default one, for now. Oh, one other thing to try first -- make sure you are using the very latest video drivers for your video card. Some of the video problems have turned out to be very sensitive to small differences in timing, and just adding FSUIPC or WideFS can make such differences. Regards, Pete

You don't give enough information. By themselves FSUIPC and WideFS do nothing, they just sit there. What are you actually using them for? i.e. what programs, DLLs or gauges are using them? The clue will be there. Also, what options have you set or changed in FSUIPC? Crashes in Weather DLL are almost always due to bad weather inputs, so if you are running a weather program or anything else setting the weather, that is the first place to look. FSUIPC is effectively a "window" into FS and programs can do mostly whatever they like. Crashing FS is easy that way. If you are running anything using FSUIPC/WideFS then you need to undertake a process of elimination to ascertain what is causing the problems. I really have no other reports of such a problem at present, and there are many users with FSUIPC, WideFS and GoFlight equipment, I assure you (I am amongst them). So it is something on your system and we need to track it down on your system. BTW when you say you "renamed" the modules, did you change the filetype so it wasn't "DLL"? If not, they will still be loaded and run -- but FSUIPC will use a new default INI file and won't recognise your KEY file so will be unregistered.. Regards, Pete

:D :D Thanks ... ... but actually most of the time when I'm not here answering folks I am instead programming like crazy. It's FSUIPC update month again, and WideFS as well. Lots to do, must get busygoing on holiday mid-Feb so I'll make some sort of release before then. I'll try to actually fly at least once a week from now on. Thanks! :) Pete

FSUIPC is not the correct vehicle for this. What RC will want is a database of taxi routes, in a format it can process efficiently, in its folder. No doubt John or someone, armed with the AFD file formats, can make such a database -- or rather, a database generator, because it would need to be modified each time the user added new scenery with possibly different AFDs. FSUIPC is for finding data out from inside FS. I have no idea if FS keeps taxi route information internally at run time, nor if it does what on Earth it would look like nor how to use it. Even knowing the AFD formats doesn't help, and in any case this is truly the wrong way to go about it. Why a DLL? Why a program anywhere near FS? All that is needed is the data. It is static, not changing all the time (only when the user updates airports). It is silly wasting FS processor time on re-deriving the same taxiway information again and again. It is just more data like the existing runway date RC has at its disposal. There's much more work in devising algirithms in RC for finding the best/proper routes along the taxiways. Even then, maybe that can be done for all possible Gates to all possible thresholds in advance, by some clever AFD extraction and analysis program. Are you volunteering, then? :) Pete