plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.

In the upcoming flighting, we've changed the behaviour of the content.xml file. If your addon uses this file, please read this article!

Please take a moment to read the platform’s guidelines before you get started!


RXP avatar image
RXP asked FlyingRaccoon commented

SU9 overriding some glTF materials: is this a regression or intentional?


I've noticed a strange behavior with SU9 and I don't know if this is bug, or a design decision.

Here is the context:

1) FS2020 prevents overriding the Taxi helpers with a community add-on for those finding them too obtrusive.

2) FS2020 doesn't provide any convenient "toggle" either ( Taxi Navigation Ribbon - Toggle - Community Support / Wishlist - Microsoft Flight Simulator Forums - 414 votes )

I've therefore made a mod which now consists in a PowerShell script in order to make the taxi helpers less obtrusive (in 3D and VR), more naturally blending with the environment, so that you can leave the taxi assistance enabled always:

The script parses, modifies then overrides the Asobo_UI.bgl file with a user selection of colors, sizes and alternate representations.

However, I've noticed that with SU9, no matter the changes to the TRACK_HELPER_Taxi {f518b7e1-0c31-4724-9968-4ccb346f8153} model materials, the game is always displaying the arrows in a certain shade of blue. More surprising is that adding the same object in scenery editor do show the correctly modified material like in this screenshot:


However, changing the size is ok, as well as changing the material of the two other parking helpers (you can see the white non-emissive pseudo ground painted version in the screenshot).

But for the arrow specifically, the same object with the same GUID is displaying in 2 different ways with 2 different materials, as if SU9 is overriding the material to paint it blue.

Is this an SU9 bug?

Is this an SU9 design decision to prevent modifying this object specifically?

Can you please open up the VFS so that we can make this type of mod in the form of a community folder instead of overriding the stock files?

Thank you!

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

RXP avatar image
RXP answered

Although the topic about the VFS is telling that any object is singly identified by its GUID:

Is scenery file structure and duplicates still a thing? - MSFS DevSupport (

I've done a few more tests and it really seems like FS2020 and in this case, the same GUID is representing two different types of instances at runtime:

- FS2020 is instantiating the TRACK_HELPER_Taxi {f518b7e1-0c31-4724-9968-4ccb346f8153} model with a material which is not in the Asobo_UI.BGL file (unexpected)

- FS2020 is also instantiating the same model that I can manually add in scenery editor, but for these, it is using the material as it is set in the Asobo_UI.BGL file (expected)

Q: Is this a bug in the object management?

Q: Is this a voluntary override for this model specifically?

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

RXP avatar image
RXP answered FlyingRaccoon commented

Well despite trying, FS2020 SU9 is instantiating the model

TRACK_HELPER_Taxi {f518b7e1-0c31-4724-9968-4ccb346f8153}

with a material which is not in the Asobo_UI.BGL file it is coming from, and this might be a bug.

@EPellissier, @FlyingRaccoon do you have any hint/recommendation? Is this still a bug in SU10?

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Hello @RXP

Does the layout.json reflects your modifications of the BGL file?
Probably something messing with the scenery cache.
Editing the base bgl files is not something we support and we don't plan investigating issues related to this kind of modification for now.


0 Likes 0 ·
RXP avatar image RXP FlyingRaccoon ♦♦ ·

Hi Sylvain,

Thank you for helping. The original BGL file content is changed but its size and layout doesn't. The type of modification I've been doing here is kind of replacing a 0x30 with a 0x31 in the file. As for the cache, if this is about the games rolling cache, this one was cleared up as well (I thought it could have been a cause).

Please note this "behavior" is new to SU9, it was working fine prior.

The question I'm raising here is only about a possible bug introduced in SU9 which shows in the example above as 2 instances of the same model/material, with the same GUID, but the instance generated by the game is overriding the material with values that don't exist in the file anymore, whereas the instance manually added is showing the material as it is set in the file.

Hence why I'm wondering whether this is specific to this GUID/model (it would be treated differently and purposely overridden in the game code), or is this a subtle bug introduced in SU9 in the way it is dealing with GUID/models/materials?

The support question here is really not about Asobo officially supporting hex editing game files at all, but this raises the question then: what would you recommend in order to override this model/GUID without editing the original file bytes?

Can you also please clarify what you're talking about more specifically, with "the layout.json reflecting the modification"?!?

0 Likes 0 ·
I'm not talking about rolling cache but scenery cache (.dat files in the SceneryIndexes directory)

The package layout.json contains the size and timestamp for each resource. You have to make sure it matches the new file when it's modified.

1 Like 1 ·
Show more comments

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 19.1 MiB each and 23.8 MiB total.