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é

Hi I'm affraid you will not find any documentation about that Typically, full ILS localizer deflection is 5° (2.5° each side). So, as far as FS modelizes things as it should, you will have a localizer scale of 128 = 2.5° However I suspect this scaling will depend on the localizer beam width which is a known ILS FS parameter (distinct for each ILS). The glide slope signals also consists of 2 overlapping beams (90 and 150 Hz). Since the thickness of the overlap is 0.7° above and below the defined ILS glideslope, I suppose the GS needle shows full deflection at top/bottom of the overlap area. This would result in a glide slope scale of 128 = 0.7°. Some tests (using aircaft & GS coordinates/elevations and trigonometry) could confirm that or not ;-) Hervé

Just to add to this discussion, this problem was discussed on the IVAO forum here http://forum.ivao.aero/index.php/topic,67666.0.html All reserved IvAp FSUIPC offsets work correctly with FS9, FSUIPC 3.75 and IvAp 1.3.4.1842 However, there were known bugs in FSX IvAp version 1.9.4 It seems it has been corrected with the release of version 1.9.5 See here: http://www.ivao.aero/softdev/IvAp/changelog.asp So be sure you use the latest IvAp version for your tests (by now 1.9.6.2039) BTW, this is only an IvAp problem Hervé

Hi Ray. Pressure Altitude (PA) is not related to any Kohlman window setting (except when set to 1013 hPa/29.92 inHg in which case altimeter will read PA). PA is by definition the altitude above MSL of an International Standard model at which air pressure is the same as the current measured air pressure. There is no offset in FSUIPC3 giving directly pressure altitude. What you can do is recalculate it from ambient air pressure (0x28C8) and the ISA model formulas for pressure vs altitude. Alternatively you can approximate it from Altitude above mean sea level and current QNH (both available via FSUIPC) For FSUIPC4, pressure altitude is directly available at offset 0x34B0 Hervé

It seems none of the [http] links work. Is it a problem on my side? Pete, could you have a look at that Hervé

Hi Ray, Try writing 1 at offset &H7DC (for enabling AP IAS mode) or at offset &H7E4 (for AP mach value). I think it will switch from IAS to Mach or the opposite. If needed, you can first read the values to know which mode is enabled (it should be 1-0 or 0-1 but never 1-1 ;-)) Hervé

Roland, I monitored &H3BFC offset that appears to work correctly when payload is changed within FS. I didn't test it after directly changing payload weights at assigned FSUIPC offsets &H1400 and following. May be there is a dysfunction here and Pete will surely check that. Writing at &H3BFC has little sense (even if it's marked OK in the SDK) since this offset adds total payload weight to basic empty weight (a fixed aircraft.cfg value) Regards Hervé PS: Zero fuel weight at &H3BFC (marked ?) doesn't appear to work correctly in FSX. It only reports basic empty weight and doesn't add payload Edit:PS

Hi Milan, First check that payloads stations are defined in your aircraft.cfg file in the [Weight_and_balance] section, otherwise FS and FSUIPC will not be able to write/retrieve any. Definitions of stations are for example: station_load.0 = 170.0, 46.3,-1.5,0.0 station_load.1 = 120.0, 46.3, 1.5,0.0 Then, check that you can read 170 lbs at offset &H1400 and 120 at offset &H1430. These are doubles and you will need to provide a corresponding 8 bytes value for read/write (I don't know which language you use for that) Check for changes after you write and process new values at the same offsets Hope, it will help Hervé

Thanks for your immediate answer Pete No, it will be ok checking 3364 and 3365 since it works for both. Indeed I had once a division by zero error while repositioning the aircraft in another part of the world (at this time the ambient air pressure at &H3498 was 0 and it was a FSUIPC3 problem). Of course, the less code we have to adapt to the FS version, the best it is but it's not a problem to add a If Else ;-). My applications are planed to work on both FS9 and FSX. Apparently, the aerodynamic maths didn't change a lot Yes Regards Hervé

Hi Pete, Is there any possibility with FSUIPC4 to check for the validity of variable reads? A "busy" internal flag was provided in FSUIPC3 (&H11D4) that was convenient so as to avoid post-read processing errors. Also, "air file path" zone at &H3C00 appears to include the full file path (including FS path) with FSUIPC4 while it only included the partial path with FSUIPC3. Is it a wanted behaviour? Finally, it appears after testing that many FSUIPC4 offsets you marked as ?-Intl or ?-SimC are working properly. I will send you the list as soon as it will be completed. Thanks for the great job! Hervé

Yes..I agree the name is inappropriate. But I didn't discovered that. You mentioned it as a possibility somewhere..I tried and it works as a ON/OFF command. Since I only have one joystick I cannot answer the second part ; may be the second at H3114 has something to do with that ; in my case writing 0 or 1 here didn't change the result. I confirm all axes AND buttons are either enabled or disabled Nothing with FSInterrogate. If you have a range of values to look at, I know how to do that :) Regards, Hervé