hsors

Seems ok to me at first glance. Did you check the TAT you've read matched the formula? (TAT=SAT*(1+0.2*Mach*Mach)) [sAT and TAT both in °K in this formula]; you'll have to add mach number to the records (&H35A0). This would be a definitive confirmation. Personally I use &H34A8 for SAT but it should be the same as E8C after rescaling I think this is also valid in slew mode but I'm not absolutely sure about that

From the tests I performed with P3D v2 with FSUIPC v4.923, there is no problem with TAT on my side As an example a record made at 13250 ft AMSL at a mach number of 0.7299 - FSUIPC reported TAT (offset &H11D0): 17.4°C (raw unscaled value 4456) - Identical to calculated value from SAT [TAT (°K)=SAT(°K) * (1+0.2*mach*mach)] [here SAT=-10.6°C that is 262.55°K) Different other records gave similar concordant values I made raw tests without any special met conditions (different P3Dv2 weather themes) and without any addon (other than FSUIPC) I could suggest reported values are compared to calculated ones so as to sort out any possible discrepancies (that is you'll have to report recorded SAT and mach number) I cannot answer for P3Dv1.4 I do not have

You should be able to do that simply by reading the BGL files containing the navaids you are interested in. As mgh pointed out there is no way to read that another way For information default FS (and standard ranges) are tabulated below. ILSs FS default ranges are always 27 NM http://www.flightsimaviation.com/aviation_theory_6_Navaid_Service_Volumes.html VOR ranges (NM) High Altitude: 195 NM (standard 130 NM) Low Altitude: 60 NM (standard: 40 NM) Terminal: 37.5 NM (standard 25 NM) NDB ranges (NM) High power NDB (HH): 112.5 NM (standard: 75 NM) NDB (H): 75 NM (standard 50 NM) Medium power (MH): 37.5 NM (standard: 25 NM) Low power (L): 22.5 NM (standard: 15 NM)

Agree Pete but it is a separate field included in each ILS definition (<Ils magvar). This value is indeed of importance for properly displaying ILS magnetic tracks on GPS and map views It is not the airport magnetic variation that is included in the parent <Airport definition. That's what I ment Yes. What I wanted to say is that keeping most airport sceneries up to date is probably unachievable especially considering the monthly changes worldwide in ILSs, runway identifiers, taxiway signs, instrument approaches, etc.. What I've done in my updates is correct all navaids (including their magnetic declination because they also have a specific one that is important for properly aligning on a specific radial) ) even if it raises some problems in the flight plan generator (most don't use anymore btw). I also corrected European ILSs and runway information for FS9 on a regular basis but didn't do that worldwide neither I did it for FSX (except France) since it is a never ending painstaking task that requires decompilation/recompilation of stock BGL files (with also possible side effects). Agree that selective airport exclusion/edition with appropriate software is a better way for most. Regards Hervé

That's often the case now, even for FSX. Note that the airport magnetic variation as coded in the BGLs is probably only used internally for calculating mag data for AI trafic..I'm not aware of any other effect changing it. Magnetic runway heading is calculated by FS from true heading and magnetic variation at airport position from the magdec.bgl file However, even taking this approach doesn't ensure it will fit charts as far as in real life, airport aeronautical data make use of a "local" magnetic variation value that may differ a bit from any "calculated" one at a given time (e.g. some airports in US and Asia still use 2005 values, most European airports use 2010, UK now use 2013, etc) Consequently there is no simple solution for correcting FS data as a whole

There is not a single FSUIPC offset that can change turbine engine thrust (and most are designed to be read only). Effective engine thrust is only determined, from throttle position, by engine characteristics, atmospheric data and several lookup aircraft tables that are defined in the aircraft.cfg and air files. These parameters can only be changed by editing the files appropriately Except for the throttle command, the only switch I know about that is able to decrease engine thrust (on some models) without change in the trottle position is the structural/engine deice command A short summary of the process is available here http://www.mudpond.org/jet_flow_chart.pdf

Did you have a look at the documentation Pete provides ? http://www.schiratti.com/files/dowson/Famp=010309 ITT (°Rankine) are mapped at offsets H2038 (1st engine), H2138 (2nd engine), etc [FLOAT64] and they work fine Hervé

Check offset x3D00 in the SDK: (256) Name of the current aircraft (from the title parameter in the AIRCRAFT.CFG file). Valid for FS2K only-Same for FSX. Should be what you are looking for

Yes, so the only solution I found to get round this problem was to write at regular interval an appropriate value (0xFF000800 in this case) at offset 32F0, so as to disable the "Aircraft" menu. See the meaning of the different Bytes in the Programmers documentation. Be sure to enable it again (by writing 0) when leaving your application so as the options and menus return to normal. Unfortunately this possibility doesn't exist in FSX. Regards

There is some mathematical techniques to determine whether a point is inside a polygon. have a look here http://alienryderflex.com/polygon/ http://local.wasp.uwa.edu.au/~pbourke//nsidepoly/ Alternatively, you can try to use surface type FSUIPC information at offset x31E8. Withe some precautions, it can help determining if the aircraft is on or off the runway. However some third party sceneries may lead to deceptive results. Regards Hervé

Hi Luke, As Pete said you can only retrieve via FSUIPC the absolute body angle of attack (at offset 0x2ED0). Since FS9 and FSX disregard wing incidence, it is also the wing AoA. Calculating AoA relative to maximum AoA will require you programmatically read Table 404 (or 1545 if it exists) of the air file and determine the AoA for max CL coefficient. This is not insurmountable since FSUIPC provides you the path of the air file. All you will have to do is to build an adequate extract routine (air file is a coded binary file). It seems this information was already extensively discussed in 2003 in the link you provided..how time flies! Hervé

Hello Falcon56 I don't think so. FStarRC is designed to export FliteStar flight plans to FS (FS9 format also readable in FSX) not the opposite. Hervé

Hi Björn, You're right. My mistake is that I own and use an English FS9 version. In the French FS9 version, this subfolder is named "Fichiers Flight Simulator". Now, I didn't find a single registry key with it neither I could find a reference to this folder in the FS9.cfg file (except as part of the [uSERINTERFACE] Situation= item). May be someone else or Pete, could tell us if there is a way to retrieve the proper localized name of this subfolder. As regard FSX, the same could be true. Again I only own an English version. Regards Hervé [Edit]: here is the answer and the way to proceed by Pete : http://www.fsdeveloper.com/forum/archiv-4243.html

Hi Björn, Indeed FSUIPC will not help you retrieving the "My documents" path. Rather than reading the registry, I will suggest you use the SHGetSpecialFolderLocation API with the adequate idl structure (&H5 for folder item). This is a more general approach that will also work on Vista. You will then have to append the "Flight Simulator Files" (FS9) or "Flight Simulator X Files" subfolder to complete the work Hervé

Hi Thomas, I think there is no fault about that. The [NAV CSI] variable (localizer deviation) mapped by Peter at offset 0x2AAC full range is -127 to + 127 while the [NAV GSI] at 0x2AB0 is -119 to +119 ; this is described in the MS SDK. Don't ask me why ± 119 ;-) There is also in FSX a [NAV GLIDE SLOPE ERROR] variable (degrees) but to my knowledge, Pete didn't map it (yet). You could also try the byte variables at offset 0xC48 (localizer) ans 0xC49 (GS) whose ranges are ± 127 Regards Hervé