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

Hi, 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 ( (https://forums.flightsimulator.com/t/taxi-navigation-ribbon-
toggle/159329)[Taxi Navigation Ribbon - Toggle - Community Support / Wishlist

  • Microsoft Flight Simulator Forums - 414
    votes](https://forums.flightsimulator.com/t/taxi-navigation-ribbon-
    toggle/159329) ) 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: <https://flightsim.to/file/19152/rxp-small-taxi-
    helpers-3d-vr> 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!

Although the topic about the VFS is telling that any object is singly
identified by its GUID: https://devsupport.flightsimulator.com/t/4278 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?

Well despite trying, FS2020 SU9 is instantiating the model

      1. 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?

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.
Regards, Sylvain

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”?!?

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.

I’ll cross check this, thank you for the pointer. Nevertheless, because the
game code is effectively loading and showing 2 different materials for a
single and same unique object GUID, if this is a scenery indexed cache issue,
wouldn’t this still indicate that one code path in the game is loading the
modified file as-is from disk disregarding any potential cache entry (expected
and experienced with the manually added instance), while at the same time,
another code path in the game is loading the file only from the cache
disregarding the file on disk (unexpected and experience with the
automatically instanced one, showing at the same time as the manually added
one) ?!? I mean either they both come from disk, or both from cache, in which
case both should be displaying the same material isn’t it? (whether the edited
or the original material). In this case, a single object GUID which material
definition is in a BGL file is showing both at the same time the original
unmodified material AND the modified material from disk. ?!

What would you otherwise suggest and recommend in order to override this
model/GUID without editing the original file bytes? Or perhaps more generally,
what would you suggest and recommend, as a SDK and Asobo supported way, to
override/edit any unique model which is found included in any “base package”
BGL file?

I can’t recommend anything for now as we don’t have any established process to
allow resources identified by a GUID to be replaced. If that’s something we
want to do, we need the engine team to make sure reusing a GUID is correctly
handled by the game and it’s not the case at the moment.