Pete Dowson

Yes, the measured surface altitude was always based on the elevation of the nearest airport. At one time you couldn't even have two airports close together (within several miles) at different elevations. Hills and mountains were "bolted on" polygon-based shapes, on top of the otherwise flat ground. I think it must have been FS5 (becoming FS5.1 then FSW95, the first Windows version). Hmmm, maybe, though it does sound a little unlikely. When are you going to check FSX? Detailed observations with FSX would be useful as I can feed them back to MS -- there's little point, now, with FS2004. Have a nice holiday! Regards Pete

Hmmmperhaps FS is more sophisticated that we're giving it credit for and computing some sort of small "fiddle factor" to represent the variations you would probably get over land -- for variations in ground altitude, clutter, air densitiy, whatever? (I don't know exactly what affects EM waves at these frequencies but I doubt that they are not affected by anything like that). Either use the little "Quote" button provided for the purpose, or enter the closing quote part with a / instead of the \ you are using. ;-) Regards Pete

Please find the key on your computer keyboard labelled "Caps Lock" and turn it OFF! There are three different methods of setting weather through FSUIPC: 1. The old FS98 method, only applicable to global weather and restricted to facilities which worked in FS98. This is via offsets in the 0F1C to 0F8C range. It is the least likely to work well in FS2004 as you must prevent localised weather changing your settings or overruling them. Global settings only apply where there is no localised weather, i.e. immediately after you clear all weather properly. 2. The Advanced Weather Interface (AWI) which was invented to handle the more advanced weather systems in FS2000. It still only works with global weather, but allows all of the other features added in FS2000 to be utilised. This uses special commands and data structures, and is documented in the separate AWI header and text in the SDK -- a separate ZIP. The program "WeatherSet" uses these facilities and is a demonstration of what they can do. It works well in FS2000 and not too bad in FS2002, but in FS2004, because the weather is constantly dynamic, you still get discrepancies unless you regularly clear all the weather and re-establish it. Unfortunately this give flickering or stutters. 3. The "New Weather Interface" (NWI) using offsets again, in the range C000 to CFFF. Documentation is again separate in the SDK, with structures and values defined in a header. This works with FS2002 and later, and is the only method which allows both global and local (ICAO-identified) weather to be set and read. Programs like FSMeteo and ActiveSky currently use this. The program "WeatherSet2" uses it and is a demonstration of its capabilities. When and if you ever get to FSX there are yet other methods, but the FS2002/2004 AWI works fine with that too (or at least it will once MS has fixed all the FSX weather bugs). There's also a "straight to SimConnect" facility supported to set weather using METAR encoded strings. Regards Pete

For FS2002 or FS2004 you need the MS Multiplayer toolkit. That's as much as I know -- I've never had anything to do with multiplayer myself. For FSX it isn't possible yet as far as I know -- MS have not released any information allowing MP to be used by third parties. On-line flying programs will be using SimConnect to inject and control "AI" traffic planes instead. Regards Pete

Sounds like you have a VERY very old version of IVAP, then, as FSUIPC 2.975 only applies to FS2002 and earlier and hasn't been available or supported now for nearly 4 years! 3.70 is not supported either. The current version is 3.73 (with a later version still available in the "other downloads" announcement above). Also, what do you mean by "tried to install"? Installing is only a matter of copying the DLL into the modules folder. If you copy version 3.7x into the modules folder and don't try installing another bad and very old package it will still be 3.7x -- it cannot change by itself! Regards Pete

FSUIPC itself changes nothing direcly, it is only an interface. I'm afraid I know nothing about your "Simulink" nor "Aerosim". Are they lumps of hardware, or just add-on software, or a bit of both? I've not heard of "FSInterface" nor an "S-Function", nor "sfunflightsim.dll" either, I'm afraid. I think you need to contact the supplier of whatever it is you are using which doesn't work. Sorry. If you downloaded FSUIPC from some unofficial place it may well be out of date in any case. The current version of FSUIPC3 is 3.73, though there's a later increment available in the "other downloads" Announcement above. Regards Pete

Sorry. I know the folks at PMDG at beavering away with FSX, but what they are planning I am afraid I am not privy to! (Even if I was, which I am certainly not, I expect they'd be pretty annoyed with me if I told anyone before they were ready to say anything themselves!) Regards Pete

Martin, One thought struck me. How are you computing the "horizontal distance"? Are you making any correction for the curvature of the Earth? Obviously for small distances away from the DME station this should be negligible, but probably NDB ranges are enough for some correction to be needed at their further reaches. The altitude difference would also be affected of course -- is isn't very simple geometry. The DME distance read-out should of course be the direct slant distance. Have you tried just basing signal strength computation on that? Regards Pete

It will be a matter of rewriting stuff which is intricately involved with FS to suit FSX instead of FS2004. This is nothing whatsoever to do with FSUIPC. The PMDG aircraft only use FSUIPC for some things. They are complex designs which interact with FS directly, not external programs interfacing only via FSUIPC! I have no program which does anything like that. I think you must be mixing my program (FSUIPC) with others? They are FS gauges, written using the FS8/9 panels SDK. They are not suitable for FSX! Of course they can be re-coded. It is "merely" a programming job. I expect PMDG are already starting unless they have other priorities. But why ask me? You need to ask them! I am totally puzzled as to why you think this is a question for me? Regards Pete

Good. Thanks! That's something to do with DirectX Force Feedback. Not my field at all I'm afraid! Regards Pete

My school physics is rusty, but, yes, I think it's the inverse square law. Certainly not linear. Okay. If you do discover anything interesting please let us know! Regards Pete

Complex C-programmed gauge files like the PMDG ones can certainly cause an access violation (not a 'security' vlolation). That's easily done when a program is written for a completely different version of FS. Regards Pete

Hmm. It seems rather odd that the altitude of the station isn't relevant. Obviously a station on top of a mountain, nearer the aircraft altitude, would at minimum reduce the actual slant distance to the aircraft. In that thread you said What is wrong with the DME1 elevation provided at 088A? FSUIPC obtains this when it gets the DME1 Lat/Lon data -- it all comes together.Are you saying that it isn't working? If so can you tell me, please whether you are using the latest versin (4.08 for FSX, 3.73 for FS9 and before) and what looks wrong -- I notice later in the thread you were seeing values like 50000, which of course isn't possible in 16-bits -- that's a misinterpretation of a negative value. No, but it would see to be a good idea to get the DME1 elevation sorted out first, then see if you still get wrong answers, doesn't it? Regards Pete

A lot of the PMDG aircraft code is tied specifically to FS2004 and before, simply because of the way it is implemented. I believe it is the PMDG options DLL which provides the menu and links up the various parts of the cockpit, and there is absolutely no way that a module written for FS2004 or before will work with FSX. Sorry, but I'm afraid you'll have to wait till PMDG gets FSX versions out. I am using the PMDG 737-700 and 800 models and AIR files in FSX, but I don't actually use the panels in any case. Regards Pete

Looks like you'll need to stop AutoThumbNail too then. I can only think SimConnect is crashing out on one of these two actions it performs before it sees a "Sim Start" event which says it's okay to get data: Last time I said, of this "it did this well after FSUIPC4 was fully loaded in any case.", but this time (presumably because you stopped two of the programs, it is doing it before anything of FSUIPC appears in the Log, so I assume that's where the Security check is occurring. Regards Pete

In FSUIPC 3.734 (now available in the "Other downloads" announcement) I have, for FS2004 only, renamed that parameter to "CorrectVSsign". This will be done automatically, converting any "PatchSimApAlt" parameters. The parameter stays as it was in FS2002, because in that case it does actually work by patching the FS A/P code, and the Options screen matches that in any case. I've also provided an FSX version (4.089) with the same facilities, excepting that this particular option doesn't apply in FSX -- the other three do though. Regards Pete

Yeah, it fooled me too for a little while ;-) . It's historical -- on FS2002 (?) it did indeed patch the A/P inside FS, something which turned out unnecessary on FS2004, but of course, in the name of compatibility, the parameter stayed for existing INI files, but only doing a bit of the original job. Maybe I'll just change the name of the parameter, and convert any old names. Regards Pete

Okay, I had some time to look at this yesterday (Sunday), so I've implemented pretty much exactly what I suggested in FSUIPC 3.733. Unfortunately I haven't had time to test it -- from inspecting the code it looks okay, but I'd be grateful if you would try it and confirm. Download 3.733 from http://fsuipc.simflight.com/beta/FSUIPC3733.zip This includes a little Text file describing what I've done. I look forward to your results, after which, hopefully, I'll be able to put this into the "Other Downloads" announcement above, and look to do similar changes for FSUIPC4. Thanks, Pete

Ah, yes, I see! Regards Pete

The FSUIPC SDK lets you write a program to read things like pitch, roll and yaw velocities and accelerations. How you translate those into suitable movements for pistons and so on is quite complex. You need to work out the algorithms your specific equipment needs, and then write the driver, interfacing to FSUIPC to obtain the information you need. The SDK is available from http://www.schiratti.com/dowson Regards Pete

Okay. I'll look to implement it as I described when I get the chance, maybe in the next increment. Yes, they look possible in the same way. Keep an eye on the Downloads Announcements above. I'll see if I can get the changes in over the next week or so. Regards Pete

HmmmI wouldn't want to change the way it works at present, for fear of messing up existing installations (I always have to think about continuing compatibility). But I could add such an aircraft-specific option, a sort of explicit override for this global setting. There's not really a good palce to put it in the on-line settable options, and creating new dialogues is more work than I'd want to undertake for such an otherwise simple change. So, how about if I add a parameter which you can edit into the appropriate aircraft-specific section of the INI file? If the parameter is there it overrides the "Miscellaneous" global setting. I think it would have to go into the aircraft-specific Joystick Calibrations section. Please be more explicit. Let's have it all sorted in one update. Regards Pete

Enter hex values as x then the value. Do not enter x at the end,. Offsets need the x at the beginning (unless you are using the decimal equivalents, which is unlikely). The parameters can be hex (starting x) or decimal, as suits the value you need to set. Well, that says the transponder mode control is offset x7B91 (don't use the C/C++ format they give, just precede hex numbers by x, as documented for FSUIPC). So Offset Byte Set, with offset = x7B91, parameter = 1 sets standby, parameter 0 sets normal. The ident is similar but offset x7B93 and parameter 1. Regards Pete

Neither I should think, as they don't really have any relationship with each other at allexcept via SimConnect, that part of FSX supporting both. It's the first time anyone has reported this particular problem, so it evidently doesn't affect evey such user, but it does sounds like a typical example of some of the SimConnect problems experienced before. I don't know why these only affect some installations, but SimConnect does seem to sometmies have problems when there are two or more clients. Are you sure FSUIPC isn't stopping working too? Please check the FSUIPC4 log, see what that says, and possibly obtain a SimConnect log -- directions for doing that are in the FSX Help announcement at the top of this Forum. I can look at those and see if I can see what is going wrong. ZIP them and send to petedowson@btconnect.com. Please make sure you are using the latest version of FSUIPC4 first, though. If you are not already using version 4.08, download it and install it, and then get 4.088 from the FSX downloads announcement above. Regards Pete

Ahainteresting! Thank you for letting us know! Regards Pete