Pete Dowson

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

I don't know of any reasons for that, but most all the black screen phenomena were with switching modes, like VC/2D, Minimise/Restore, Looking left/right, et cetera, and I think, by comparison with the same sorts of things hapening in many other DX8/DX9 games it was narrowed down to video driver progblems. Most eventuially got resolved by video updates, though it was a difficult time. I'm not sure what you mean by "displaying Text from my programme in FS2004". Is this the facility in FSUIPC? What happens if you divert it using AdvDisplay? Regards, Pete

Well, that's what the names of those imply when you save a flight and look in the .FLT file, e.g. [simVars.0] ... PVelWorld=0.00016016837602437931 BVelWorld=5.2741978078219892e-005 HVelWorld=-3.1679513659914766e-007 XVelWorld=8.5849995967027069e-005 YVelWorld=-3.6722501463765101e-006 ZVelWorld=0.015182631094688877 Apart from that I've no idea what they are, sorry. I don't know. It depends what "world axes" means relative to "body axes". The only person I know of that understood all that stuff is Ian Donohoe, and it was his information that originally led to me adding this stuff to the FSUIPC list of values. All I've done since then is track them down on each successive FS version. Those that understand them use them, but I am sorry I am not one of those elite few. :? All I can suggest is try it and see. Try it on FS2004 so you can compare it with the GPS value I pointed you too. If it works, then apply it to FS2002 as well. Regards, Pete

The only "pitot heat" indicator I know of is the switch itself, plus an electrical circuit flag ("PITOT_HEAT_CIRCUIT_ON"). You could check the latter. It is in the list of Gauge values which FSLook provides, and as far as I can see the circuit normally stays on whilst there's an active electrical system whether ot not the switch is operated. Possibly in extreme icing the circuit blows a fuse? There's also an FS control called TOGGLE PITOT BLOCKAGE which you could try using -- assign it in FSUIPC or in the FS Options-Controls-Assignments (where it's called "Pitot tube blockage on/off"). Regards, Pete

The ground track isn't normally provided. The programs that do show it calculate it from heading, TAS and ambient wind speed and direction. You can't derive it without taking the wind into account. However, if you are doing this only for FS2004 you can 'cheat' and get it from the GPS data in the 6000-61FF area. Check offset 6040. I think it is valid even with no plan loaded. Of course in a real airliner it's sort of the other way around. The track is provided by the INS and the wind indicator for the ND is derived from the differences that provides from heading and TAS. Regards, Pete

And with anti-icing enabled or disabled? FSUIPC gets blamed for all the ills in the world. I get used to it, but it is depressing nonetheless. :( There's no icing in FSUIPC unless you elect to enable the random cloud icing. Again, this applies to third party weather inputs only, not to FS "real weather" downloads. I can certainly add a limit option, but you are under a misunderstanding, as the random icing cannot be applied to FS's downloaded localised weather. It can be applied to the global weather but that is only used by FS where there are no nearby WX stations, and even then an additional option in the Technical page has to be enabled in FSUIPC (with it on you cannot retain Themes). Well, it hasn't been brought up in the Microsoft Beta newsgrups either. Generally identified FS errors are mentioned there, else it is unlikely they'll be fixed in the next version either. And why don't the problems occur with FS downloaded weather? Don't the Jeppesen/Microsoft weather reports ever have icing in clouds? In any aircraft, or only some? If the aircraft is equipped with anti-icing, does this make any difference? Possibly it occurs on aircraft where the pitot tube is on the wing or in other places more liable to severe icing? Is the aircraft realism turned up to 100%? What if that is lowered? Are folks really actually complaining about some additional realism introduced into FS2004 which wasn't there before? Well, I've added the item to my list, and it is reasonably easy to do (for third party inputs, and the random icing option) so it'll probably get done in the next version. I'd like to know what icing level you need to set to force this failure -- is it only the top level, or anything other than 'slight' (1)? I'd also still like to know whether it is really an FS bug or not. Maybe MS just changed the icing scale in FS2004 compared with previous releases, and the values used in the Weather programs need scaling down for the same effects as before. Or maybe the new effects are more realistic. There's a difference. Regards, Pete

Sounds like it might be checking the version number of either FSUIPC or FS, or possibly both. Maybe you need an update for FS2004 -- have you looked to see if there is one? Not all programs will work without changes. You could try adding "MakeItVersionFS2002=Yes" to the FSUIPC.INI [General] section, but if you do that many other add-ons may go wrong because FSUIPC will be lying about what version of FS it is. And I don't support the use of this "fiddle". Regards, Pete