LNM seems hit-or-miss picking up taxiway names on Load Scenery Library for custom airport

[fourdegrees]

Windows 11 64 bit
MSFS 2020

I want to make sure I'm using "best practices" compatible with LNM while developing custom airports in MSFS 2020 developer mode. I am working on an update to KBJC partly because of how bad the AI-built taxiways are, but also it's my home airport. I noticed when I built my package, loaded into the sim, and used Load Scenery Library, that LNM suddenly lost a lot of the taxiways I laid out. I can't figure out where LNM is "looking" when it labels and draws taxiways. I see how it finds drawn aprons and some taxiway surfaces, but can't sus out if I'm doing something wrong.

Asobo, on their forums, recommends keeping taxiway paths and points as simple as possible and using painted lines to draw in junctions and other complex taxiway interactions. It seems like once I simplified my paths and turned off center lines and surface draws, I lost a lot of info in LNM. But some taxiways are still showing up and are labelled how I built them.

Here is what it looks like in MSFS Dev Mode:

And here is LNM, after saving scenery, building package, reloading sim, and using LNM's LSL function:

You can see how many missing paths and names there are.

Can you tell me, is LNM looking within the taxiway path XML tag for certain things? For example, here is a snippet from the scenery XML file describing one of the paths that comprises Taxiway A3:
<TaxiwayPath parentGroupID="44" groupIndex="5" type="TAXI" surface="{F6FCF674-CC5C-4AA1-A297-7FFFF94E644D}" centerLine="FALSE" start="371" end="377" width="17.000000" weightLimit="0" name="4" drawSurface="FALSE" drawDetail="TRUE" groundMerging="FALSE" excludeVegetationAround="TRUE" excludeVegetationInside="TRUE"> <Material guid="{F6FCF674-CC5C-4AA1-A297-7FFFF94E644D}" type="Base tiled" tilingU="1.000000" tilingV="1.000000" width="1.000000" falloff="0.000000" opacity="255"/> </TaxiwayPath>

The snapshot of LNM showing part of TWY A and A3 being drawn are with 100% of TWY centerlines and surfaces set to "FALSE" so I'm not convinced having those off is the only issue. I tried changing the MSFS Dev Mode several ways and rebuilding. I tried having surfaces off, but center lines on. Then I tried center lines off but surfaces on. And I tried another TWY with both set to ON, but it still didn't show up.

Is LNM looking to be sure center lines are drawn before it will display the taxiway? Or is it looking for the taxiway surface to be drawn? Or some combination? What's the logic behind LNM labeling and drawing taxiways, so I can be sure to make my addon airport compatible?

Cheers.

[albar965]

LNM reads the taxiway lines, nodes and names. The center lines are drawn on top of the aprons and taxiway lines with the names. I see no issues here when looking at a few larger airports like KORD, KSEA or EDDF.

I have no idea what triggers the broken taxiway lines. I see this only with very few add-ons. Unfortunately Asobo does no care to document the BGL format and the only available non-official documentation is outdated. So I have to do a lot of guesswork.

If you send me your source XML and BGL file I can do some research what's going on there.

[fourdegrees]

It's a WIP, but I'd be glad for you to help me find if I've done something wrong!

Just before moving to this build, I had one with vastly more taxiway points and paths, but simplified it based on advice from the Asobo forums. I included that file as well, if you might find it useful. I recall LNM picked up more, but not all, of the paths and names from that one. Just rename the ".backup" to .xml if you'd like to look that one over. Unfortunately, I didn't preserve the .BGL from that version, but I could generate one without too much trouble if you need.

KBJC-20241021-1347.zip

[albar965]

Thank you. I'll have a look at it but give me a day or two since I'm currently looking at a tricky problem with airways.

[albar965]

Looking at it. I expected new record types for taxiways but have not seen any. Needs more research.

BTW: Note that the taxiway lines are drawn on top of aprons but below runways.

[fourdegrees]

For the note you wrote about draw order, does LNM look for lines defined as a taxiway path with centerLine="TRUE", or can it look for PaintedLines and draw those over aprons if centerLine="FALSE"? I ask because of how Asobo recommended using PaintedLines for details on complex TWYs while keeping the actual paths simple for the AI to understand.

I verified that the AI needs simple TaxiwayPaths because in my original TWY build, I would get crazy long instructions from the AI, including crossing the same RWY multiple times. Once I simplified the paths, the instructions became dependable. Hopefully LNM understands PaintedLine pretty well?

[albar965]

LNM reads all paths independent of the center line flag. Only the types vehicle and runway are ignored.

I don't read painted lines and adding this would be quite some effort. Not sure if it is worth it.

In the KBJC.bgl I get 136 invalid taxipaths from a total of 1174 which do not have a coordinate assigned. In the XML file I count 1324 paths. I dug through the unofficial BGL documentation and the MSFS SDK. I'm afraid I'm at a loss here.

[albar965]

Major hubs like EDDF, KORD or KSEA have a perfectly modeled taxiway system.

[fourdegrees]

It's so strange. I'm certain I've done something wrong, if my airport varies so widely from other ones, even ones that are more complex. I just don't know what I did that's causing the difference.

It's funny because in the file I sent you, the ramp areas are vastly more complex than the TWYs and the ramp is displayed just fine.

Any insight on the 136 invalid paths? Where did the "invalid" indication show up? LNM parser?

[albar965]

Sorry, forget my numbers above. I was looking at the wrong BGL file while debugging through it. 🤦
Number of taxi paths read by LNM is 1324 as it is reported by BGLExplorer. All are correct.

[fourdegrees]

Oh, haha. That's OK. I was hoping you hit on something I could dig into. I'm back to square one, then.

My only shot may be to get an Asobo dev to look at my files to see if they spot a mistake, but they are too busy with 2024 and I'm too small a fish.

I really don't want to erase all my taxipaths and start over with only a vague hope that the issue would resolve. :(

Am I doing something wrong in LNM? I've been building a package in MSFS, quitting, replacing the folder in Community, reloading the sim, then going into LNM and clicking Load Scenery Library and letting it rebuild the database.

"LNM reads all paths independent of the center line flag. " -- Does LNM check the drawSurface tag in any way?

[fourdegrees]

I did notice something interesting about LNM's TWY parsing, I think, at least for my airport. It gets TWY A correct, then A1 correct, then A2 also correct, then it catches a single segment of A3 and quits. Like it's running through the TWYs, hits something at A3 it doesn't like, then stops processing. I don't know if that means anything.

[albar965]

I did notice something interesting about LNM's TWY parsing, I think, at least for my airport. It gets TWY A correct, then A1 correct, then A2 also correct, then it catches a single segment of A3 and quits. Like it's running through the TWYs, hits something at A3 it doesn't like, then stops processing. I don't know if that means anything.

Unlikely. The names are handled in a separate way and nameless taxiways are kept since they are still valid.

I hope I'm not asking too much but can you send me a copy of your airport which has all taxiways removed except one or a few invisible one(s)? This would make debugging much easier.

I think the one on the left labelled B (not sure - hard to read) is clearly missing in LNM. What happens if you delete all but this one?

BTW: Most airports are correct but I know a few cases like an LSZH add-on where the taxiways are really broken.

[fourdegrees]

I'll do that now. Give me a bit.

[fourdegrees]

OK, this is all removed except B, B1, B3, and a small segment of D. I built the package, dropped it in Community, ran Load Scenery Library, and the TWYs appear as expected.

KBJC-20241025-pared-down-TWYs.zip

[fourdegrees]

I FOUND IT!!!!!

LNM DID encounter an error and quit parsing TWYs at A3, as I suggested, BUT, it's not the name of the TWY that was the issue, nor was it the surface or the center line. Hidden within TWY A3 is this problem: One of the 2 hold short lines is Orientation = Forward, and the other is Orientation = Reverse.

I deleted the offending "Reverse" point, then rebuilt that part of the TWY to ensure both are Orientation=Forward, and LOOK:

(Though, bizarrely, D3 has the same issue but it displays just fine. I've found I have lots of Forward and Reverse HSLs. Not sure what was up with A3, but that's the only thing I changed before the rebuild when it worked. I'm going to hunt down all of my HSLs that are Reverse and rebuild them to Forward, just to be safe.)