Pete Dowson

Not quite. In the UK the requirement is that all IFR flights in controlled (class A-E) airspace must file a flight plan. In uncontrolled airspace (F/G) a flight plan is not required Sorry, I was referring to FS. Pete

Sorry, I don't know any way to do that other than by calling the Load Flight routine. In FS2004 there is a "reload aircraft" control which you could send via FSUIPC, but that doesn't change the aircraft, only reloads the current one (presumably to reset its systems or conduct repairs). Regards, Pete

These are really questions for PM support. FSUIPC is merely the messenger, it doesn't read the contents of these things nor act upon them. However, as to your first question I think it means that his program has no way of telling that you want two successive characters the same if nothing changes -- the only way it knows you've done anything is because the value changes. So, you have to make a change that doesn't matter. It looks like the word "bytes" there should in fact be "bits" -- just change one of the unallocated bits in the high byte each time you send a character, then it will know about the change. Sorry, I don't know anything about the second question. Regards, Pete

Unlikely. Most everything in FS nowadays is procedural -- I actually have to monitor the writes to many many things and use the written data in parameters to calls into assorted FS DLLs. The problem is finding the right place and the right parameters for each need. It is made extremely complicated also by the fact that much of the code is now Object-Oriented C++, not the original ASM + C of FS95/98, and many things are inherited or polymorphed or otherwise OO-ised, necessitating finding the right pointers to the right structures/tables beforehand in each case. Sometimes an apparently simply thing takes several calls to several hacked entries in several different DLLs. Ugh. Yes, but when there's so much else to do in any case, trying to solve the same problem someone else has solved already is wasteful and not enticing. The quickest way would be for me to find out how ActiveCamera does it, but that is against my principles as well as wrong. Sorry. If the ActiveCamera author wants to volunteer the information "for the common good", then that is another matter. I can add stuff in that folks tell me about. That's how a lot of the stuff got in there in the first place, starting back in FS95 or even before. Regards, Pete

You still have to file a flight plan. All IFR involves flight plans. But you can specify your alternates and declare emergencies. Radar Contact does not handle VFR at all. The main difference from the old days of ProFlight and Radar Contact 2 is that RC is now a separate program, and runs fine under WideFS on a separate PC. This has several advantages, the main one for me being the separation of the ATC voices to a different set of speakers or, more realistically, a headset. Using one of the voice recognition programs you can actually then have ATC completely on headset without affecting the normal FS sounds on your main FS PC. Radar Contact is getting more and more sophisticated all the time and some amazing things will be seen as it develops. If you are really into ATC I strongly suggest you give it a try. The authors are very responsive to sensible and constructive suggestions too, so anyone who knows his stuff is always welcome and should ask to get on the Beta team to help development. Yes. But it doesn't know taxiways so you won't get taxi directions. It's up to you to find the runway for departure and the ramp/gate after arrival. Ah yes, you are right "Sidewinder Game Voice" it was called. It came with a headset (Microsoft-badged Plantronics) and a gizmo for connecting it to USB as well as sound card. It was the only one I ever found which would recognise things pretty consistently without even any training. Yes, but from what I've read here and there folks do seem to find that it works. As I said, Game Voice seemed pretty good, and I was surprised how well it worked even with the FS sounds all around me on normal speakers. Voice Buddy worries me a little as it seems to imply you have to have all the sound on the headset. Regards, Pete

If FSUIPC recognises the hat positions as buttons, yes. If not, no. Whether it does depends upon how it is programmed in the joystick driver, I think. Try it -- go to FSUIPC's Buttons page, and move the hat to different positions. See if those are seen as different "button numbers" in FSUIPC. If not, then I'm afraid I have no answer for use of the hat. You'd have to find some other buttons to share their functions. Yes, you'd still need a button (or key) to set the flag so that this special programming can be conditional. You could make the condition on another button being pressed at the same time, but that's a bit more awkward to use than toggling a flag, and you still need a dedicated button or key in any case. Well, maybe it didn't get enough attention, but however they implemented it you'd still need some means of selecting between choices, so I don't see how you'd do without some use of buttons or keyboard. I don't use FS's ATC. I find Radar Contact much more satisfactory. And it certainly is a lot cheaper than a radio stack. However, neither solve the problem of needing keys or buttons to select responses. One other solution you might consider is some form of voice recognition, so you can talk to FS to execute the responses. Voice Buddy seems the latest popular add-on for this, but it looks like, for that to work well, you have to have all sound via the headset. I did for a while successfully use Microsoft's own Game Commander package, which may not be available now but wasn't so restrictive. Regards, Pete

You can program the keystrokes to your buttons in FSUIPC's Keys page. That's all described in the User Guide. If you want the hat to be ignored for this purpose at other times you'd need to then edit the FSUIPC.INI to make those keystrokes conditional. You could make the spare button used to call up the ATC window (either by control or the keyboard '@ key, whatever) also toggle a Flag which would be the condition on the hat button programming. Details for this sort of thing are in the FSUIPC Advanced Users Guide. Regards, Pete

Ah, sorry about thatit's always been that way though. At least you won't make that mistake again! :) Regards, Pete

They are actually 'original' Global.DLL values, unmapped by FSUIPC, still in the same place over several FS releases. FSUIPC doesn't stop you writing to them, but I don't think that does you much good. Have you tried? Let me know if you can make it do anything. True, though without hacking ActiveCamera I don't know how it does it. I'm not going to hack into someone else's program to provide methods to bypass their code. That's unethical as well as technically illegal. It seems to be. I added these only because someone else told me about them. Since ActiveCamera already does such a good job, I know not how, this isn't really an area I would dedicate time to. Sorry. Let's solve new problems, not try to reproduce other's solutions, eh? :wink: BTW have you tried any of the "Eyepoint ..." controls FS offers? Don't they do anything useful? Regards, Pete

Download the current version from http://www.schiratti.com/dowson, and copy the FSUIPC.DLL from the Zip to your FS Modules folder. If the version installed by Flight Deck III is earlier than 3.00 then you may need to pay for and register the later FSUIPC, depending on what permissions Flight Deck III has. Sorry, I do not know. Regards, Pete

Okay. Thanks for confirming. I'll release it generally in the morning. Regards, Pete

It's a problem of DirectX 7, as used in FS2002, which had a limitation of 2048 pixels in any dimension. Provided your window is less than 2049 pixels wide it will work. You can use full screen at 1920 x 480 (i.e. 3 x 640 x 480) -- I used that quite happily on FS2002 from October 2002, when I got my first Parhelia, until FS2004 came out. For scenery only I found 1920 x 480 perfectly acceptable. Regards, Pete

No promises, yet, but I am now looking at dedicating a 256 byte area to string replies to a series of requests for path type data. So far there are only two of this type -- yours for the path to the FS default FLT folder, and another for the path corresponding to the Traffic ID used in the TCAS tables. But there will no doubt be more needs in the future, so it may be time for a generic solution. I think if I design a system of requests + answers, allowing a variety of types of reply, I can justify the offset space needed. I shall probably re-use some global space which appears currently useless in any case, e.g. 1000 - 10FF. I'll do some further investigation into all this and get back to you some time, maybe this week, possibly with a test version. Okay? If I do this it will work with WideFS too, of course. Regards, Pete

But they'll carry over from your current FSUIPC.INI file, unless you delete that as I suggested. Do I need FSUIPC.DLL in the modules folder in order to run my licensed version of WideServer/Client? Yes, WideServer will not work without FSUIPC. WideFS is an extension to FSUIPC to make its interface work over a Network. If your FSUIPC isn't registered, then none of its joystick facilities will be operative in any case. Pete

Hmmmthere are a lot of programs using those facilities without any problems. I need to see the logging to see if there's anything out of the ordinary. Ahare you Michael Garbers? If so, it has just arrived -- I'll look at it now. [later] Hmmm. It would have been a much smaller log if you had only enabled IPC write logging -- we don't need to look at reads. Anyway, I think you have made a rather nasty mistake. See this: 119592 WRITE0 3380, 128 bytes: 48 41 4D 42 55 52 47 20 44 20 32 30 35 33 20 41 ... 119592 WRITE0 3400, 32 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 ... 119592 WRITE0 3420, 8 bytes: 00 00 00 00 00 00 00 00 119592 WRITE0 3428, 16 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 119592 WRITE0 3438, 32 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 119592 WRITE0 3458, 79 bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... You appear not only to be writing to the 128 byte message area at 3380, but also another 168 bytes, right up to offset 34A7 -- a total of 296 bytes!!! (You may be doing this in one "FSUIPC_Write" -- the reason they are logged like this is that each of the offsets you see listed is mapped internally to a different place within FS). Some of the offsets in the 34xx range are known and documented in the second table in the programmers guide, but the others could do anything in FS, and probably different things in different versions. you should never write to unknown offsets or write to offsets which are known but which you don't want to change. Your write to 32FA seems odd too: 119592 WRITE0 32FA, 2 bytes: 00 03 The value 0300 is 768 in decimal, saying "display this for 768 seconds". Are you sure that's what you want? Regards, Pete

FSUIPC doesn't touch anything to do with joysticks itself unless you've asked it do. EITHER go to each of the FSUIPC Joystick pages and make sure every axis has a button that says "Set" on the left -- if it says "Reset" press it to reset FSUIPC's calibration OR, possibly easier, either delete the FSUIPC.INI file to make it start over with defaults, or edit that file and remove the joystick section completely. If the problem still exists it is definitely something else which is accessing the joystick values, possibly through FSUIPC. Regards, Pete

Is the problem the same with non-scrolling test, or with a different delay specified? The fact that the same thing happens when you have AdvDisplay intercepting the request instead is strange -- the action is completely different then. Can you turn on FSUIPC IPC write logging and show me the extract, showing what you are doing? Maybe there's some obscure problem resulting in some corruption somewhere. Regards, Pete

Well, currently FSUIPC doesn't know it. It doesn't need to know it. Also I'm reluctant to lose another 256 bytes to such an obscure need. Are you sure you can't do it another way? A diddy utility program running on the FS PC could get it and send it. It isn't ever going to change unless another user logs in in any case, so having another 256 bytes of offset wrapped up in unchanging data seems rather wasteful. The best thing to do is actually share it with a fixed known name, then your remote program can have that known name built in. Regards, Pete

Yes, it seems so. Pete

Ah, you won't be able to do that across a Network -- SHFolder, assuming it runs on the Networked PC will give you the personal folder path on that PC. I don't know any way of doing it remotely. It would be easier simply to key it in as a user-entered parameter, or share it with a known name. Regards, Pete

I've been doing lots of tests, and can get no problems with the maximum number of checkpoints set higher than 29. As I said, the 29 was an RC restriction, not one of FStarRC. What can give a problem is if the resulting plan exceeds the memory allocated for it. The program gennerates all the files in memory before writing any of them, because things like final destination details aren't obtained until the end, yet are needed by RC at the beginning of the file. So, in version 1.85, attached for your own testing, I have increased the space allocation. I've tested it here with the maximum set to 200 and with various plans with up to 112 waypoints. I am finding it quite difficult to make plans with FliteMap with more than that -- if you still have difficulties, you'll need to send me the plans. Bear in mind that I am using FliteStar/Map version 8.5 -- I don't know if the .fcf file format from other versions is compatible. Please let me know how you get on. I won't make a general release of version 1.85 till I hear from you that it is okay. Regards, Pete FStarRC185.zip

Oh, I thought it was trackhang on, I'll re-check. [later] The value labelled "TRK" in degrees magnetic in the GPS is defitiely track, not heading. I don't know who said it wasn't, but I think they are wrong. Okay. The terms "body axes" and "world axes" are confusing. Since the aircraft always has zero velocity relative to its own "body" I always assumed that these terms referred not to what the speeds are relative to, but how the axes are oriented -- so world axes would have x, y and z oriented relative to the Earth, but the speed wasn't necessarily relative to a fixed point. Evidently, as you've found, it is. Nice to know. Thanks! Regards, Pete

The only way I know is to use the SHGetFolderPath API with "CSIDL_PERSONAL". This is in the SHFolder.DLL, which is included with FS and is probably standard in WinXP in any case. That gets you to the correct personal documents folder. Then you have to append the "Flight Simulator Files" bit, in the language FS is actually using. If you are happy only to work with an English/American version then that's not a problem, but AutoSave has to do it properly -- it reads the FS folder name as a Resource from the FS Language.DLL -- after loading the Library you have to LoadString #36864 from it. Regards, Pete

Sorry, I have no idea. That flag isn't even processed by FSUIPC, it's one of the original 'GLOBAL' indications which FS has supported directly since pre-historic times, almost. :) Why there should be any delay I have no idea, but the possibility that occurs to me is that there's some bouncing occurring and occasionally the timing of your reading it coincides with the zero. You could try polling more frequently, at the risk of affecting performance. Another possibility is that the aircraft model is one of those with an undercarriage not quite touching the ground, or only just. Not knowing how FS decides its "on ground" flag, this may make the detection somehat erratic. I don't know why accurate detection is so necessary for you, but perhaps you could detect it, or at least confirm it, by comparing aircraft altitude with ground altitude, with some allowance for the cockpit height (or at least the position the aircraft altitude is measured from). Maybe that would have to be a parameter? Regards, Pete

Normally a crash in the Weather DLL during loading means either a corrupt WX file set with your default Flight, or possibly one of the files in the WEATHER sub-folder is corrupted. For the former either delete the WX file associated with your default FLT file, or edit the FS9.CFG to remove the default flight, stopping it loading. For the latter I don't know any way apart from re-installing them. You say there's a Theme selected in your default flight? If so, then perhaps that file is corrupted. They are in their own subfolder (Weather\Themes), so maybe those could be re-installed. When you do manage to load FS successfully, can you select that theme okay in the Weather menu? Since I do a lot of testing I always have a parallel unmolested installation of FS in my PC, so to check things like this it is always possible just to copy such files from one installation to the other. Failing this it is often a complete re-installation -- and that is usually what Microsoft's support will advise. Sorry, I cannot narrow it down any further. Regards, Pete