Pete Dowson

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

Unless you have applied the limits on visibility in the FSUIPC options, FSUIPC cannot interfere with FS2004's real weather. It sounds like there was a problem with the Jeppesen/Microsoft weather website. FSUIPC is not a fix for everything which may go wrong with FS. Regards, Pete

This is news to me. Icing isn't a problem with pitot heat and, possibly also, the anti-icing enabled. At least I've not experienced any problems, and yours is the first report I've seen. FSUIPC could only reduce or eliminate icing when it is being set be external programs. It cannot do it for weather set by FS's own downloads, nor for weather set from the menus. Apart from that it would be easy enough, but wouldn't the correct place be in the weather programs? The whole point of providing the extensive weather interface for those programs was to allow them full control, and now you want some taken away. I don't know what program you use, but have you asked the author about this, as a possibility? Regards, Pete

Where and how? Sorry, the terms "raw" and "directx" don't really go together as far as I've found. Depends whether you count from 0 or 1. :) That's an error returned by EPICIO.DLL (part of the USB Epic package), but as it corrected itself immediately afterwards I wouldn't worry about it. Maybe it's an initialisation state. It logs the axes and the values. With Log=3 if changes were seen on your programmed axes at all they'd be logged. If there's nothing like that in the log then the changes aren't being seen. I noticed you have "AxisReads=Both", so it seems the changes aren't getting through either the Windows route or the EPICIO.DLL routine. I really think you'll need to check things with the EPIC folks, unless someone else here can jump in. It sounds like something related to the way you've defined things in the EPL, but I'm afraid I get puzzled by all that stuff too. I've not programmed EPIC seriously since the new EPL was invented. Regards, Pete

I don't know what you mean when you say you've "debugged the joystick values". Values "Px" are not virtual axes, in the sense I understand, but POVs ("Points Of View" controls). You don't say whether you are using FS98, FS2000, FS2002 or FS2004. You don't say whether you are using ISA EPIC or USB EPIC. I also need the EPICINFO version number, and the FSUIPC version number. But first, please help yourself by using the logging facilities in EPICINFO as documented. The log should show you what is going on. Regards, Pete

Thanks! Your solution should do the trick, I think, although your objective isn't exactly the same thing. The centreline needs to be though the centre of the aircraft, but I am sitting to the left (being Captain) and I want to see straight ahead, to the point on the horizon which is otherwise on the join between two monitors. This does, of course, represent a minute angle towards that centerline. But with a real obstruction so close as the windshield it wouldn't matter. The trouble is you can't look around the join of the two monitors. Reading that back it looks a bit confused. Sorry. It does make a sort of sense I hope :) Pete

FSUIPC already gets all the useful data it knows about out of FS. What is it that FS knows and which you cannot get from FSUIPC as it is? If it is stuff buried in some cockpit gauges surely it is up to the programmer of those gauges to provide your access? He can use FSUIPC if he wishes, maybe optionally. No, that is not the way to do it. Espen can ask me for an allocation in FSUIPC's memory, and he can then interface to FSUIPC and use those locations. You can then read and write them through the normal IPC interface to FSUIPC. This is thay is should be done and has been done for several implementations already. Everything I have received for the SDK is in the current version except for a recent correction to the code the C#.Net and VB.Net, which will be published soon enough. I have no other reports of problems with code in the SDK. Regards, Pete

How do you "shift" the view over without changing the angle of view? You still need to be looking in the same direction as the nose. Regards, Pete

Yes, even worse is 2D stretched over 3 screens on a Parhelia. If you wanted to use a 2D panel you'd need to reconfigure the sizes of the bitmaps and the gauge proportions and positions. The only thing I don't like about 2 screen views is that straight ahead is right where the join of screens is. I suppose there's a way to move scenery view to left or right without changing the angle of view, but I didn't find it. Regards, Pete

Those two statements seem to directly conflict with each other. Can you explain what is happening, please, rather than attempting a diagnosis initially, as I really cannot understand how it can be sending the weather and not sending the weather at the same time. Observations with both WeatherSet and the FS Weather Dialogues would be useful. Neither. Before FS2004 I and many others have been using FSMeteo on FS2002, and FS2000 before it (the Weather implementation didn't change between those two) for nearly 4 years without such problems. Let me know what the problem actually is first. Things like Veriosn numbers are also useful -- in fact essential, please. Regards, Pete

Yes. Since WideClient "pretends" to be FS, you can't run it whith a real FS present -- client programs would not be able to tell which to attach to in any case. Sorry, no, unless you have another EPIC on the second PC and get the two talking. I know that's something R&R planned for the USB version but I don't know how far it's got yet. With the ISA version, under Win95/98, I provided EpicLink for this. Otherwise it sounds like a good facility for WidevieW to provide. Have you suggested it to Luciano? Regards, Pete

It's difficult enough for me to keep up with Enrico's changed in FSUIPC, let alone the code in EPICINFO which is in fact far older (dating back years). Enrico says he's going to revise quite a lot of this stuff soon, hopefuly keeping backward compatibility, and after that maybe I'll look at trying to catch up again, though it wouldn't be my top priority -- FSUIPC would. Meanwhile the button programming in FSUIPC is actually easier to use, as (a) it is on-line in FS, and (b) it recognises the buttons without you having to work out any numbers and so on. When I added all that to FSUIPC I didn't actually remove the older facilities in EPICINFO since that would incapacitate existing set-ups, but I had hoped not to have to go back and continue modifying the latter. Regards, Pete