Jump to content
The simFlight Network Forums

herve_sors

Members
  • Content Count

    30
  • Joined

  • Last visited

Community Reputation

1 Neutral

About herve_sors

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Location
    Paris

Recent Profile Visitors

1,605 profile views
  1. 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é
  2. 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é
  3. Translate it to "bigger (or other) fish to fry" but sure Pete will do that for you.. 😎
  4. 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?
  5. 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é
  6. 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.
  7. 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é
  8. 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é
  9. 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é
  10. 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.
  11. 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é
  12. 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é
  13. 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é
  14. >>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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.