Read new MSFS SID and STAR records

[albar965]

Related to #555

SID and STAR are mostly recognized but not all due to the new records below which were introduced with 1.16.2.0:
The records SID_STAR_MSFS_DEPARTURE (0x004a) and SID_STAR_MSFS_ARRIVAL (0x00f0) are still unknown and cannot be read.

Disabled skeleton code is here:
https://github.com/albar965/atools/blob/release/3.6/src/fs/bgl/ap/sidstar.cpp#L159-L185

[icykoneko]

Uggggh, and after I went to all that trouble lol

[albar965]

I feel with you. It took me a lot of time to find the changes in the current new records. 🙁
Therefore, I'd be glad for any help. 👍

Alex

[icykoneko]

Sure thing. Looks like you've already made a few changes to the code since my original PR, but I did happen to have copies of a couple BGLs from the previous version, and compared them with the latest ones. As far as I can tell, it was only the FSProcedureChildType enumeration that got additions:

Type	Old	New
Transition	0x002C	0x0049
RunwayTransitions	0x0046	0x0046 (unchanged)
EnrouteTransitions	0x0047	0x004A
ApproachLegs	0x00E1	0x00EC
MissedApproachLegs	0x00E2	0x00ED
TransitionLegs	0x00E3	0x00EE
RunwayTransitionLegs	0x00E4	0x00EF
CommonRouteLegs	0x00E5	0x00F0
EnrouteTransitionLegs	0x00E6	0x00F1

The only changes I could really find was 8 bytes added to the end of the Leg structure, an array found in parent types *Legs above. And the Transition and EnrouteTransitions structs each contain 8 bytes before starting the LegContainer of types *Legs above. For those two, the 8 bytes seem to contain a string representing the IF, but it's kinda redundant.

[albar965]

Now I feel stupid. The records seem to have the same format. Only the id has changed?

I just adapted the code according to your table and now the code blows up because of missing route transitions.

This from bglcomp.xsd gave me the impression that the lists are merged in one record:

<xs:complexType name="ctDeparture">
  <xs:sequence>
    <xs:element name="RunwayTransitions" type="ctRunwayTransitions" minOccurs="1" maxOccurs="1" />
    <xs:element name="CommonRouteLegs" type="ctApproachLegs" minOccurs="1" maxOccurs="1" />
    <xs:element name="EnrouteTransitions" type="ctEnrouteTransitions" minOccurs="1" maxOccurs="1" />
  </xs:sequence>
    <xs:attribute name="name" form="unqualified" type="stString6" use="required" />
</xs:complexType>

BTW: Old fields and formats still have to be supported for add-ons (e.g. Navigraph is still using the old format).

BTW 2: RUNWAY_TRANSITIONS_MSFS seem to have two sizes depending on format before or after 1.16 and there is no field or flag indicating the size. Therefore, the ugly hack in there. Maybe it is better to calculate the size of the ApproachLeg by record size and number of legs.

[albar965]

I think I have it. Your table helped a lot.
Forget what I wrote above with bglcomp.xsd.

[icykoneko]

Did you already commit a fix?
I noticed in sidstar.cpp where it appends the ApproachLegs, the record type needs to be legRec.getId(). If you don't use that, you'll miss the RUNWAY_TRANSITIONS_MSFS case.

[albar965]

Just pushed.

[albar965]

I see. Like

          Record legRec(options, bs);
          int numLegs = bs->readUShort();
          for(int i = 0; i < numLegs; i++)
          {
            qint64 pos = bs->tellg();
            ApproachLeg leg(bs, legRec.getId<rec::ApprRecordType>());

and

          Record legRec(options, bs);
          int numLegs = bs->readUShort();
          for(int i = 0; i < numLegs; i++)
            legs.append(ApproachLeg(bs, legRec.getId<rec::ApprRecordType>()));
          insertEnrouteTransition(legs);

[icykoneko]

yea, okay, let me sync this with my local branch, cause I kinda was messing with it myself, and just finished up. About to test the code out now.
I think I renamed some parts and formatted a little different

[albar965]

legRec.getId<rec::ApprRecordType>() gives strange record types like 0xEF

[icykoneko]

You don't happen to know the BGL that contained the entry would you?

[albar965]

.../Official/OneStore/fs-base-nav/scenery/0000/NAX07070.bgl and PAKP

[icykoneko]

No, that's what you want. The extra 8 bytes in the leg records is determined by the container for the legs, in this case, 0xEF is the new RunwayTransitionLegs container type, which is inside the RunwayTransitions of type 0x46. Remember that's the only one that didn't get a new record type.

[albar965]

Okay. I see. This could make the hack in the RUNWAY_TRANSITIONS_MSFS redundant, right? Can you do the change? Maybe easier.

[icykoneko]

Yea, I see it too. The current code assumed there'd be only one of those records, but it can actually have multiple. Maybe the old type only supported one?

Sure, my branch is also working, I'll push in just a sec and link it.
https://github.com/icykoneko/atools/tree/feature/msfs-su4-appr-fixes

[icykoneko]

[albar965]

Perfect. Matches with X-Plane and Navigraph data.

BTW: How do you test? Hopefully not by running the whole LNM to comile? I use the navdatareader with a filter in navdatareader.cfg on selected files. Runs through in a few seconds.

[icykoneko]

Uhhhhhhhhh...... I... I use the tool... but... I rebuild it all eehehe. I should just do it for a select few airports.

[albar965]

Copy the navdatareader.cfg from the resources folder to the ABarthel in Roaming. Then filter by files:

IncludeFilenames=NAX07070.bgl,APX07070.bgl,APX28310.bgl,NAX28310.bgl,APX28310.bgl,NAX28310.bgl,APX07390.bgl,NAX07390.bgl,APX06240.bgl,NAX06240.bgl,APX26160.bgl,NAX26160.bgl ,APX03070.bgl,NAX03070.bgl

and/or airports:

IncludeAirportIcaoFilter=NTAR,PAKP,SKSV,PHKO,CYTZ,PAPO

Keep in mind that LNM uses this file too. Rename or delete after testing.

[icykoneko]

I had to step away for a little bit, but just about ready to submit pull request.

…

On Wed, May 26, 2021 at 5:13 PM Alexander Barthel ***@***.***> wrote: Copy the navdatareader.cfg from the resources folder to the ABarthel in Roaming. Then filter by files: IncludeFilenames=NAX07070.bgl,APX07070.bgl,APX28310.bgl,NAX28310.bgl,APX28310.bgl,NAX28310.bgl,APX07390.bgl,NAX07390.bgl,APX06240.bgl,NAX06240.bgl,APX26160.bgl,NAX26160.bgl ,APX03070.bgl,NAX03070.bgl and/or airports: IncludeAirportIcaoFilter=NTAR,PAKP,SKSV,PHKO,CYTZ,PAPO Keep in mind that LNM uses this file too. Rename or delete after testing. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#649 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG2BPIQ6OWK5AEROD56PYXTTPVP5XANCNFSM45PVKVNA> .

[icykoneko]

[icykoneko]

I think this ought to do it.
albar965/atools#12

[albar965]

Hmhm. RF legs are fine now. I also added the speed limits. Unfortunately there is no information if this is max, exact or minimum speed what they give in the BGL.

[icykoneko]

Yea, hey, you submitted the ticket to them about the RF legs right; guess they listened.

[albar965]

Yup. Good thing they actually listening to users.

Just compiled without any warnings (at least no unexpected ones). Perfect!
Thanks a lot! I have a few more tasks and bugs on my list. Maybe a release (maybe a beta first) in a week or two. Have to see.

Going to call it a day now. 😴

Alex

[albar965]

Working perfect now.

I get missing waypoints with the Navigraph update but this is not relevant anyway since users can update the LNM database with Navigraph directly.