Pete Dowson

Ah, interesting! Seems that the indicators give misleading results with no power? Did the gear actually deploy/retract? Regards, Pete

Please check things out using FSInterrogate. What does that show? Try it with different aircraft. Pete

GPSout can only relay the information it gets from FS. I don't notice this sort of "error" when using moving map type programs -- e.g. Jeppesen FliteMap -- which is what GPSout was designed for (i.e. to emulate a GPS rather than provide simulated input to one). I think the error is simply a function of the GPS, entirely, and probably a result of some algorithm intended to deal with temporary losses of signal -- as in cars when passing through tunnels or through tree-lined avenues. It simply refuses to believe that the aircraft can suddenly stop dead. Understandably. Regards, Pete

The check for a duplicated module has been in FSUIPC, unchanged now, for around 2 years. There's really no difference in any of the versions as far as this is concerned. Somewhere, somehow, you have either FSUIPC duplicated or a close look-alike which has the same ID. Or you actually have FS still running someplace -- that would generate the same symptom. You said "I took out the old module. Gone. Dead. No more", but why ever bother? FSUIPC is called "FSUIPC.DLL" and Windows only ever allow one copy of a file with the same name in any one folder. All you have to do to upgrade from one version of FSUIPC to the next is to copy the new version into the FS Modules, folder, exactly as it says in the instructions. Windows may ask you if you really want to replace the file with the same name, and you confirm "Yes", and that's it, job done. Please re-check. Look at ALL of the Modules, the DLLs, in the FS Modules folder. Aren't there any there that don't look right? Also see if there's a copy of FS lurking, unseen, running with no windows. If you are using WinXP do this by CTRL-ALT-DEL, check the processes list. If it is there, elect to end the process. If you still can't fgure it out, let me know and I'll send a little BATch file with lists the DLLs to a text file so I can check it for you. Regards, Pete

Did you receive the test version of FSUIPC with the cowl flap facilities added? I sent it on Saturday. I think it should all work well, but I could do with some feedback in confirmation, when you've got time, please. Regards, Pete

I sent you a test version on Saturday and have been waiting anxiously for feedback, as it may also affect WideFS. After three full days I got this back: This presumably explains why I've not heard from you! :( Can you please let me have an email address which works? Maybe I can send it to you using the email address you use to come here? Would that be okay? Regards, Pete

Go to http://www.simmarket.com and open your account there. According to all reports you can then retrieve your Key without any problems. Pete

Well, short of writing a separate program to read the FS menus and reproduce them on a client PC, and be able to impose the correct keystrokes to active the selections made remotely afterwards, no, I've no idea. I can see that possibly a remote menu system could be devised, but it is a rather substantial project and certainly outside what I would consider the realms of fSUIPC. In fact it would probably need to be a separate EXE in both the FS PC and Client PC in any case, just using spare offsets to communicate -- FSUIPC cannot handle FS menus because it is effectively not running when the menus are in operation. A separate program sending the keystrokes directly to FS is not so inhibited. If you rather meant somehow finding a handy procedure someplace inside FS which loads a specified Weather Theme just by calling it with the filename as parameter, much like the one I do know of to load a flight, then, sorry, but that would involve a lot of work disassembling and analysing yet more FS code, something which takes many hours and may prove useless even then. I just don't have time to consider such things at present. Determining the filenames of possible weather themes you could load can of course be done directly by you -- just look in the FS folder "Weather\Themes". The files are those with the .wtb filetype, but the .wt ones contain the titles and descriptions for the menu. The BMPs are simply for display only. I think there's also an official Weather Themes SDK from MS which you may find useful. Regards, Pete

Well, if I had a copy of the Dash 8 and some better description of the problems I could have a look and maybe advise PSS what their problem is, if it is indeed anything related to things I understand. But if PSS have stopped support there's maybe not a lot of point. They were pretty good at one time, and even sent me aircraft to check out. Ah well, nothing good seems to last these days. :( Regards, Pete

Was that when you had the autopilot on without realising it? Something you only do once, though. But a real A/P would (should?) disengage if you move the controls enough. At least I think they do. Regards, Pete

FSFK? I'm not familiar with that acronym. Ah -- it looks like their uninstall isn't so good then! Seems that they arranged for their program to be loaded by FSUIPC but didn't remove the inserted parameter when it was uninstalled. You'll need to edit the FSUIPC.INI file (in the FS Modules folder) and remove the line in the [Programs] section which tells FSUIPC to run it. Do this when you are NOT running FS. Regards, Pete

Aren't there some third party programs that can do that -- set up complete weather situations based on a theme? The FS2004 "themes" are a different thing altogether. They are programmed in some new format for FS to load. I have no idea how they work at all I'm afraid. Ahthat must be one of the 3rd party programs I meant. Can't that be run from your instructor station? I don't really think FSUIPC should get involved in actually creating weather. Regards, Pete

No, not at all. I really can't see what sort of conflict there could be, to be honest. Especially when the limiting version of FSUIPC was apparently 2.8 which is over two years old! You'd think someone would have mentioned something during those two years or more, whether PSS or a user? The only description of the 'problem' I've received is the one above: "goes into a freeze thaw mode", which I don't understand and cannot visualise. Regards, Pete

There is none easily available. You'll need to work out how to do it. start by writing a Gauge. Gauges are just DLLs loaded by PANEL CFG files. Well FSUIPC is synchronised to FS's frame rate -- it needs to be because aynchronous settings can upset things. If you aren't achieving a smooth change via FSUIPC I think you need to look again at what you are doing. Attempting 50 fps is a bit ambitious in the first place -- you are allowing 20 mSecs per frame including the process swapping needed between your EXE and FS. Maybe in a Pentium 4 3.0 or better with hyperthreading you can achieve this, with many FS settings turned down, but even then I would think it doubtful. Try 25 fps, with the FS frame rate limiter set to 25 so that it doesn't do more than it has to. Regards, Pete

No, it isn't strange at all. I now see exactly what is going on. (You didn't check with FSInterrogate as I asked, did you? Then it would have been more obvious to you too :wink: ). I missed this in your last message: 26172 Write: Offset=0262, Size=0004 You are writing 4 bytes to a 2 byte field!!! Only write 1 to the 16-bit (2 byte) control value at 0262, as documented. Writing to 0264 is trapped by FSUIPC and converted to a write to 0262 in any case --- it does this because for a long time some lists showed 0264 as the control, not the indicator. Writing 1 to 0262 and 0 to 0264, as you were doing, will actually write 1 then 0 to the control, so setting the pause ON then OFF. Sorry I missed that before. I see you are also writing 4 bytes now to 0264. This will write zero to the two bytes at 0266. That could do something unexpected too. Never write to someplace you don't know unless you want surprises! There are lots of things in that program which I have no idea how to access. The author is privileged by being part of the FS team. I don't get the sort of information he gets. I you can work out how I can retireve it, I will see if I can add the correct code into FSUIPC, of course, but I think it will be a lot of work -- it took me long enough to get the information I am providing. Sorry. Regards, Pete

Sorry, I've no idea. Try it with FSInterrogate, it always works okay here. Also use the FSUIPC Monitor facility to monitor the value in 0262 in real time (eg. on screen by AdvDisplay selection in Monitor). Also check it with IPC write logging in FSUIPC, and check it with your program running locally to FS too. Regards, Pete

Sorry, but it isn't FSUIPC, and it won't be FDC either. There are several main possibilities -- video driver (ensure you have the latest non-Beta for your card), bad gauge (add-on panel/aircraft, or corruption), bad scenery (add-on or corruption) or bad sound file (or even sound driver), etc. It could even be a bad WX file (WX files are weather files associated with FLT (flight) files. Try starting off creating a complete new flight instead rather than loading an existing one, just in case. Also try different aircraft, especially the default ones, in case it is something in an add-on aircraft, panel or gauge. Generally, though, the only foolproof way I know to resolve such things is to uninstall each add-on in turn till the problem goes away, then add the others back in. However, even that doesn't always work because the add-ons don't always uninstall in a way which returns things to the way they were before. So the most definite way, assuming you have enough disk space, is to rename the FS folder, then install a fresh copy of FS. Check it out, then add one add-on at a time, checking at each step, until you regain your full system, but now working, or discover which it is that is crashing FS. Then you can either remove the old installation, or remove the discovered culprit from that copy and re-test that one. If you don't have enough disk space and no other method solves the problem, then I'm afraid a complete de-install of FS and re-install of everything would be called for. But be sure to check things out at each step. Regards, Pete

Well, my window is supposed to be also a modal window within FS. It is created within FS (my application is a module, i.e. a dll loaded by FS) and seems modal as expected (FS hangs until my window is closed). The only non-modal visible effect is that damn black screen. Ah, well that's odd then. I can't imagine why yours makes the black screen and mine doesn't. Hmmm. Pete

Ah, the black screen. That is easy to get without programming. I really don't know what sort of mess DX8/9 is in, but black screens seem to be typical. I wish I knew the answers. If you do solve them, please let us know. It is likely that the only difference between yours and FSUIPC's window is the fact that FSUIPC's is a modal dialog within FS, so most of the normal FS activities are frozen whilst it is active. I don't know that there's any way of accomplishing this from an external program. Regards, Pete

Without any doubt, choice 1 -- with one proviso. Keep the copy you wrote back and use that, don't read a new one, if the next update is within, say half a second or so (you'd need to experiment). If more than this interval occurs with no update, read a new value from FS next time. If you don't take this precaution then you may get stuttering or stuck values as you read back the previous value -- i.e. before FS has actually implemented the change FSUIPC has sent to it. This is the technique I used for the FlightLink TR-1 and KR-1 stacks (via EPIC), and I also do this in the PFC driver. Sending increments and decrements leads to overruns or overruns, it just isn't precise because of the message queuing in Windows and in FS. In FS98 there were no such problems because the actual values used by FS were those in the locations you could write to directly through FS6IPC or FSUIPC. The same was more or less true in FS2000, but it all changed drastically in FS2002 -- FSUIPC can only make the changes effective by calling procedures in FS. Sorry, but really option 1 is the only way of ensuring that. Regards, Pete

No, never as low as that. Certainly it can dip to 10-15. This is okay for airliner flying, which is all I do on that PC. I have all the weather sliders up to maximum -- no 2D clouds, I don't like them. But one big difference, possibly, is that I have no panel at all -- the 2400x600 view is full-screen scenery view only. I think that will make a lot of difference. If you are using a panel , try to find one with a good virtual cockpit (so it all runs as one 3D view) -- I think the imposition of the 2D panels has a considerable impact. I only have 1Gb main memory, but the Parhelia is the 256Mb version. Not that this should make any difference I think. I have been through the list of XP services which are running and tried to cut those down to a minimum -- anything that looked unnecessary for FS is disabled. I only use that PC for FS, so this is relatively easy -- though you can set up separate profiles which give you a choice at XP boot time if you want dual use. Also the only other process I have running with FS is the Project Magenta MCP (with no Window for it -- it runs in the background). I used to have this on a separate PC but the Hyperthreading on the P4 3.2Gb seems to allow it to run with FS with no adverse effects. Regards, Pete

No, never. You just copy the DLL into the FS Modules folder. That's it. Upgrade done! Do not delete your FSUIPC.INI or FSUIPC.KEY file or you'll need to start all over. Only do such drastic things if they really get in a mess, but even then keep a safe copy. Regards, Pete

I'd like to know that too. Even to stop the FSUIPC options dialogue flashing in FS2004 full screen mode I have to intercpet the WM_PAINT messages to FS's Window and validate them without passing them on. Try moving the FSUIPC options window and you'll see one of the horrible results. I asked the FS team why this was and they just said "blame DirectX8, it's out of our control" (FS2004 is programmed to the DX8 API). Regards, Pete

I thought FS2004 provided you that access? What else could you want? Sorry, I'm nissibg something here. Pete

That's only because they were using the FSUIPC-computed value, not the standard one than most things use. For performance reasons I didn't want really to do this on every frame, but as PC speeds have increased it is less noticeable. I don't think I've got any VSI and RPM values which are computed by FSUIPC. The mapped ones should update once per frame, same as the Altimeter readng. I can't do better than that. What actual offsets are they reading for these? BTW I have an Aerosoft GA-28 panel which looks somewhat similar to yours and I must admit that I don't notice any stutter with any of the instruments. Their altimeter in that setup uses the original method, so wasn't affected by the FS computation change -- since FS98 days the original method was to read the actual altitude, the QNH and the Kollsman setting, and compute the value to be displayed. Regards, Pete