Pete Dowson

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

There's no problem actually shown in the Log extract you provide. The section 49516 AIRCRAFT\VIPER\VIPER.air 54203 C:\Program Files\Microsoft Games\Flight Simulator\GAUGES\F16.GAU 54203 not listed in Key file 192484 READ1 02A0, 2 bytes: 34 0E 192484 READ1 0560, 24 bytes: 00 00 92 DB 31 6E 50 00 00 00 merely says that the F16.GAU isn't listed in the FSUIPC.KEY file. That doesn't mean it doesn't have access. It may be supplying its key automatically. I could tell if you enabled IPC write logging, instead of read (why DID you enable IPC read logging anyway?). If it was being refused entry there should be an error message in the log saying so -- there isn't one. In fact there's nothing for over two minutes after it starts. Did you suddenly decide to turn the IPC read logging on after 2 minutes? That doesn't help. The gauge may simply be reading the FS version and deciding it doesn't like FS2004, so it isn't running. Have you checked with the author, (Eric Marciano?), to see if it is supposed to work in FS2004? Many of the FS2002 gauges have such checks. I do have a fiddle which you can try if that's the case, but let's get more information first. It looks most unlikely that this is anything to do with registration or accridatation. Don't run TrafficLook, that confuses the issue, and enable IPC read and write logging BEFORE loading the aircraft. If it's your default, enable that logging then close down and restart FS. Regards, Pete

Hmmm. So the one they supply for home use is not so good, really? I use a fully and regularly updated Norton AV and that says it's okay too! :) Thanks, & Regards, Pete

Just load up FS, press ALT M F to get into FSUIPC options, press the button saying "Register an application program", enter "FSMetar" as the program name and the Key you know as the Key. Press OK. Why is this difficult? It is exactly as described and even illustrated in the User Guide. It is simply entry of the program name and the Key. If you like you can instead edit the FSUIPC.KEY file and add it in there, but you are sure to make a mess of that if you are so careless with your spelling. Anyway, why would you make a real mess, and how on Earth do you think a mistake will mess anything else up? Do you really think that I'm such a poor programmer? I'm really not at all surprised you had problems with Squawkbox, as you've not spelled it correctly once in your message -- is is NOT "Squackbox", nor "Squakbox". Please just try to be a little more careful and enter the correct names, not ones you invent yourself! Regards, Pete

You would have to write a program to handle the serial port and thence interface to FSUIPC. The interface for FSUIPC is described in the FSUIPC SDK, available from http://www.schiratti.com/dowson. However, you should be aware that many third party cockpits have their own autopilot system. Whether the PSS A320 autopilot can be controlled programmatically I don't know. You should check first. If it accepts keystrokes your program may be better off reading your COM port data and sending keystrokes to FS. You can do that directly, emulating a keyboard in Windows, or sending FS "WM_KEYDOWN" and "KEYUP" messages, or, perhaps more reliably, do that too through FSUIPC (see offset 3200 in the Programmers' Guide). Alternatively, if you want to be able to program which keystrokes to use in FSUIPC, and maybe use your input for other things too, you could make your program operate the "virtual joystick buttons" FSUIPC provides (offset 3340) and program their action in the FSUIPC "Buttons" page. This method is probably simpler than the keyboard method. Regards, Pete

Sorry, I have no idea. What was your previous version of FSUIPC? I don't know Weather Center at all I'm afraid. If the previous FSUIPC you had it working with was 2. something, perhaps the Weather Center program has some version check which is wrong? Otherwise, if you enable some of the logging in FSUIPC then maybe we can see what it is doing. There's an option for weather logging, try that first, but it may be that you need to enable the IPC read/write logging too to get enough data. Are you also asking the Weather Center author? Regards, Pete

Ah, NOW I understand! You are confusing the setting to limit the surface wind with the FS2000/FS2002 "Taxi Wind" facility, which was entirely different. That operated by directly changing the wind experienced at the aircraft, without changing the weather, as such. The surface wind you are limiting is the lowest wind layer, i.e. the whole layer. There is no taxi wind facility in FSUIPC for FS2004 because I couldn't find any way to get to the wind actually imposed. If I could, I would be able to smooth it too! I'd love to do this, but in many many hours or hacking through FS code I haven't managed, and there are other things needing doing. Please check through the FSUIPC User Guide some time. It does actually mention all these things. You certainly were NOT using the same option in FS2002. Well, two points there: (1) The option doing that in FS2002 was the Taxi Wind facility. You are not using the option you used in FS2002. You are limiting the surface wind layer's speed actually being set. (2) Because the wind being set IS limited to 1 knot, that IS the wind, there is no other, so that is what ATIS correctly reports. Regards, Pete

If you set the weather sliders in FS's Options-Settings-Hardware all to maximum, you shouldn't have many occasions where clouds appear suddenly. That's usually due to limited cloud drawing distances. They may still pop up at that maximum distance, but it is less noticeable. Make sure you have 100% 3D clouds as the 2D clouds are notoriously bad both for popping up and flickering. FS2004's own downloaded weather "morphs" the clouds -- i.e. it grows them and shrinks them. I've been trying to find a way into that mechanism in FS2004 but it is simply so complex I don't have much of a hope. Microsoft won't help, at least not until FS2006, by which time I hope to have persuaded them to provide some weather interface so that third party weather programs can compete. As far as wind shifts are concerned, FS should be interpolating those correctly between stations, but there is certainly a bug in the FS code as 180 degree wind shifts can occur -- even with their own downloaded weather. It is not a phenomenon limited to the add-on weather programs at all, though, since the weather they provide tends to be more complete, more varied, it may be more likely. I know both the main weather program authors are trying very hard to find ways around the problems in FS2004 and I expect both FSMeteo and ActiveSky to be superior to FS's own weather in due course. FSUIPC's smoothing can only smooth what is going IN to FS's weather stations. Except for visibility (which I found a way to bypass) I cannot get to the actual wind and clouds being presented in the simulator, I can only smooth the inputs being made to FS. What it then does with them is outside my control. I don't know FSMetar, sorry, so I cannot even advise on what steps it may be taking. I think you'll need to ask the author. I only have regular contacts with the authors of FSMeteo and ActiveSky. Regards, Pete