herve_sors

Well, I didn't scroll right far enough..my fault 😉 Thanks for the support Hervé

Dear John, Would it be possible to briefly clarify the meaning of the different background colours used in the offsetStatus-v0.1x file. By now, I can see the following in the previous FSUIPC read/write status as well as in the current Read/Write status: yellow, light green, dark green, pink, red, light blue but I couldn't find a legend even if there's occasionally some notes . I think it could facilitate the initial work for adapting applications so as to maintain compatibility with MSFS 2020. Thanks for the outstanding work done with FSUIPC Hervé

Hi Pete, It is always possible to include 2 ILSs associated to a single runway end since, as you know, ILSs are not coded in the same section of the BGL file than airport data. Both are functional in the simulator. However, the problem is that, the runway record includes at offset 0x0C (for the primary end) and 0x10 (for the secondary one) a single ILS identifier. I don't know the possible effects of choosing one or the other in such a case but it may affect the choice of some approaches by the simulator ATC and by some 3rd party FMCs. Anyway, just reading the runway record in such cases cannot indeed guarantee there's no other ILS associated to it. For that the only way would be to read the full 0x13 section (VOR/ILSs) and determine for each ILS both the associated airport (bit 11-31 at 0x24 of main ILS record) AND runway it is linked to (0x06 and 0x07 of localizer subrecord). May be it will complicate things quite a lot considering the very few BGLs that include such dual ILSs for a single runway end. Hervé

As Pete explained airport magvar (as coded at 0x24 of airport record) is not used by the sim. So there's really no need correcting it. Some designers provide a correct valuet. Other don't. So, I don't think it is a good idea for any addon to use it. Now, there is no way to obtain from BGL scenery files alone magnetic orientation of runways since the only coded value is the runway TRUE heading and airport magvar is not reliable. In the simulator runway magnetic heading is calculated from true heading and current magnetic variation at runway position from the MAGDEC.BGL file. So it is impossible to obtain it from the scenery BGL alone if you wish to obtain a trustable value. Hervé

Translate it to "bigger (or other) fish to fry" but sure Pete will do that for you.. 😎

Interesting Pete..is "x" defined by FSUIPC on some predefined criteria you set in the code (may be depending on retrieved data) or by SimConnect itself and what does decides mean on the SimConnect side?

AFAIK, this information is only part of the ILS name contained in the relevant airport BGL. CAT is usually included as a prefix (ex CATIII ILS/DME 26L) Hervé

Thanks Scotfleiger but documentation is not available before installing (the zip doesn't contain it as separate files) and even if most FSUIPC4 documents remain valid, the history document is not covered.

For those who will not install the latest FSUIPC5 version (because they do not own P3Dv4 or for whatever other reason), is there a link for looking at the history document file. I cannot find any FSUIPC5 documentation only in the documentation folder Hervé

There was a mistake in my previous post regarding Sim1.dll table offsets P3Dv4 Sim1.dll (4.0.23.21468) rolling friction coefficient tables (with scalars) are at offset 0x148500. Braking coefficient table is at offset 0x1497C0. Structure is identical to that of previous P3D versions (and FSX). All tested values are also the same. Full data are available here http://www.aero.sors.fr/documentation/Friction_Coefficients_Sim1_P3Dv4.xlsx Hervé

P3Dv4 Sim1.dll (4.0.23.21468) rolling friction coefficient tables (with scalars) are at offset 0x148580. Braking coefficient tables are at offset 0x149840. As far as I could see, structure is similar to that of previous P3D versions (and FSX) Hervé

Thanks Pete. Some of my analysis/tracking programs were affected and I already adapted them to correctly identify P3Dv4 from FSUIPC5. So, on my side, better not to change anything unless you have other requests to do so. Documentation would be fine enough.

Thanks Thomas and noted. Seems offset &H3124 (labelled specific version of FSX or P3D being used) reports by now a value of 51 (and not 40 to 4x for P3Dv4 as expected) but not a problem as far as we know it is like that ;-) Hervé

Hi Pete, Some early users of FSUIPC5 on P3Dv4 indicated FSUIPC5 reports FS Version=12 for P3Dv4 at this offset and not 10 (P3D). Could you confirm that? Thanks by advance Hervé

Perfect. Thanks a lot Pete.

Hi Pete & contributors, Any experience from retrieving sim data from FSUIPC5 using 32-bit applications? Do they have to be converted to 64-bit? Any change to the published FSUIPC SDK routines for gaining access to sim data via the use of available offsets? Hervé

>>So, it isn't reproducible here, sadly<< Neither here on my system..and it can hardly by a problem reading the BGL entry since runway width is a single entry (offset 0x24 of the fixed part) that applies to both opposite runway (that's make sense) and cannot be x for one and y for the other

That's an interesting information Pete..Could we have some more information on the way you set this delay? I'm sure designers who include landing detection (with or without bounce detection) in their FSUIPC driven applications will be interested. Thanks for sharing Hervé

This is just a reference coordinate system for speed and acceleration vectors BODY axis system refers (as its name indicates) to a body-fixed (aircraft) rotating axis system WORLD axis system refers to a non-rotating axis system See a figure below The only difference is that FS labels axes differently X -> Z Y-> X Z-> Y and that sign of speed/acceleration along the Y axe (vertical) is inverted More details in Zyskowski's paper. A link to it here (4th link in Aircraft dynamics pages, documents and utilities frame) http://www.aero.sors.fr/fsairfile.html There have been a lot of discussions on the way FS calculates g-force. I presume FSUIPC4 uses the G FORCE Simconnect variable Hope it will help

Personnaly for Jet and turboprop engines I use 64-bit double floating values at offsets 0x2060, 2160, etc depending on number of engines and 0x0918 and following (offsets &H98 for consecutive engines) for propeller aircrafts. Of course individual engine fuel flows should be added. It works well and completely fits gauge displays Hervé

I don't think so. My applications still report FS version=9 (that for this purpose must be considered as a FSX version) from users under FSX-SE (with FSUIPC version 4938.0001). If you just checked for Ver=8, that's the reason Otherwise, there might be many other causes of incompatibility (especially if you make access to the cfg file depending on side by side or replacement installation). Some more information here regarding that http://www.fsdeveloper.com/forum/threads/fsx-on-steam-compatibility.432460/#post-694920 Pete recently provided an offset for P3D version number, may be he could do the same for the different versions of FSX although you can also do it by yourself from build number of the exe file (that's easy considering FSUIPC will provide you the sim category (FS9, FSX or P3D) and the sim path so that you just have to retrieve the corresponding exe version data Best regards

In VB6, the easiest way to convert an ASCIIZ byte array (defined as barray() before reading offset) to a string, taking into account 0 terminator is string = StrConv (barray, vbUnicode) See your VB documentation Hervé

Go to the [brakes] section of the corresponding aircraft.cfg file and decrease the toe_brakes_scale value; 1 is the default. For example, try toe_brakes_scale=0.80 and make some tests; know that many 3rd party commercial aircrafts use values between 0.50 and 0.70 There's no air file parameter for this action, only the boolean #332 value (Toe brakes available) but it is obsolete in FSX Hope it will help Hervé

Hi James Altitude as provided at 0x0570 is (by definition) above mean sea level and will not change with baro setting as you assumed. Take care to properly retrieve and manipulate the data as far as the value is provided in units (high 32-bit integer at 0x0574) and fractional part (low 32-bit integer at 0x0570). Height above ground level can be obtained either by subracting ground altitude (at 0x0020) or using FSUIPC calculated radio altitude (0x31E4) Regards Hervé

MAC calculation and position of current CoG (in %MAC from leading edge, the one that is reported by FSUIPC from FS) is complicated by the fact FS defines 2 MAC's, one for aerodynamical calculations, the other for gauge display. They may fit or no. However both can be precisely calculated from aircraft geometrical data (as defined in the aircraft.cfg) and weight distribution. When such "external" calculations are performed, resulting values perfectly fit what FS reports as CG %MAC. May be you could have a look to the excellent paper written by Yves Guillaume that undermine the foundations of how FS is doing that (and that have been implemented in my latest AFSD version) http://library.avsim.net/download.php?DLID=170811 If you need some more details regarding practical calculations let me know by mail Hope it will help Hervé